Development Process Overview

November 10, 1998 - Jack Harich

Anything complex requires a high level overview to not only design it, but allow everyone to understand it and use it well. Here we present the key high level process diagrams and briefly discuss their content.

Project Process

A repeatable process for projects is defined mainly by standard phases, milestones and documents. There may also be standard procedures, tools, components and infrastructure. The above diagram shows the process elements for the average small project. These are the "core elements". More elements are needed for larger or different projects, or to show a product's lifecycle. The elements will also change as your process matures. To keep your process definition usable, all elements should have descriptions and criteria for when to use that element, since most are optional. Documents should have templates and examples. All processes and sub-processes should have a one page summary model.

A process definition is an organized collection of standard reusable elements.

Thus performing a defined process is just marching through the standard elements. If these elements are small in number and simple to understand and reuse, steps will proceed swiftly and rework will be minimal, resulting in short developement cycles.

Timeline

This covers a project lifecycle. Since this is typically used for product creation, we show that. However, by changing milestones and documents, and adding a Maintenance phase, the process can be used for subsystems or product versions also. Since these are essentially types of products, product and system are synonymous and are used interchangably in this document.

Phase 1 - Exploration

This phase is used to explore new concepts that lead to creating a new product. Its main goals are to define what is needed, prove that it should be done, and prove that it can be done.

Phase 2 - Planning

This phase plans remaining work at a high level. Its main goal is to reduce remaining risk

Phase 3 - Development

This phase develops the product. Its main goal is to produce a product with a high probability of success. To ensure this we split development into two parallel tracks - Construction and Readiness.

Construction builds the physical product, including packaging and documentation. Incremental phased delivery passes are used. High risks, core functionality and predecessor areas are developed first. Each pass has standardized and custom steps, such as those in the Mini Process.

Readiness watches the product grow and continually verifies its quality, correctness in meeting requirements, and "likeability" by customers. It monitors how ready it is for release, relieving the developers of this task and letting specialists do it. The "testing buddy" approach may be used. By having the readiness group continually monitor the product's state of readiness, the product will be tested as it grows and much less testing and surprises will occur late in the project. This will greatly accelerate the project.

Likeability is similar to "usability" but goes a step further by also testing how users enjoy using the product. In competitive markets high likeability is a huge advantage.

Phase 4 - Release

This phase is for final testing and product release preparation. It begins after code complete. The Readiness Review determines when the product is ready for general customer release. Since preparation for this review started in the Development phase and readiness began early in detail, this review will have great depth and confidence, and the Release phase should be short.

There could also be transition and production or support phases.

Phase 1 - Exploration Documents

Concept Proposal - Self explanatory.

Product Plan Proposal - Self explanatory.

Market Requirements - Optional, for large systems. This is a proposal subdocument. It specifies the market's needs at a higher level of abstraction than Product Requirements. For example it might say "The user needs a way to manage server connections and utilization better."

An important distinction is this states what the market wants, not what will be in the product. This allows the subsequent planning phase to look way back, all the way to the market, when building the Product Requirements document. The planners can also design a better long term product version plan to meet most of the market's needs eventually.

Phase 2 - Planning Documents

Product Requirements - Similar to an Analysis, this contains a complete or initial definition of what the product must do. Building upon our Mini Process, this document should contain:

Product Vision (may have sections such as Overview, Customers, Goals, Benefits)
Use Case List (outline form if a large number of use cases)
Major Use Case Details (goal, actors, steps, options, discussion, etc)
Trait List (traits are requirements common to many use use cases)
Major Trait Details (discussion, specifications, etc)
Risk Ranking (optional, for example what is the risk level on each use case and trait)

If the requirements are large then only the first pass and most important Use Case and Traits should be analyzed.. This will allow the Development phase to develop the complete Use Case and Traits to meet the market's needs in a Detailed Product Requirements document.

Risk Managment Plan - Start by brainstorming (at the highest level of abstraction possible) to create a list of risks. Circulate that list to your key people, face down. Have them first list the risks they can think of for five minutes, then turn the page over, read it, and see if they can think of any more. You can also consult previous documents and projects. You can include risks from the Product Requirements document, but these tend to be low level. Avoid thinking at too low a level here. This step is known as risk identification.

Next group and organize the risks. Then rank them. You can optionally quantify this with Risk Exposure, which is Schedule Impact (in days or weeks) times Occurance Probability (in percent).

Then take the Risk List, exhaustively analyze each risk, and present a resolution plan for each risk or group, with emphasis on the higher risks. As the project progresses this plan must be kept up to date. Expect lots of churn here. Since well managed projects are risk driven, higher risks are resolved early in the project. As the project rolls along lower and lower risks are addressed. By the time development approaches completion, there is very little risk left, and the project should be progressing smoothly.

Examples of generic risks are missing milestones, incomplete requirements, unstable requirements, poor time estimates, defects, unlikeability, team new to certain technologies, difficult algorithms, new algorithms, undefined or poor process, insufficient skill in certain areas, bugs in third party reusables and security.

Examples of product specific risks are files out of synch on server, socket timeout handling, broken communication handling, transaction robustness, firewall module complexities, subsystem A is hard to test, and window B may be hard to use.

See "Rapid Developement" by Steve McConnell, chapter 5 on Risk Management for details.

High Risk Resolutions - This is a collection of work used to resolve the high risks. It may include GUI prototypes, subsystem prototypes, outsourcing research, market research, algorithm research, etc.

High Level Design - This is the rough first pass of the system's logical and physical architecture. This should include a Logical Component Model and a high level Architecture Model. The first helps design the second. The second should have partitions that cover the first. Design risks should be listed and resolved. Importaint details should be covered.

Construction Plan - This specifies what will be constructed when, with details as needed, such as staffing plans, contengency plans, training plans and task elaboration. It may have Change Requests already prepared for scheduled tasks, since this is a good way to elaborate on what a task entails. Primary output is a detailed Development and Release project schedule.

Readiness Plan - This details how readiness will be monitored as the system is developed. Once development starts, a Readiness Status document is avaiable at all times. Thus the Readiness Plan is centered around how the Readiness Status document will be maintained in parallel with construction.

Phase 3 - Development Documents

Architecture Design - This takes the High Level Design from the Planning phase and, going further, shows the final architecture design(s) that will drive system development. Good architecture ensures that subsequent work will be easy, flexibility can be achieved, high reuse can be achieved, and that the project remains understandable and thus is more in control. Please note that software should be architecture driven, but projects should be risk driven. This is a crucial step that should not be short changed. Output will include:

Architecture Models showing how the system and subsystems are partitioned and collaborate.
Component Models showing the logical system organization. These are especially useful to non-programmers.
Class Models for the most important areas, such as heavyweight plugpoint framework subsystems, key subsystems, high risk areas, and first pass areas.
Narrative text as necessary for how the architecture works.
Prototypes as necessary.

Various OOAD Artifacts - In addition to Architecture Models, many other Object Oriented Analysis and Design artifacts are produced as needed. These include more Use Cases, Class Models, Sequence Diagrams, Use Case versus Actor Diagrams, State Diagrams, etc. Subsystems will use the Mini Process and thus have a full contengent of artifacts, including Use Cases.

Readiness Design - This is not easy. Here we do two main things:

Design various quality gate tests.
Determine how to map original requirements to completed system functionality.

This is to make sure we are building the system right and are building the right system. This is a subtle point many organizations miss. Part of the problem is putting too great a burden on developers by expecting them to play too many roles. That issue is partially solved by parallel Construction and Readiness.

We are following the principle "Continuously test the product as you build it" from Microsoft Secrets, page 294. To guarentee the system is continually as "ready" as possible, items like these are necessary:

Use Case Test Suite - This is a list of manual or automated tests and when to run them. One goal is to map tests to specific use cases to ensure good coverage. Another is to test "all possible" use cases, even those not in the requirements. The latter is an example of excellence.
General Test Suite - These tests cover things like integration testing, stress testing, gorilla testing, code coverage testing, etc as needed.
Full Regression Test - This tests all basic functionality and all defect fixes, should be automated, and can become huge. Some roll all their automtated tests into here for complete coverage. The Excel 5.0 testing team had 45 people and their automated regresstion test took 15 hours to run.
Likeability Test Suite - These tests cover traditional "usability" as well as "likeability". This will require testing with average users at many stages in the product's growth, so actually running these tests is a lot of work. Typically this is done in batches, and developers eagerly attend to see how their stuff holds up.
Requirements Mapping - The goal of mapping requirements to production is to double check that what we planned to happen has happened. In large systems and dynamic projects this becomes difficult, not to mention forgotten. This document exhaustively lists all requiremnts and maps each to where it was implemented or resolved, and how well. This is done for Use Cases, Traits and Risks.

Readiness Status - This quickly becomes the barometer for the Development and Release phases. It shows what functionality is complete, what has been tested, test results, open defects, likeability results, mapping status, etc. A summary shows where the product really is at a glance. This document should be current at least weekly in the Development phase and daily in the Release phase. Automation will allow daily or real time status.

Phase 4 - Release Documents

Beta Test Plan - This details how the product will be beta tested. This includes who is testing, feedback and defect collection channels, observed testing, open defects, beta version release plan, how it feeds into Readiness Status, etc.

Readiness Status - This is also the barometer for the Release phase. It shows the Best Test Plan status and how close to Gold Release the product is. Given the shortness of the Release phase, this should be current daily. For large projects an effective tool is a graph of time versus defects. This can start in the Development phase. Gold is reached when the graph falls to a very acceptable level. The graph can help plan maintenance releases.

Project Post Mortem - After popping the champaign and flying gold CDs around the room, the team should take the time to prepare a review of what they did right and wrong, what they learned, and how to do better. The document should have a section on conclusions and suggested improvements.

Serious types will even have a plan to implement the accepted improvements. In this manner an organization can have a gigantic feedback loop and formally learn from each project. This phenomenon is called a "learning organization". Of course much of this occurs as the project progresses.

System Task Pipeline

Since most work is in the System Task Pipeline, it needs to be as efficient and effective as possible.

The pipeline runs from scheduled or unscheduled tasks all the way to when a change is injected into the system. Pipeline activity starts in the Development phase as the actual system begins to be built, although some may start in the Planning phase if prototypes are used. Since approximately 75% of all software work is maintenance, and most of a project's work is on scheduled tasks, the pipeline must be superb.

The diagram shows how specific tasks are formally handled. The objective is to have a formal but easy way to specify, schedule, and track all changes to the system. This introduces the ability to control system changes well, such as new features, bug fixes, last minute changes, feature backouts, etc. By simply monitoring where in the pipeline a change is, it can be reliably tracked and shown on the rather useful Readiness Status document.

Pipeline Narrative

A task enters the process as a Scheduled Task or as an Unscheduled Task, such as a bug fix or enhancement. It is turned into a Change Request (CR) so the process can handle it like an object. A CR contains one or more requests. For example a CR may have a single rush request or six related Use Cases that need implementing.

Simple changes can skip Analysis and Design and go directly to a Change Proposal. Others will require serious high quality Analysis and Design to do well.

The Change Proposals accumulate and must pass a Controlled Injection Review before proceeding. This step allows the team to introduce only high quality changes into the system, and serves as a good educational forum. Most Change Proposals move through this step swiftly. Small ones, such as minor enhancements and bug fixes, can do it in minutes via instant virtual electronic meetings.

In the case of emergency changes, such as bug fixes in the Final Pass or Release phase, there will be a large temptation to skip reviews. Don't do this. Instead, keep calm and realize that in complex systems each bug fix introduces approximately 0.5 more bugs. Even in simple systems the chance of a ripple effect is more than zero. So in a day with 10 bug fixes and enhancements, the chance of introducing further problems is very high. This is why reviews are needed. Also note that during a final push your less senior developers will be participating heavily.

Once a Change Proposal is implemented, its status is changed to Implemented.