| <?xml version="1.0" encoding="UTF-8"?> |
| <!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd"> |
| <!-- VERSION rmc:7.1.0 --> |
| <html xmlns="http://www.w3.org/1999/xhtml"> |
| <head> |
| <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/> |
| <!-- START NON-TRANSLATABLE --> |
| <title>openup&#92;guidances&#92;checklists&#92;&#92;design.xmi</title> |
| </head> |
| <!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. --> |
| <body> |
| Element Name: design.xmi<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: presentationName<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:presentationName,_0XSzsMlgEdmt3adZL5Dmdw CRC: 3403898630 -->Design<!-- END:presentationName,_0XSzsMlgEdmt3adZL5Dmdw --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: briefDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:briefDescription,_0XSzsMlgEdmt3adZL5Dmdw CRC: 1218476290 -->This checklist provides questions to verify that the design is created in a consistent and complete manner.<!-- END:briefDescription,_0XSzsMlgEdmt3adZL5Dmdw --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: mainDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:mainDescription,_YIYIYMM1EdmSIPI87WLu3g CRC: 3513199825 --><p> The items in this checklist represent good practices for creating and communicating |
| a robust design. Try to address every item to the greatest extent possible to |
| create the best design. It may not be possible to address every item, and you |
| may be able to address some items to only a limited extent. In these cases, |
| be sure that there are good reasons for only partially addressing an item or |
| not addressing an item at all. </p> |
| <p> Design can take place every day. Use this checklist regularly to ensure a |
| robust, consistent, and understandable design. Make the design good enough for |
| the specific goals being addressed by using this checklist to identify areas |
| that have been skipped, ignored, or not sufficiently addressed. </p><!-- END:mainDescription,_YIYIYMM1EdmSIPI87WLu3g --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: name<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:name,_sO-NINVUEduaE6F4-SvXzg CRC: 49713048 -->Is the design understandable?<!-- END:name,_sO-NINVUEduaE6F4-SvXzg --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: sectionDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:sectionDescription,_sO-NINVUEduaE6F4-SvXzg CRC: 2843105966 --><ul> |
| <li> Is the design organized in a way that team members can easily find the |
| information that they're looking for? </li> |
| <li> Is the design as simple as it can be, while still fulfilling the objectives |
| of the design and giving sufficient direction to implementers? </li> |
| <li> Is the design neither too simple nor too advanced? The design sophistication |
| should be appropriate to the experience level of other team members and technical |
| stakeholders. This applies to both the concept and the representation of the |
| design. </li> |
| <li> Does the design express what the designer intends to express? </li> |
| </ul><!-- END:sectionDescription,_sO-NINVUEduaE6F4-SvXzg --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: name<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:name,_7DUXMNTQEduaE6F4-SvXzg CRC: 716893646 -->Is the design consistent?<!-- END:name,_7DUXMNTQEduaE6F4-SvXzg --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: sectionDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:sectionDescription,_7DUXMNTQEduaE6F4-SvXzg CRC: 2695804666 --><ul> |
| <li> |
| Does the design follow any design standards? |
| </li> |
| <li> |
| Does the design apply other idioms consistently? |
| </li> |
| <li> |
| Are the names of the design elements consistent and easy to interpret? |
| </li> |
| <li> |
| Does any part of the design contradict another part of it in such a way that puts the project at risk? |
| </li> |
| <li> |
| If the design is rendered visually, is the notation used to describe the design used consistently so that it |
| can be understood and is not ambiguous? |
| </li> |
| </ul><!-- END:sectionDescription,_7DUXMNTQEduaE6F4-SvXzg --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: name<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:name,_V_LgsNTREduaE6F4-SvXzg CRC: 441237292 -->Is the design maintainable?<!-- END:name,_V_LgsNTREduaE6F4-SvXzg --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: sectionDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:sectionDescription,_V_LgsNTREduaE6F4-SvXzg CRC: 3035818919 --><ul> |
| <li> |
| Is the design structured well enough to be maintained? |
| </li> |
| <li> |
| Is the design set up to appropriately accommodate expected changes? The design should not be overdone to handle |
| <em>any</em> possible change, just reasonably expected changes. |
| </li> |
| <li> |
| Have redundant areas of the design been removed so that the implementation does not contain redundant code? |
| </li> |
| </ul><!-- END:sectionDescription,_V_LgsNTREduaE6F4-SvXzg --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: name<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:name,_ySbT4NTREduaE6F4-SvXzg CRC: 3910462897 -->Is the design traceable?<!-- END:name,_ySbT4NTREduaE6F4-SvXzg --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: sectionDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:sectionDescription,_ySbT4NTREduaE6F4-SvXzg CRC: 3309810254 --><ul> |
| <li> Is it clear how the design elements relate to the requirements? This does |
| not need to involve a heavyweight traceability strategy, but is there some |
| way to figure out what part of the design supports a particular requirement? |
| </li> |
| <li> It what portions of the implementation support each design element clear? |
| </li> |
| </ul><!-- END:sectionDescription,_ySbT4NTREduaE6F4-SvXzg --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: name<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:name,_tywgENTQEduaE6F4-SvXzg CRC: 1118296618 -->Does the design reflect the architectural objectives of the system?<!-- END:name,_tywgENTQEduaE6F4-SvXzg --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: sectionDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:sectionDescription,_tywgENTQEduaE6F4-SvXzg CRC: 2298006158 --><ul> |
| <li> Does the design conform to the architecture as specified? </li> |
| <li>Does it apply the architectural patterns appropriately? </li> |
| <li> Are Architectural Mechanisms used appropriately? Are they applied in all |
| applicable circumstances? </li> |
| </ul><!-- END:sectionDescription,_tywgENTQEduaE6F4-SvXzg --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: name<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:name,_nMogoNTQEduaE6F4-SvXzg CRC: 901177840 -->Are the design elements modular?<!-- END:name,_nMogoNTQEduaE6F4-SvXzg --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: sectionDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:sectionDescription,_nMogoNTQEduaE6F4-SvXzg CRC: 2665406664 --><ul> |
| <li> Do the design elements have high internal cohesion? Does the degree of |
| interaction within the unit demonstrate that all of the internal parts belong |
| together? </li> |
| <li> Do the design elements have low coupling? Is there minimal interdependence |
| between design elements? When design elements depend upon one another, is |
| this done as simply as possible and in such a way that the client element |
| will not be affected by changes to the internal parts of the supplier element? |
| </li> |
| <li> Are the design elements defined with abstract interfaces in ways that |
| changes can be made to the internal implementation without affecting client |
| design elements? </li> |
| <li> Does each design element represent a clearly defined abstraction? </li> |
| </ul><!-- END:sectionDescription,_nMogoNTQEduaE6F4-SvXzg --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: name<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:name,_19E2INTQEduaE6F4-SvXzg CRC: 2745551718 -->Can the system be implemented from the information in the design?<!-- END:name,_19E2INTQEduaE6F4-SvXzg --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: sectionDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:sectionDescription,_19E2INTQEduaE6F4-SvXzg CRC: 3091544119 --><ul> |
| <li> Has sufficient detail been included to direct the implementation? </li> |
| <li> Does the design constrain the implementation only as much as necessary? |
| Does the design allow freedom for the implementer to implement it appropriately? |
| </li> |
| <li> Is the design feasible? Is it a design that can be reasonably implemented |
| by the team by using the technologies selected within the timeframe of the |
| project? </li> |
| </ul><!-- END:sectionDescription,_19E2INTQEduaE6F4-SvXzg --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: name<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:name,_F_AWwNTTEduaE6F4-SvXzg CRC: 1847073178 -->Does the design provide enough information for developer testing?<!-- END:name,_F_AWwNTTEduaE6F4-SvXzg --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: sectionDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:sectionDescription,_F_AWwNTTEduaE6F4-SvXzg CRC: 1985321229 --><ul> |
| <li> Does the design provide enough information for developer test design? Are |
| the expected behavior and constraints on the methods clear? </li> |
| <li> Are the collaborations between design elements clear enough to create integration |
| tests? </li> |
| </ul><!-- END:sectionDescription,_F_AWwNTTEduaE6F4-SvXzg --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: name<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:name,_upZp0NT0EduaE6F4-SvXzg CRC: 1436929061 -->Does the design describe the system at the appropriate level of abstraction?<!-- END:name,_upZp0NT0EduaE6F4-SvXzg --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: sectionDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:sectionDescription,_upZp0NT0EduaE6F4-SvXzg CRC: 2949688924 -->Does the design describe the system at the appropriate level of abstraction given |
| the objectives? This usually means that the system is described at several different |
| levels of abstraction and from different perspectives.<!-- END:sectionDescription,_upZp0NT0EduaE6F4-SvXzg --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: name<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:name,_Nqih0NVREduaE6F4-SvXzg CRC: 1473879132 -->Does the design support a coarse-grained perspective of the system?<!-- END:name,_Nqih0NVREduaE6F4-SvXzg --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: sectionDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:sectionDescription,_Nqih0NVREduaE6F4-SvXzg CRC: 3878978930 --><ul> |
| <li> |
| Can the design be understood as a set of higher-order subsystems? |
| </li> |
| <li> |
| Are the subsystem dependencies documented? |
| </li> |
| <li> |
| Are interfaces clearly defined for each subsystem? Is each subsystem designed so that its services can be accessed |
| through the interface without a need to access internal parts? |
| </li> |
| <li> |
| Is each subsystem designed so that someone can work within one part without having to understand the internal parts |
| of the other elements? |
| </li> |
| </ul><!-- END:sectionDescription,_Nqih0NVREduaE6F4-SvXzg --> |
| </body> |
| </html> |
