Implement the System (Late Iteration in the Construction Phase)
Context
Some of the characteristics of the late construction phase are that requirements are stable, and a great deal of the functionality has been implemented and integrated in preparation for test.
Workflow
Project Management: Plan the Iteration. |
The project manager updates the iteration plan based on what new functionality is to be added during the new iteration, factoring in the current level of product maturity, lessons learned from the previous iterations, and any risks that need to be mitigated in the upcoming iteration (see Artifact: Iteration Plan and Artifact: Risk List). |
Implementation: Plan system-level integration. |
Integration planning takes into account the order in which functional units are to be put together to form a working/testable configuration. The choice depends on the functionality already implemented, and what aspects of the system need to be in place to support the overall integration and test strategy. This is done by the system integrator (see Workflow Detail: Plan the Integration within an Iteration in the Implementation workflow), and the results are documented in the Artifact: Integration Build Plan. The Integration Build Plan defines the frequency of builds and when given 'build sets' will be required for ongoing development, integration, and test. |
Test: Plan and design system-level test. |
The test designer ensures that there will be an adequate number of test cases and procedures to verify testable requirements (see Workflow Detail: Plan and Design Integration Test and Workflow Detail: Plan and Design System Test in the Test workflow). The test designer must identify and describe the test cases, and identify and structure the test procedures. In general, each test case will have at least one associated test procedure. The test designer should review the accumulated body of tests from preceding iterations, which could be modified and therefore available for re-use in regression testing for the current and future iteration builds. |
Analysis & Design: Refine Use-Case Realizations. |
Designers refine the model elements identified in previous iterations by allocating responsibilities to specific model elements (classes or subsystems) and updating their relationships and attributes. New elements may also need to be added to support possible design and implementation constraints (see Workflow Detail: Elaborate the Design) Changes to elements may require changes in package and subsystem partitioning (see Workflow Detail: Define the Architecture). Results of the analysis need to be followed by review(s). |
Test: Plan and design integration tests at the subsystem and system level. |
Integration tests focus on how well, developed components interface and function together. The test designer needs to follow the test plan that describes the overall test strategy, required resources, schedule, and completion and success criteria. The designer identifies the functionality that will be tested together, and the stubs and drivers that will need to be developed to support the integration tests. The implementer develops the stubs and drivers based on the input from the test designer (see Workflow Detail: Implement Integration Test and Workflow Detail: Implement System Test in the Test workflow). |
Implementation: Develop Code and Test Unit |
Implementers develop code, in accordance with the project's programming guidelines, to implement the Artifact: Components in the implementation model. They fix defects and provide any feedback that may lead to design changes based on discoveries made in implementation (see Workflow Detail: Implement Classes Within an Iteration in the Implementation workflow). |
Implementation: Plan and Implement Unit Tests. |
The implementer needs to design unit tests so that they address what the unit does (black-box), and how it does it (white-box). Under black-box (specification) testing the implementer needs to be sure that the unit, in its various states, performs to its specification, and can correctly accept and produce a range of valid and invalid data. Under white-box (structure), testing the challenge for the implementer is to ensure that the design has been correctly implemented, and that the unit can be successfully traversed through each of its decision paths (see Workflow Detail: Implement Classes Within an Iteration in the Implementation workflow). |
Implementation: Test Unit within Subsystem. |
Unit Test focuses on verifying the smallest testable components of the software. Unit tests are designed, implemented, and executed by the implementer of the unit. The emphasis of unit test is to ensure that white-box testing produce the expected results, and that the unit conforms to the project's adopted quality and development standards. |
Implementation and Test: Integrate Subsystem. |
The purpose of subsystem integration is to combine units that may come from many different developers within the subsystem (part of the implementation model), into an executable 'build set'. The implementer in accordance with the plan integrates the subsystem by bringing together completed and stubbed classes that constitutes a build (see Workflow Detail: Integrate Each Subsystem Within an Iteration in the Implementation workflow). The implementer integrates the subsystem incrementally from the bottom-up based on the compilation-dependency hierarchy. |
Implementation: Test Subsystem. |
Testers execute test procedures developed in accordance with activities identified in Steps 3 and 5 (see Workflow Detail: Execute Integration Test in the Test workflow). If there are any unexpected test results, integration testers log the defects for arbitration on when they are to be fixed. |
Implementation: Release Subsystem. |
Once the subsystem has been sufficiently tested and it is ready for integration at the system level, the implementer 'releases' the tested version of the subsystem from the team integration area into an area where it becomes visible, and usable, for system-level integration. |
Implementation: Integrate System. |
The purpose of system integration is to combine the currently available implementation model functionality into a build. The system integrator incrementally adds subsystems, and creates a build that is handed over to the integration testers for overall integration testing (see Workflow Detail: Integrate the System within an Iteration in the Implementation workflow). |
Test: Test Integration |
Integration testers execute test procedures developed in accordance with activities identified in Steps 3 and 5. The integration testers execute integration tests and review the results. If there are any unexpected results, the integration testers log the defects (see Workflow Detail: Execute Integration Test in the Test workflow) . |
Test: Test System |
Once the whole system (as defined by the goal of this iteration) has been integrated, the system tester tests the system (see Workflow Detail: Execute System Test in the Test workflow). The test designer will then analyze the results of the test to make sure the testing goals have been reached (see Workflow Detail: Evaluate System Test in the Test workflow). |
Project Management: Assess the iteration itself. |
Lastly, the project manager compares the iteration's actual cost, schedule, and content with the iteration plan; determine if rework needs to be done, and if so, assign to future iterations; update the risk list (see Artifact: Risk List); update the project plan (see Artifact: Project Plan); prepare an outline of an iteration plan for the next iteration (see Artifact: Iteration Plan). Productivity figures, size of code, or and size of database might be interesting to consider here. |
Result
The main result of a late iteration in the construction phase is that more functionality is added, which yields an increasingly more complete system. The results of the current iteration are made visible to developers to form the basis of development for the subsequent iteration.
