| Project Management: Plan the iteration. | The Project Manager updates the Iteration Plan based on any new functionality that 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 (Artifact: Iteration Plan and Artifact: Risk List). |
| Implementation: Plan system-level integration. | Integration planning takes into account the order in which subsystems are to be put together to form a working and testable configuration. The choice depends on the functionality already implemented and on the aspects of the system that must be in place to support the overall integration and test strategy. This is done by the System Integrator, and the results are documented in the Build Plan (Artifact: Integration Build Plan). The Integration Build Plan defines the frequency of builds and describes 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 (Artifact: Test Cases) to verify testable requirements. The Test Designer must identify and describe Test Cases and identify and structure Test scripts and test suites. In general, each Test Case has at least one associated Test Script. The Test Designer also reviews the accumulated body of tests from preceding iterations, which could be modified to be reused in regression testing for current and future iteration builds (Artifact: Test Scripts). |
| Analysis and Design: Refine use-case realizations. | Designers refine the classes identified in previous iterations by allocating responsibilities to specific classes and updating their relationships and attributes. Classes may need to be added to support design and implementation constraints. Changes to classes may require a change in subsystem partitioning. |
| Test: Plan and design integration tests at the subsystem and system levels. | Integration tests focus on the degree to which developed components interface and function together. The Test Designer follows 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 must be developed to support the integration tests. The Implementer develops the stubs and drivers based on the input from the Test Designer. |
| Implementation: Develop code and test unit. | In accordance with the project's programming guidelines, Implementers develop code to implement the classes in the Implementation Model. They fix defects and provide feedback that might lead to design changes based on discoveries made in implementation. |
| Implementation: Plan and implement unit tests. | The Implementer designs unit tests that address what the unit does (the black-box test) and how it does it (the white-box test). Under black-box (specification) testing, the Implementer must be sure that the unit, in its various states, performs to its specification and can 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 implemented correctly and that the unit can be traversed through each of its decision paths. |
| Implementation: Test unit within a 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 produces the expected results and that the unit conforms to the project's adopted quality and development standards. |
| Implementation and Test: Integrate a subsystem. | The purpose of subsystem integration is to combine into an executable build set units that may come from many developers within the subsystem (part of the implementation model). In accordance with the plan, the Implementer integrates the subsystem by bringing together completed and stubbed classes that constitute a build. The Implementer integrates the subsystem incrementally from the bottom up based on the compilation dependency hierarchy. |
| Implementation: Test a subsystem. | Testers execute Test Procedures developed earlier. If there are unexpected test results, Integration Testers log the defects for arbitration to decide when they are to be fixed. |
| Implementation: Release a subsystem. | Once the subsystem has been tested sufficiently 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 the system. | The purpose of system integration is to combine the 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. |
| Test: Test integration. | Integration Testers execute Test Procedures developed earlier. The Integration Testers execute integration tests and review the results. If there are unexpected results, the Integration Testers log the defects. |
| Test: Test the system. | Once the whole system (as defined by the goal of this iteration) has been integrated, the System Tester tests the system. The Test Designer then analyzes the results of the test to make sure that the testing goals have been reached. |
| Project Management: Assess the iteration itself. | The Project Manager compares the iteration's actual cost, schedule, and content with the Iteration Plan; determines whether rework is necessary and, if so, assigns it to future iterations; updates the Risk List (Artifact: Risk List); updates the Project Plan (Artifact: Project Plan); and prepares an outline of an Iteration Plan for the next iteration (Artifact: Iteration Plan). |
