Architecture Design Rubric | ||
|---|---|---|
| Evaluation Considerations | ||
| Category | Attribute | Plus/Check/Minus |
| Requirements | Use Cases cover core gameplay | |
| Use Cases are reasonable (not overly ambitious for Alpha | ||
| Use Cases provide clear, concise descriptions of gameplay scenarios | ||
| Non-functional requirements that impact architecture are clearly articulated | ||
| Domain Diagrams | Domain diagram identifies key domain concepts found in Use Cases | |
| Domain diagram identifies key relationships found in Use Cases | ||
| Class Diagrams | Simple and Intuitive; | |
| Uses real game objects. | ||
| Clearly articulates important aspects of interface. | ||
| Identifies major collaborations between classes. | ||
| Obeys single responsibility principle. | ||
| Favors composition over inheritence. | ||
| Obeys Law of Demeter. | ||
| Encapsulates variation. | ||
| Diagrams are clear and well drawn. | ||
| Sequence Diagrams | Realize Use Cases | |
| Illustrate Low Coupling | ||
| Avoids unnecessary details | ||
| Diagrams are clear and well drawn. | ||
| Other Models | Scoring models are clearly described, responsibilities for maintaining and updated these models are clear in class and sequence diagrams | |
| Simulation models are clearly described, responsibilities for maintaining and updated these models are clear in class and sequence diagrams | ||
| Data models ncluding data structures and input/output specs are described, responsibilities for maintaining data is clear in class and sequence diagrams | ||
| Importan algorithms are clearly described, responsibilities for implementing these algorithms are clear in class and sequence diagrams | ||
| Feasibility; | The team can build the architecture within Phase 2 | |
| Testability | No obvious problems in testing an implementation of this architecture | |
| Extensibility | Design sufficiently flexible that extending for final game is reasonable | |
| Follows open-closed principle | ||
| Design sufficiently intuitive and flexible so that others could extend | ||
| Design Patternsl | Used as appropriate | |
| Critique | Rational for key decisions | |
| Weaknesses in the architecture identified | ||
| Reasons for NOT addressing Weaknesses in the architecture discussed | ||
| Review Package | Introduction is clean and well-written | |
| Review Agenda was appropriate | ||
| Recommendation for review assignments was helpful | ||
| All design documents were linked: (Use Cases, Class diagrams, Sequence Diagrams, Model Descriptions Critique, etc. | ||
Last Modified Tuesday, 09-Oct-2012 13:44:08 PDT