Characteristics, Risk, and Project Phases

This section outlines the advantages of iterative development processes. See the sections on UML and the Rational Unified Process or extreme programming for more about iterative development.

Project Characteristics

Characteristics of projects:

Unhealthy projects lack rhythm which is provided by the iterative process.
The iterative process is directed considering risks.
Need skillful planning and solid requirements definition to build a good system.
The iterative process establishes the basic and main functional requirements and works its way out to additional requirements.

Risk

Risk is critical when two or more of the following are changed:

The system requirements
The technology used
The team
The program design methods or management methods.
The development language
The operating system and hardware platform
The tools

Risk management must be done repetitively during the project lifecycle. Four phases of risk management:

Identification - Identify all project risks
Analysis - Reduce the risk identification to the most probable ten that will affect the project based on:

Chance of occurance.
Impact on the project
During the project lifecycle, when it will occur.

Planning - Plan the response to be used in the event of risk materialization.

Control - Implement the risk response.

The Overall Process

The overall project process when dealing with iterative design processes includes the below phases. Iterative design assumes that complete project requirements are not available at the start of the project or the requirements will change.

Conceptualization (Normally 1 month for a 12 month project) - A proof of concept is built to limit risk. Core requirements are established. Generate:

A broad and shallow throw away prototype. The prototype needs goals and a specific time limit.
General project requirements.
Risk assessment.

Analysis (Normally 1-2 months for a 12 month project) - Users and domain experts explore scenarios and a common understanding (terms are defined) about the system functions. Generate:

System context and description to establish project boundaries.
Determine a collection of use case scenarios to establish desired system behavior.
Domain model - A domain model is used to determine relationships between subcomponents of the system. When dealing with object oriented softare design, the domain model includes candidate classes. Don't get too detailed with scenarios when building a domain model.
Revised risk assessment, CRC cards, scenario diagrams indicate message flow.
The system architecture is defined.

Questions answered during this phase:

How will the system interact to other systems?
What main functions should the system support?
For each function, what system primary behaviors are desired?
For each primary behavior, what exceptions may occur?
How will subsections of the system or software classes support the system desired behaviors?
Has asking and answering these questions revised our risk assessment?

Four to six people are used for analysis, including the system architect.

Big architectural patterns are used to determine the system basic frame. Considerations are:

Central or distributed platform
Message based architecture or time slice frame architecture.

Consider what may change and how to use existing products.

Design (Normally 1-2 months for a 12 month project) - Design toward an 80% project solution. The following tasks should be done during this phase:

A skeleton system is made.
Release plan is developed.
System test criteria are determined.
Risk assessment is revised.

Build a horizontal or vertical slice of the system that most effectively eliminates risk. The following are done during this phase:

Continued architectural planning - Build the basic prototype. Focus on:

Interfaces - How subsystems interface and/or how objects interface between each other.
Responsibilities of each subsystem or object and class of objects.
Patterns - Design methods which are standard for software and are used to solve known common problems.

Tactical design - How the design will work. What existing software is used.
Release planning - Plan the evolutionary phase product releases around the iterations. There is not normally a release for each iteration, but may be between three to seven releases.

Warning signs during design:

Architectural prototype is slow and has an extra large size.
The project is growing in complexity.
There is a large amount of code for each scenario.

Set the project rhythm near the end of the design phase. Design teams should be no more than seven to ten. If more staff is required, have a core design team control the project with several teams built around the core team.

Evolution (Normally 9 months for a 12 month project) - Refinement and additional requirements. There should be three to seven releases during this phase. Each release provides a stable from to grow more functionality from. For large projects the executable release may happen in intervals of six to nine months. For moderate projects it would happen in intervals of two to three months. There are many small functional integrations. Don't allow the team to be jerked around as requirements change or new problems arise. Management sorts and priortizes. This phase produces:

Prototypes
Several executable releases.
Documentation
Results of quality assurance checking.

Maintenance - At this point there should be no major changes to the system. If you've done your project well, this is where your investment will pay off. You should have a low maintenance system or a flexible system. There may be some maintenance procedures for the equipment.

Iterations

Can have secondary small teams (20% of team) or individuals examine technologies and build test prototypes to see if technologies can be used in the main design.

Throw away 10% to 20% of code for each iteration. If more than 30% of the work is trashed at the end of the first iteration, the system architecture is not stable. Sizes of changes:

Minor - Change affects a few classes. The owner of the class should make the change.
Modest - The change affects one or two class categories. The collaboration of class owners make the change.
Major - The change affects three or more class categories. This should not normally happen, but if it does, use a tiger team to make the changes.