Final 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 | ||
| Important 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 | Problems in architecture are identified | |
| Reasons for not addressing problems are discussed | ||
| Response to Design Review | Discusses how the design was reviewd in response to review issues | |
| Discusses issues raised in the review that were not addressed | ||
Last Modified Sunday, 14-Oct-2012 16:55:46 PDT