Activity: Develop the Solution |  |
Design, implement, test and integrate the solution for a requirement within a given context.
Extends: Develop Solution (for requirement) (within context)
| Description |  | Work Breakdown Structure |  | Team Allocation |  | Work Product Usage |  |
Purpose
For developers: To create a solution for the work item for which they are responsible For project managers: To have a goal-based way of tracking project status
Relationships
Parent Activities | Develop the Architecture
Description
### Introduction Run this activity as a way to perform a goal-based planning and execution. Work is taken on by developers and work progress is tracked based on the goals achieved using the designed, developer-tested, and integrated source code. #### Context of what is being developed 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. Whether a context is specified or not, the developer's responsibility is to create a design and implementation for that requirement, and also to write and run developer tests against the implementation to make sure it works as designed, both as a unit and integrated into the code base. #### Overview of workflow Typical changes require some effort in designing the solution before moving into the implementation, even if it is only a mental exercise that results in no long-term work product. Trivial changes to the existing implementation to support some requirement might have their design self-evident in the context of the existing architecture and design. Once the organization of the technical solution is clear, developer tests are defined that will verify the implementation. This test-driven approach enforces that design considerations have been done before the solution is coded. The tests are run up front and, in failing, clearly define the criteria to determine if the implementation works as intended. Failed tests lead to the implementation of the solution which upon completion causes the tests to be run again. This innermost loop is repeated until the tests pass. Passing the tests does not necessarily mean that the solution is a high-quality, appropriate solution. It is proper to revisit the design at this point. That path loops back through the process since any changes to the design could affect the developer tests and implementation. Once the tests are passing and the design of the solution is deemed appropriate, there is one more possible loopback. It is best to keep the test-driven, evolutionary design inner loops as tight as possible. Come up with some small-scale design solution for a part of the work item, define a test or two for the implementation of one part of the solution, pass that test, verify the quality, and then continue on in a test-first manner until that part of the design is working. Then in the outermost loop go back to the work item and design another chunk to get closer to completion.
Properties
Event-Driven |
Multiple Occurrences |
Ongoing |
Optional |
Planned |
Repeatable |
This program and the accompanying materials are made available under the Eclipse Public License v1.0 which accompanies this distribution. OpenUP Copyright. OpenUP/DSDM Copyright.