| <?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.3/uma.ecore" epf:version="1.0.0" xmi:id="_YIYIYMM1EdmSIPI87WLu3g" name="design,_0XSzsMlgEdmt3adZL5Dmdw" guid="_YIYIYMM1EdmSIPI87WLu3g" changeDate="2006-09-15T15:28:43.942-0400" 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 |
| some items may only be able to be addressed to 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 be performed every day. Use this checklist regularly to assure the design is robust, consistent, and |
| understandable. 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="_cKSvsD6SEduAL-bCqar_dg" name="General" guid="_cKSvsD6SEduAL-bCqar_dg"> |
| <sectionDescription><p> |
| Do separate design elements have low coupling? Does each design element have high internal cohesion? |
| </p> |
| <p> |
| Does the design reflect the architectural objectives of the system? |
| </p> |
| <p> |
| Can the system be implemented from the information in the design? Has sufficient detail been included? |
| </p> |
| <p> |
| Is the design consistent? Does any part of the design contradict another part of it in such a way that puts the project |
| at risk? |
| </p> |
| <p> |
| Is the design able to accommodate future changes? |
| </p> |
| <p> |
| Is the design appropriate to the experience level of other team members and stakeholders, neither too simple nor too |
| advanced? |
| </p> |
| <p> |
| Is the design written in such a way, and is it structured well enough, so it can be maintained easily? |
| </p> |
| <p> |
| Does the design constrain the implementation only as much as is necessary? |
| </p> |
| <p> |
| Does the design describe all the behavior of the system for the requirements that are currently being addressed? |
| </p> |
| <p> |
| Can all parts of the design be traced back to the requirements? Can the requirements (for the current iteration) be |
| traced to design elements? |
| </p> |
| <p> |
| Is there an unambiguous place or places&nbsp;in the design where each behavior exists? |
| </p> |
| <p> |
| Are the use case flows that are currently being addressed described in the design? |
| </p> |
| <p> |
| Are&nbsp;complex flows outside the Basic Flow&nbsp;addressed, including exceptional cases? |
| </p> |
| <p> |
| Has the behavior described in the requirements that are currently being addressed&nbsp;been distributed to the correct |
| design elements? |
| </p> |
| <p> |
| Does the design provide enough information for test design? For example, are the collaborations between design elements |
| clear enough to create integration tests? |
| </p> |
| <p> |
| Have redundant areas of the design been removed so the Implementation does not contain redundant code? |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="__4O2AD6WEduAL-bCqar_dg" name="Organization and Clarity" guid="__4O2AD6WEduAL-bCqar_dg"> |
| <sectionDescription><p> |
| Does the design describe the system at the appropriate level of abstraction, given the objectives? This usually means |
| the system is described at a number of different levels of&nbsp;abstraction and perspectives. |
| </p> |
| <p> |
| Does the design use common vocabulary and terms from the business and technical domains? |
| </p> |
| <p> |
| Does the design describe the behavior of the elements unambiguously to the extent that developer tests can be created |
| toverify the implementation? |
| </p> |
| <p> |
| Are the design's constructs, vocabulary, and semantics appropriate to the problem being solved? This usually means the |
| customer's vocabulary is used, and elements of the design are referenced in a consistent manner. |
| </p> |
| <p> |
| Is the design organized in a way that team members can easily find the information they're looking for? |
| </p> |
| Is the notation used to&nbsp;describe the design&nbsp;used consistently?<br /> |
| <p> |
| Is the design organized in a way that helps team members modify it without contending for the same part of the design? |
| That is, can mulitple people work on the design in parallel? |
| </p> |
| <p> |
| Are the names of elements within the design consistent and easy to interpret? |
| </p> |
| <p> |
| Does each design element represent a clearly defined abstraction? |
| </p> |
| <p> |
| Is the design as simple as it can be while fulfilling the objectives of the design and giving sufficient direction to |
| implementers? |
| </p> |
| <p> |
| Is the design clear enough and contain enough detail so it can be implemented? |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_dahBcD6SEduAL-bCqar_dg" name="Architecture" guid="_dahBcD6SEduAL-bCqar_dg"> |
| <sectionDescription><p> |
| Is the architecture clearly called out in the design ? Can team members and stakeholders clearly identify the portion |
| of the design that is the architecture? |
| </p> |
| <p> |
| Are architectural mechanisms (patterns) clearly defined in the design so they're reusable and understandable? |
| </p> |
| <p> |
| Are architectural mechanisms used appropriately? Are they applied in all applicable circumstances? |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_kWnQ4D6SEduAL-bCqar_dg" name="Subsystems" guid="_kWnQ4D6SEduAL-bCqar_dg"> |
| <sectionDescription><p> |
| Do all elements within a subsystem have private visibility? In other words, is the subsystem interface the&nbsp;only |
| way to access the behavior of elements inside the subsystem? |
| </p> |
| <p> |
| Is the interface for each subsystem clearly defined in the design? |
| </p> |
| <p> |
| Are the subsystem dependencies documented?&nbsp; |
| </p></sectionDescription> |
| </sections> |
| </org.eclipse.epf.uma:ContentDescription> |