| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:ContentDescription xmi:version="2.0" |
| xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.5/uma.ecore" |
| xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.0" xmi:id="_YIYIYMM1EdmSIPI87WLu3g" |
| name="design,_0XSzsMlgEdmt3adZL5Dmdw" guid="_YIYIYMM1EdmSIPI87WLu3g" changeDate="2007-03-18T15:57:27.416-0800" |
| version="1.0.0"> |
| <mainDescription><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&nbsp;ensure&nbsp;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></mainDescription> |
| <sections xmi:id="_sO-NINVUEduaE6F4-SvXzg" name="Is the design understandable?" |
| guid="_sO-NINVUEduaE6F4-SvXzg"> |
| <sectionDescription><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></sectionDescription> |
| </sections> |
| <sections xmi:id="_7DUXMNTQEduaE6F4-SvXzg" name="Is the design consistent?" guid="_7DUXMNTQEduaE6F4-SvXzg"> |
| <sectionDescription><ul>
 |
| <li>
 |
| Does the design follow any design standards?
 |
| </li>
 |
| <li>
 |
| Does&nbsp;the design&nbsp;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&nbsp;describe the design used consistently so that it
 |
| can be understood and is not ambiguous?
 |
| </li>
 |
| </ul></sectionDescription> |
| </sections> |
| <sections xmi:id="_V_LgsNTREduaE6F4-SvXzg" name="Is the design maintainable?" guid="_V_LgsNTREduaE6F4-SvXzg"> |
| <sectionDescription><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></sectionDescription> |
| </sections> |
| <sections xmi:id="_ySbT4NTREduaE6F4-SvXzg" name="Is the design traceable?" guid="_ySbT4NTREduaE6F4-SvXzg"> |
| <sectionDescription><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></sectionDescription> |
| </sections> |
| <sections xmi:id="_tywgENTQEduaE6F4-SvXzg" name="Does the design reflect the architectural objectives of the system?" |
| guid="_tywgENTQEduaE6F4-SvXzg"> |
| <sectionDescription><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></sectionDescription> |
| </sections> |
| <sections xmi:id="_nMogoNTQEduaE6F4-SvXzg" name="Are the design elements modular?" |
| guid="_nMogoNTQEduaE6F4-SvXzg"> |
| <sectionDescription><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&nbsp;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></sectionDescription> |
| </sections> |
| <sections xmi:id="_19E2INTQEduaE6F4-SvXzg" name="Can the system be implemented from the information in the design?" |
| guid="_19E2INTQEduaE6F4-SvXzg"> |
| <sectionDescription><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></sectionDescription> |
| </sections> |
| <sections xmi:id="_F_AWwNTTEduaE6F4-SvXzg" name="Does the design provide enough information for developer testing?" |
| guid="_F_AWwNTTEduaE6F4-SvXzg"> |
| <sectionDescription><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></sectionDescription> |
| </sections> |
| <sections xmi:id="_upZp0NT0EduaE6F4-SvXzg" name="Does the design describe the system at the appropriate level of abstraction?" |
| guid="_upZp0NT0EduaE6F4-SvXzg"> |
| <sectionDescription>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.</sectionDescription> |
| </sections> |
| <sections xmi:id="_Nqih0NVREduaE6F4-SvXzg" name="Does the design support a coarse-grained perspective of the system?" |
| guid="_Nqih0NVREduaE6F4-SvXzg"> |
| <sectionDescription><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></sectionDescription> |
| </sections> |
| </org.eclipse.epf.uma:ContentDescription> |
