| <?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" xmlns:rmc="http://www.ibm.com/rmc" |
| rmc:version="7.5.0" xmi:id="_YIYIYMM1EdmSIPI87WLu3g" |
| name="design,_0XSzsMlgEdmt3adZL5Dmdw" guid="_YIYIYMM1EdmSIPI87WLu3g" changeDate="2008-08-11T14:21:25.062-0700" |
| version="1.0.0"> |
| <sections xmi:id="_sO-NINVUEduaE6F4-SvXzg" name="The design is 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="The design is 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="The design is 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="The design is 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="The design reflects 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="The design elements are 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="The system can 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="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="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="The design supports 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> |
