| <?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="-mFnoIulBQ7JrxiaHVCrE7A" |
| name="new_checklist,_OhJKUNWsEduaE6F4-SvXzg" guid="-mFnoIulBQ7JrxiaHVCrE7A" changeDate="2007-07-25T12:48:32.932-0700" |
| version="1.0.0"> |
| <mainDescription><p>
 |
| The items in this checklist represent good practices for creating a high-quality implementation. Try to address every
 |
| item to the greatest extent possible to create the best implementation. 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>
 |
| This checklist is not something that should be considered only for heavyweight code reviews. Each developer should keep
 |
| the quality criteria embodied in these check items in mind while coding. When developers work together, the review
 |
| against these criteria should be done in real time so that quality is ensured up front as they are writing the code.
 |
| </p>
 |
| <p>
 |
| Appropriate divergence from the quality criteria described here could be worthy of a comment in the implementation so
 |
| that developers examining the code in the future know why the exception occurred.
 |
| </p></mainDescription> |
| <sections xmi:id="_q8zSoNWsEduaE6F4-SvXzg" name="Does the implementation conform to the architecture and design?" |
| guid="_q8zSoNWsEduaE6F4-SvXzg"> |
| <sectionDescription><ul>
 |
| <li> Is the implementation structured as specified in the design? </li>
 |
| <li> Are all of the functions in the design implemented? </li>
 |
| <li> Are all of the interfaces in the design implemented according to their 
 |
| specifications? </li>
 |
| <li> Does the implementation adhere to all design and architectural constraints? 
 |
| </li>
 |
| </ul></sectionDescription> |
| </sections> |
| <sections xmi:id="_vb-zsNWsEduaE6F4-SvXzg" name="Is the implementation testable?" |
| guid="_vb-zsNWsEduaE6F4-SvXzg"> |
| <sectionDescription><ul>
 |
| <li> Can you test the expected behavior at the unit level? </li>
 |
| <li> Is the code written in a way that all paths can be exercised? </li>
 |
| </ul></sectionDescription> |
| </sections> |
| <sections xmi:id="_djoQENXCEduaE6F4-SvXzg" name="Is the implementation correct?" |
| guid="_djoQENXCEduaE6F4-SvXzg"> |
| <sectionDescription><ul>
 |
| <li> Does the implementation pass all of the developer tests? </li>
 |
| <li> Does the implementation support the acceptance criteria of the test cases? 
 |
| </li>
 |
| <li> Is all code executable (no dead code areas)? </li>
 |
| </ul></sectionDescription> |
| </sections> |
| <sections xmi:id="_D4YyoO24EduHHNqbab9GOA" name="Is the implementation understandable?" |
| guid="_D4YyoO24EduHHNqbab9GOA"> |
| <sectionDescription><ul>
 |
| <li> Does the implementation clearly state the intention of the developer? </li>
 |
| <li> Does the code adhere to the Coding Guidelines? If a set of Coding Guidelines 
 |
| has not been identified, the code should be checked for a variety of consistency 
 |
| issues, such as naming conventions, indentation, spacing, and so forth.</li>
 |
| <li> Are the names of the variables easy to understand? Do they describe the 
 |
| purpose of the variable? </li>
 |
| <li> Are all of the comments necessary to be able to understand the associated 
 |
| code? Comments should enhance the understanding of the code rather than merely 
 |
| repeat it. </li>
 |
| <li> Are all comments correct? </li>
 |
| <li> Does the implementation match the documentation? </li>
 |
| </ul></sectionDescription> |
| </sections> |
| <sections xmi:id="_klOGANvBEduy3tw_ntB-3g" name="Is there no redundancy?" guid="_klOGANvBEduy3tw_ntB-3g"> |
| <sectionDescription><p> Is there no redundancy in the implementation? (Identify candidates for refactoring.) 
 |
| </p></sectionDescription> |
| </sections> |
| </org.eclipse.epf.uma:ContentDescription> |
