| <?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\capabilitypatterns\construction_phase_iteration\content.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: content.xmi<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: presentationName<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:presentationName,_y-3IrutQEdqc1LGhiSPqRg CRC: 1846029888 -->Construction Phase Iteration<!-- END:presentationName,_y-3IrutQEdqc1LGhiSPqRg --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: briefDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:briefDescription,_y-3IrutQEdqc1LGhiSPqRg CRC: 1899401464 -->This iteration template defines the activities (and associated roles and work products) performed in a typical iteration in the Construction phase. Each activity and its goals is described.<!-- END:briefDescription,_y-3IrutQEdqc1LGhiSPqRg --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: mainDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:mainDescription,-239OBD2wagT2qp8fuPWcHQ CRC: 2393740895 --><h3> |
| Introduction |
| </h3> |
| Iterations in Construction phase have a work breakdown structure (WBS) similar to iterations in the Elaboration phase, with |
| activities happening in parallel. There is a different emphasis on how activities address the phase objectives, |
| though. |
| <p> |
| The <a href="./../../openup_basic/workproducts/architecture,_0XAf0MlgEdmt3adZL5Dmdw.html" guid="_0XAf0MlgEdmt3adZL5Dmdw">architecture</a> is expected to be stable when this phase starts, allowing the remaining |
| requirements to be implemented on top of it. Another advantage of validating the architecture and eliminating as many |
| risks as possible during Elaboration is to provide more predictability in Construction, which allows the <a class="elementlinkwithusertext" href="./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html" guid="_0a0o0MlgEdmt3adZL5Dmdw">project manager</a> to focus on team efficiency and cost reduction. |
| </p> |
| <p> |
| Functionality is continuously implemented, tested, and integrated, resulting in <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/build,_0YuXEMlgEdmt3adZL5Dmdw.html" guid="_0YuXEMlgEdmt3adZL5Dmdw">builds</a> |
| that are more and more complete and stable. A beta or prerelease may be deployed to a sampling of the intended audience |
| at the end of Construction. Delivery of the actual release is the main focus of the next phase. |
| </p> |
| <p> |
| The activities performed in a typical iteration during Construction phase are described after the following |
| introductions to each activity. |
| </p> |
| <h4> |
| Manage iteration |
| </h4> |
| <p> |
| This activity is performed throughout the project lifecycle. The goal of this activity is to identify risks and issues |
| early enough to mitigate them, to establish the goals for the iteration, and to support the development team in |
| reaching these goals. |
| </p> |
| <p> |
| Similarly to other phases, the project manager (supported by the team) launches the iteration, allocates work, tracks |
| status, and handles issues and risks. Although the high-priority and architecturally significant risks were mitigated |
| during Elaboration, new risks may appear during Construction, such as not having the right amount of resources to |
| obtain the desired degree of parallel development. |
| </p> |
| <p> |
| The prioritization of work for a given iteration (existing change requests and possibly a few remaining requirements) |
| takes place. project manager, <a class="elementlinkwithusertext" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">stakeholders</a>, and the remaining team members agree on what is supposed to be |
| developed during that iteration. |
| </p> |
| <p> |
| At the end of the iteration, the team performs an iteration assessment. The goal is to conduct a retrospective review |
| of the iteration that is ending. As part of this assessment, the objectives for the Construction phase are expected to |
| be demonstrated by the beta-quality release of the software, thus supporting the possibility of transitioning the |
| software to its end users. |
| </p> |
| <h4> |
| Manage requirements |
| </h4> |
| <p> |
| This activity is repeated throughout the lifecycle. The goal of this activity is to understand and prioritize |
| stakeholder needs and associated requirements for the system, as well as to capture these in a form that will support |
| effective communication and collaboration between the stakeholders and the development team. |
| </p> |
| <p> |
| During Inception, most requirements are captured. The high-risk requirements are detailed, implemented, and validated |
| (through a working architecture) during Elaboration. |
| </p> |
| <p> |
| During the Construction phase, requirements management demands less time from the <a class="elementlinkwithusertext" href="./../../openup_basic/roles/analyst,_0VxJsMlgEdmt3adZL5Dmdw.html" guid="_0VxJsMlgEdmt3adZL5Dmdw">analyst</a>. |
| There still may be low-risk requirements to be detailed or refined, but in a way that can be assigned to <a class="elementlinkwithusertext" href="./../../openup_basic/roles/developer,_0YDosMlgEdmt3adZL5Dmdw.html" guid="_0YDosMlgEdmt3adZL5Dmdw">developers</a>. |
| </p> |
| <p> |
| <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/test_case,_0ZS-0MlgEdmt3adZL5Dmdw.html" guid="_0ZS-0MlgEdmt3adZL5Dmdw">Test cases</a> describe which requirements are being tested in that iteration. |
| </p> |
| <h4> |
| Develop solution |
| </h4> |
| <p> |
| This activity is repeated multiple times, in parallel, for each development task planned for that iteration. The main |
| goal of this activity is an executable system that provides the incremental quality and functionality for the specified |
| requirements, within the specified context. |
| </p> |
| <p> |
| The architecture was proposed and a baseline established at the end of Elaboration. Critical requirements were |
| expected to be implemented, tested, and integrated as part of the baseline architecture. As the remaining requirements |
| are implemented during Construction, the Architect identifies commonalities among solutions being developed by the |
| various developers and leverages reuse where possible. Some degree of refactoring of the architecture may be needed to |
| accommodate putting common pieces together. |
| </p> |
| <p> |
| A pattern similar to the Elaboration phase happens during Construction when it comes to breaking down requirements into |
| development tasks and assigning each requirement within a context to a developer. Requirements at this stage are mostly |
| of medium-to-low level of risk, but usually they represent the largest slice from the total amount of requirements to |
| be implemented in a project. Thus, it is expected that this activity is repeated, or instantiated, multiple times (once |
| per requirement within context), thus allowing parallel development. <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/guidelines/continuous_integration,_i8bUEL6cEdqti4GwqTkbsQ.html" guid="_i8bUEL6cEdqti4GwqTkbsQ">Continuous integration</a> allows functionality to be added to the code base constantly, |
| which helps the achievement of more and more complete <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/build,_0YuXEMlgEdmt3adZL5Dmdw.html" guid="_0YuXEMlgEdmt3adZL5Dmdw">builds</a> |
| of the software. |
| </p> |
| <h4> |
| Validate build |
| </h4> |
| <p> |
| This activity is repeated throughout the project lifecycle. The main goal of this activity is to validate the current |
| increment of the system against the requirements allocated to it. |
| </p> |
| <p> |
| Similarly to Elaboration, this activity happens in parallel with the <a class="elementLinkWithUserText" href="./../../openup_basic/capabilitypatterns/develop_solution,_h2-iAfimEdmugcVr9AdHjQ.html" guid="_h2-iAfimEdmugcVr9AdHjQ">develop solution</a> activity. The intent is to validate that a stable beta release is |
| achieved and that users can perform acceptance tests. |
| </p> |
| <h4> |
| Ongoing tasks |
| </h4> |
| <p> |
| Similarly to any other phase, <a class="elementlinkwithusertext" href="./../../openup_basic/roles/any_role,_0dsWoMlgEdmt3adZL5Dmdw.html" guid="_0dsWoMlgEdmt3adZL5Dmdw">any role</a> on |
| the team can submit <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/guidelines/change_requests,_fnZj0NVXEdqy9sbRhejO5Q.html" guid="_fnZj0NVXEdqy9sbRhejO5Q">change requests</a>. The software being developed is achieving beta quality by this |
| point; therefore, defects of high priority are generally addressed during Construction iterations and |
| Transition iterations. Enhancement requests can be planned for either subsequent Transition iterations or a next |
| release of the product. |
| </p><!-- END:mainDescription,-239OBD2wagT2qp8fuPWcHQ --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: presentationName<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:presentationName,_y-k0bOtQEdqc1LGhiSPqRg CRC: 1824416172 -->Plan and Manage Iteration<!-- END:presentationName,_y-k0bOtQEdqc1LGhiSPqRg --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: presentationName<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:presentationName,_eE5nEUbpEduLBN1xMBngqw CRC: 2084512818 -->Manage Requirements<!-- END:presentationName,_eE5nEUbpEduLBN1xMBngqw --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: briefDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:briefDescription,_eE5nEUbpEduLBN1xMBngqw CRC: 2015390557 -->Detail a set of requirements (one or more use cases, scenarios, or supporting requirements).<!-- END:briefDescription,_eE5nEUbpEduLBN1xMBngqw --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: presentationName<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:presentationName,_MWFjoU9HEdudU75l2xOQTw CRC: 2237470038 -->Develop Solution (for requirement) (within context)<!-- END:presentationName,_MWFjoU9HEdudU75l2xOQTw --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: briefDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:briefDescription,_MWFjoU9HEdudU75l2xOQTw CRC: 1575460021 -->Design, implement, test and integrate the solution for a requirement within a given context.<!-- END:briefDescription,_MWFjoU9HEdudU75l2xOQTw --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: mainDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:mainDescription,-q-X9OHGNRjU5gIyWVibSGQ CRC: 4065423054 --><h3> |
| Introduction |
| </h3> |
| <p> |
| Project managers use this Capability Pattern as a way to perform a goal-based planning and management. Work |
| is assigned to developers and work progress is tracked based on the goals to be achieved using the designed, |
| unit-tested, and integrated source code. |
| </p> |
| <h4> |
| Context of what is being developed |
| </h4> |
| <p> |
| A context can be specified when a requirement is assigned to be developed, thus specifying how broadly a requirement is |
| to be developed in a iteration. Development may focus on a layer (such as the user interface, business logic, |
| or database access), on a component, and so on. |
| </p> |
| <p> |
| Whether a context is specified or not, the developer's responsibility is to create a design and implementation for that |
| requirement, then to write and run unit tests against the implementation to make sure the implementation |
| works as designed, both as a unit and integrated into the code base. |
| </p> |
| <h4> |
| Overview of workflow |
| </h4> |
| <p> |
| To accommodate major changes or major functionality to be developed, architecture may have to be refined. Small |
| changes and functionality may reflect changes on the design only, with no need to refine the architecture. For trivial |
| changes and functionality to be developed, only the source code may be affected. |
| </p> |
| <p> |
| In any case, there is no strict sequence for how writing code and creating or running developer tests should |
| happen, because they can happen in parallel. You may choose to create and run developer tests before the actual |
| code is created or the reverse sequence. |
| </p><!-- END:mainDescription,-q-X9OHGNRjU5gIyWVibSGQ --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: purpose<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:purpose,-q-X9OHGNRjU5gIyWVibSGQ CRC: 2872432095 --><ul> |
| <li> |
| For developers: To create a solution for the requirement assigned to them |
| </li> |
| <li> |
| For project managers: To have a goal-based way of assigning work and tracking project status |
| </li> |
| </ul><!-- END:purpose,-q-X9OHGNRjU5gIyWVibSGQ --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: usageNotes<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:usageNotes,-q-X9OHGNRjU5gIyWVibSGQ CRC: 1279855432 --><p> |
| This Capability Pattern occurs multiple times during each iteration. Usually, there is one instance for each |
| requirement planned for that iteration. When instantiated in a project plan, the pattern becomes a development task to |
| be assigned to a developer, and it should be renamed to include the actual requirement name. Optionally, the word |
| <strong>Solution</strong> may be suppressed, then you can instantiate the pattern this way: |
| </p> |
| <blockquote> |
| <p align="left"> |
| Develop <font face="Courier New, Courier, mono">requirement_name</font> (within <font face="Courier New, Courier, mono">context_name</font> context) |
| </p> |
| </blockquote> |
| <p> |
| If a context is specified, there will be one instance of this pattern for each requirement for each |
| context. |
| </p> |
| <blockquote> |
| <p> |
| <strong>Example</strong> |
| </p> |
| <ol> |
| <li> |
| Develop <font face="Courier New, Courier, mono">scenario 1</font> (within <font face="Courier New, Courier, mono">user interface</font> context) |
| </li> |
| <li> |
| Develop <font face="Courier New, Courier, mono">scenario 1</font> (within <font face="Courier New, Courier, mono">business logic and DB access</font> context) |
| </li> |
| <li> |
| Develop <font face="Courier New, Courier, mono">scenario 2</font> |
| </li> |
| <li> |
| Develop <font face="Courier New, Courier, mono">supplemental requirement 1</font> |
| </li> |
| </ol> |
| </blockquote> |
| <p> |
| Note that there are four instances of this pattern in the preceding example: |
| </p> |
| <ul> |
| <li> |
| The first two are related to the same requirement (scenario 1) but within two different contexts |
| </li> |
| <li> |
| The last two are related to different requirements, with no context specified. |
| </li> |
| </ul><!-- END:usageNotes,-q-X9OHGNRjU5gIyWVibSGQ --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: presentationName<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:presentationName,_y-3IretQEdqc1LGhiSPqRg CRC: 79270194 -->Validate Build<!-- END:presentationName,_y-3IretQEdqc1LGhiSPqRg --> |
| </body> |
| </html> |