OpenUP/OpenUP_baseline_EN/exported_HTML_0_9/openup_basic/guidances/checklists/design.html - epf/org.eclipse.epf.nl-libraries - Git at Google

 <?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_basic\guidances\checklists\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: 4067238563 --><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><!-- END:mainDescription,_YIYIYMM1EdmSIPI87WLu3g -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: name<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:name,_cKSvsD6SEduAL-bCqar_dg CRC: 26480598 -->General<!-- END:name,_cKSvsD6SEduAL-bCqar_dg -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: sectionDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:sectionDescription,_cKSvsD6SEduAL-bCqar_dg CRC: 2506740626 --><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><!-- END:sectionDescription,_cKSvsD6SEduAL-bCqar_dg -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: name<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:name,__4O2AD6WEduAL-bCqar_dg CRC: 526592327 -->Organization and Clarity<!-- END:name,__4O2AD6WEduAL-bCqar_dg -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: sectionDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:sectionDescription,__4O2AD6WEduAL-bCqar_dg CRC: 2838722867 --><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><!-- END:sectionDescription,__4O2AD6WEduAL-bCqar_dg -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: name<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:name,_dahBcD6SEduAL-bCqar_dg CRC: 1822983426 -->Architecture<!-- END:name,_dahBcD6SEduAL-bCqar_dg -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: sectionDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:sectionDescription,_dahBcD6SEduAL-bCqar_dg CRC: 2885622810 --><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><!-- END:sectionDescription,_dahBcD6SEduAL-bCqar_dg -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: name<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:name,_kWnQ4D6SEduAL-bCqar_dg CRC: 1704096685 -->Subsystems<!-- END:name,_kWnQ4D6SEduAL-bCqar_dg -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: sectionDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:sectionDescription,_kWnQ4D6SEduAL-bCqar_dg CRC: 1533110501 --><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><!-- END:sectionDescription,_kWnQ4D6SEduAL-bCqar_dg -->
 </body>
 </html>
	<?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_basic\guidances\checklists\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: 4067238563 --><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><!-- END:mainDescription,_YIYIYMM1EdmSIPI87WLu3g -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: name<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:name,_cKSvsD6SEduAL-bCqar_dg CRC: 26480598 -->General<!-- END:name,_cKSvsD6SEduAL-bCqar_dg -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: sectionDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:sectionDescription,_cKSvsD6SEduAL-bCqar_dg CRC: 2506740626 --><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 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 complex flows outside the Basic Flow addressed, including exceptional cases?
	</p>
	<p>
	Has the behavior described in the requirements that are currently being addressed 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><!-- END:sectionDescription,_cKSvsD6SEduAL-bCqar_dg -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: name<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:name,__4O2AD6WEduAL-bCqar_dg CRC: 526592327 -->Organization and Clarity<!-- END:name,__4O2AD6WEduAL-bCqar_dg -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: sectionDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:sectionDescription,__4O2AD6WEduAL-bCqar_dg CRC: 2838722867 --><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 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 describe the design 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><!-- END:sectionDescription,__4O2AD6WEduAL-bCqar_dg -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: name<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:name,_dahBcD6SEduAL-bCqar_dg CRC: 1822983426 -->Architecture<!-- END:name,_dahBcD6SEduAL-bCqar_dg -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: sectionDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:sectionDescription,_dahBcD6SEduAL-bCqar_dg CRC: 2885622810 --><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><!-- END:sectionDescription,_dahBcD6SEduAL-bCqar_dg -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: name<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:name,_kWnQ4D6SEduAL-bCqar_dg CRC: 1704096685 -->Subsystems<!-- END:name,_kWnQ4D6SEduAL-bCqar_dg -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: sectionDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:sectionDescription,_kWnQ4D6SEduAL-bCqar_dg CRC: 1533110501 --><p>
	Do all elements within a subsystem have private visibility? In other words, is the subsystem interface the 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?
	</p><!-- END:sectionDescription,_kWnQ4D6SEduAL-bCqar_dg -->
	</body>
	</html>