| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:TaskDescription 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="_d2aMwKrMEdmqUqi7YGiSxw" name="implement_solution,_0hyzgMlgEdmt3adZL5Dmdw" guid="_d2aMwKrMEdmqUqi7YGiSxw" authors="Jim Ruehlin" changeDate="2006-09-27T18:31:00.562-0700" version="1.0"> |
| <mainDescription><p> |
| Usually, this task is focused on a specific element, such as a class or component, but it does not need to be. |
| </p> |
| <p> |
| You implement a portion of the design during each iteration by performing this task. You can perform the task any |
| number of times during an iteration. |
| </p> |
| <p> |
| Modify the implementation incrementally. Make additions and changes to the implementation for an issue, run the unit |
| and regression tests, and then complete the issue before moving on to other issues. |
| </p> |
| <p> |
| See the associated guidelines for information on how to perform the steps described in this task. |
| </p></mainDescription> |
| <keyConsiderations><p> |
| This task is complete once the build has successfully completed. The implementation should then be immediately tested. |
| </p></keyConsiderations> |
| <sections xmi:id="_2sxisE2iEduU655MA_3VXg" name="Determine a strategy" guid="_2sxisE2iEduU655MA_3VXg"> |
| <sectionDescription><p> |
| You need to determine a strategy, based on the <a class="elementLink" href="./../../openup_basic/workproducts/design,_0WuL8slgEdmt3adZL5Dmdw.html" guid="_0WuL8slgEdmt3adZL5Dmdw">Design</a>&nbsp;of the work item being worked on, for how you're going to implement it. |
| Your fundamental options are: |
| </p> |
| <ol> |
| <li> |
| Apply existing, reusable assets. |
| </li> |
| <li> |
| Model the design in detail and generate the source code (by model transformation). |
| </li> |
| <li> |
| Write the source code. |
| </li> |
| <li> |
| Any combination thereof. |
| </li> |
| </ol></sectionDescription> |
| </sections> |
| <sections xmi:id="_iMMWoKuPEdmhFZtkg1nakg" name="Identify opportunities for reuse" guid="_iMMWoKuPEdmhFZtkg1nakg"> |
| <sectionDescription><p> |
| Complete the implementation by reusing code at every opportunity. |
| </p> |
| <p> |
| Identify existing code or other implementation elements that you can reuse in the portion of the <a class="elementLink" href="./../../openup_basic/workproducts/implementation,_0YoQcMlgEdmt3adZL5Dmdw.html" guid="_0YoQcMlgEdmt3adZL5Dmdw">Implementation</a>&nbsp;that you are creating or changing. A comprehensive understanding |
| of the overall design is helpful, because it is best to leverage reuse opportunities when you have a thorough |
| understanding of the proposed solution.<br /> |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_pjehkNb7Edq_LtLvi4w2yw" name="Transform design into implementation" guid="_pjehkNb7Edq_LtLvi4w2yw"> |
| <sectionDescription><p> |
| If you are using sophisticated modeling tools, you should be able to generate a portion of the required source code |
| from the model.&nbsp;Note that programming is often required to complete the implementation after the design |
| model&nbsp;has been transformed into code. |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_mFQ58KuPEdmhFZtkg1nakg" name="Write source code" guid="_mFQ58KuPEdmhFZtkg1nakg"> |
| <sectionDescription><p> |
| You should strive to reuse and/or generate code wherever possible, but you will still need to do some |
| programming.&nbsp;To do so, consider the following: |
| </p> |
| <ul> |
| <li> |
| Examine the&nbsp;requirements. Because some requirements information does not translate directly into your design |
| you should examine the requirement(s) (potentially including both the <a class="elementLink" href="./../../openup_basic/workproducts/use_case,_0VGbUMlgEdmt3adZL5Dmdw.html" guid="_0VGbUMlgEdmt3adZL5Dmdw">Use Case</a>(s) and <a class="elementLink" href="./../../openup_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html" guid="_BVh9cL-CEdqb7N6KIeDL8Q">Supporting Requirements</a>) to ensure that they are fully realized in the |
| implementation. |
| </li> |
| <li> |
| Refactor your code to improve its design.&nbsp;<a class="elementLink" href="./../../openup_basic/guidances/concepts/refactoring,_Poc7IPDzEdqYgerqi84oCA.html" guid="_Poc7IPDzEdqYgerqi84oCA">Refactoring</a>&nbsp;is a technique where you improve the quality of your code via |
| small changes. |
| </li> |
| <li> |
| Tuning the results of the existing implementation by improving performance, the user interface, security, and other |
| nonfunctional areas. |
| </li> |
| <li> |
| Adding missing details, such as completing the logic of operations or adding supporting classes and data structures |
| </li> |
| <li> |
| Handling boundary conditions. |
| </li> |
| <li> |
| Dealing with unusual circumstances or error states. |
| </li> |
| <li> |
| Restricting behavior (preventing users from executing illegal flows, scenarios, or combinations of options). |
| </li> |
| <li> |
| Adding critical sections for multi-threaded or re-entrant code.<br /> |
| </li> |
| </ul></sectionDescription> |
| </sections> |
| <sections xmi:id="_-0yzwDH4EduMqpUNhaTSRA" name="Create a build" guid="_-0yzwDH4EduMqpUNhaTSRA"> |
| <sectionDescription><p> |
| Create a new <a class="elementLink" href="./../../openup_basic/workproducts/build,_0YuXEMlgEdmt3adZL5Dmdw.html" guid="_0YuXEMlgEdmt3adZL5Dmdw">Build</a>. This might involve simply running an existing build script and/or updating an |
| existing build script. |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_ni25UKuPEdmhFZtkg1nakg" name="Evaluate the implementation" guid="_ni25UKuPEdmhFZtkg1nakg"> |
| <sectionDescription><p> |
| Verify that the implementation is fit for its purpose.&nbsp;Examine the code for its suitability to perform its |
| intended function. This is a quality assurance step that you perform in addition to testing, and it is described in |
| other tasks. Consider these strategies: |
| </p> |
| <ul> |
| <li> |
| Pair programming.&nbsp;By pairing to implement the code in the first place, you effectively evaluate the code as |
| its being written. |
| </li> |
| <li> |
| Read through the code for common mistakes. Consider keeping a checklist of common mistakes that you make, as a |
| reminder reference. |
| </li> |
| <li> |
| Use tools to check for implementation errors and inappropriate code. For example, use a static code rule checker or |
| set the compiler to the most detailed warning level. |
| </li> |
| <li> |
| Use tools that can visualize the code. Code visualization, such as the&nbsp;UML visualizations in the Eclipse IDE, |
| help developers identify issues such as excessive coupling or&nbsp;circular dependencies. |
| </li> |
| <li> |
| Perform informal, targeted code inspections. Ask colleagues to review&nbsp;small critical sections of code and code |
| with significant churn. Avoid reviewing large sections of code. |
| </li> |
| <li> |
| Use the Tester to assure the implementation is testable and understandable to testing resources. |
| </li> |
| </ul> |
| <p> |
| Improve the implementation based on the results of these evaluations. |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_q5XiIKuPEdmhFZtkg1nakg" name="Communicate significant decisions" guid="_q5XiIKuPEdmhFZtkg1nakg"> |
| <sectionDescription><p> |
| Communicate the impact of unexpected changes to the design and requirements. |
| </p> |
| <p> |
| The issues and constraints that you uncover when you implement the system must be communicated to the team. The impact |
| of issues discovered during implementation must be incorporated into future decisions. If appropriate, update use cases |
| and supporting requirements to reflect ambiguities that you identified and resolved in the implementation so they can |
| be tested and you can manage the <a class="elementLink" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">Stakeholder</a>&nbsp;expectations appropriately. Similarly, update the design to reflect |
| new constraints and issues uncovered during implementation to be sure that the new information is communicated to other |
| developers. |
| </p> |
| <p> |
| Usually, there is no need for a change request if the required change is small and the same person is designing and |
| implementing the class. That individual can make the design change directly. If the required change has a broad impact, |
| such as a change in a public operation, it may be necessary to communicate that change to the other team members |
| through a change request.<br /> |
| <br /> |
| </p></sectionDescription> |
| </sections> |
| <purpose><p> |
| The purpose of this task is to produce an implementation for part of the solution (such as a class or component), or to |
| fix one or more defects. The result is typically new or modified source code, which is generally referred to <em>the |
| implementation</em>.<br /> |
| </p></purpose> |
| </org.eclipse.epf.uma:TaskDescription> |