A Minimal Iterative Software Development Process

This document offers a brief description of a minimal and iterative software process I adapt in my software development projects. This process is an extreme abbreviation of those activities and deliverables from the Rational™ Unified Process that directly affect a software development group. This process outline can be profitably applied in RUP, Scrum, or other iterative methods. NOTE: This version differs from the original version published at IBM developerWorks® only in my recommendation now to enter models into an OO CASE tool only if you can justify this investment of time. It is a simple truth that most models do not need to be saved—their value is only in the insights and understanding obtained from developing them.

Getting Started:   (do this once)

1.     Capture the major functional and non-functional requirements for the system.

• Express the functional requirements as use cases, scenarios, or stories.

• Capture non-functional requirements in a standard paragraph-style document.

2.     Identify the classes which are part of the domain being modeled.

3.     Define the responsibilities and relationships for each class in the domain.

4.     Construct the domain class diagram.

• This diagram and the responsibility definitions lay a foundation for a common vocabulary in the project.

5.     Capture use case and class definitions in an OO CASE tool only when they have stablilized.

6.     Identify the major risk factors and prioritize the most architecturally significant use cases and scenarios.

• It is absolutely imperative that the highest risk items and the most architecturally significant functionality be addressed in the early iterations.  You must not pick the “low hanging fruit” and leave the risks for later.

7.      Partition the use cases/scenarios across the planned iterations.

8.      Develop an Iteration plan describing each “mini-project” to be completed in each iteration.

• Describe the goals of each iteration, plus the staffing, the schedule, the risks, inputs and deliverables.

• Keep the iterations focused and limited (I prefer 2-3 weeks per iteration). In each iteration, conduct all of the software activities in the process: requirements, analysis, design, implementation and test. “Eat the elephant one bite at a time!”

For each iteration:   (repeat until done)

1.     Merge the functional flow in the use cases/scenarios with the classes in the domain class diagram.

• Produce sequence diagrams at the analysis level.

2.     Test and challenge the sequence diagrams on paper, or whiteboard.

• Discover additional operations and data to be assigned to classes.

• Validate the business process captured in the flow of the sequence diagram.

3.     Develop state machine diagrams for classes with “significant” state.

• State machine events, actions, and most activities will become operations on the corresponding class.

4.     Enhance sequence diagrams and state machine diagrams with design level content.

• Identify and add to the class diagram and sequence diagrams any required support or design classes (e.g. collection classes, GUI and other technology classes, etc.)

5.     Challenge the sequence diagrams on paper/whiteboard, discovering additional operations and data assigned to classes.

6.     Update the OO CASE tool information as models stabilize, and if the there is a good reason to save them.

• Update class diagrams: add in discovered datatypes, message names, actual functions and arguments, actual return types. These are discovered especially in the design level sequence and state machine diagrams.

• Add or modify classes as necessary.

• Republish system reports for team members.

7.     Develop the code for the use cases/scenarios in the current iteration from the current diagrams.

8.     Test the code in the current iteration.  (In a test-then-code approach this step precedes #7.)

9.     Conduct an Iteration review:

• What went wrong? What went right? Re-evaluate the iteration plan, and content of next iteration. 

• Revise the next iteration plan if necessary.

• Revise the Project Plan if necessary.

10. Conduct the next iteration, adding in the next set of use cases/scenarios, until the system is completely built.