A Simple Unified Process

8/25/99 - Jack Harich - Go Back

This document is in progress....

---

Key Definitions

Architecture - The key partitions and their relationships of a system. At a lower level it includes the key decisions of what to use in the partitions and relationships. The Unified Process seems to define architecture as the entire design. We beg to differ - it's only the strategic design aspects. Long term, the greatest software risk is bad architecture because it reduces extensibility.

Artifact - Any significant physical item produced in the course of a project. Examples are documents, files, user manuals and built hardware. Most artifacts are never shipped because they are not the product. The old definition artifact excluded product items, and so artifacts were incidental. Artifacts are also known as work products. Careful selection of artifacts is one way the Process Manager's strategy is expressed.

Best Practice - An approach to work that is widely accepted as one of the very best ways to strike at problem root causes. Technology moves forward by discovery and adoption of new best practices. So do organizations and individuals. See DOD Best Practices for a preview of the future or Ed Yourdon's Article on Best Practices for enlightenment, which has the famous List of Top Best Practices created for the DOD in 1995:

1. Formal Risk Management
2. User Manual As Specification
3. Inspections, Reviews, and Walkthroughs
4. Metrics-Based Scheduling and Tracking
5. Binary Quality Gates at the Inch-Pebble Level
6. Program-Wide Visibility of Project Plan and Progress versus Plan
7. Defect Tracking Against Quality Targets
8. Separate Specification of Hardware and Software Functionality
9. People-Aware Management Accountability

Iteration - A bit of work done one or more times to achieve a goal, as opposed to just once. For example we may work on and show the customer a prototype 5 times before we're all satisfied it's the way to go. The value of iterations is we can do a small amount of work, get feedback, and then do more with the confidence we heading down the right road. Iterations tend to reduce rework and scrap because due to continual feedback, we tend to do more right the first time. To avoid confusion we don't use the term increment or incremental. Careful selection of iterations is a key way management's strategy is expressed.

Phase - A bit of work done over a period of time to achieve an important goal, and then move on to the next phase with a very different goal. Large work is best broken down into a phased approach. Careful selection of phases is one way the Process Manager's strategy is expressed.

Process - A collection of procedures and technogies working in harmony, and presented in a reusable framework that can be applied to different projects. It's really just a suite of best practices organized to work together. The purpose is "better" project results.

Workflow - The production of a series of related artifacts, that is designed to flow towards completion of a unifying major objective. For example the Requirements workflow produces a series of artifacts (usually documents) leading up to the objective of "Determine the right thing to build". One advantage of workflows is each can be given a manager. Another is they make planning easier.

---

Key Best Practices Used

The Unified Process very specifically supports these Best Practices per page 6 in "The Rational Unified Process" by Kruchten::

1. Develop software iteratively.
2. Manage requirements.
3. Use component-based architectures.
4. Visually model software.
5. Verify software quality.
6. Control changes to softwrae.

To these we would add:

1. Use Risk Management from day one.
2. Software should be architecture driven.
3. Schedules should be risk and depencency driven.
4. Use Structured Assembly.
5. Let Use Cases drive everything.
6. Manage quality by both validation and verification.
7. Make the process easier to use than not use. :-)
8. (any of the ones in the DOD's List of Best Practices, as listed above)

---

Phase and Workflow Diagram

Here's the top level model of the whole process. It shows at a glance what's happening over time, and shows the work relationships clearly. Each workflow produces artifacts, some of which are the product itself. The work level per workflow varies over time, as shown by the height of the blue boxes. Note how each phase has one or more iterations. Note how if we pick our workflows correctly, they can come into play for only about 2 phases, and the rest of the time are fairly dormant. This allows good resource utilization.

The first step to understanding this process is deep understanding of this model. For example, can you see how Requirements leads but overlaps Design? For a harder question, can you see why the level of work in the Assessment workflow is the way it is? (Assessment is Quality Assurance)

---

Summary of How Process Works

A good process provides a surefire approach to objective and task identification and management. The Unified Process does this with a framework of phases, iterations, workflows and artifacts. For each project you pick and choose what artifacts and iterations are approproate. At the top level you plan all this out on a grid like the one above. For detail a scheduling tool is used. The value of the process framework is a higher tendency to do correct and sufficient work the first time, leading to less scrap and rework, and more predictable milestones.

A project starts at the beginning of the Inception phase. Here Management is heavily involved in determining Requirments to flesh out just what is needed. At first these are high level, objective oriented requirements. Specific ones come later, perhaps in the second iteration of the Inception phase. For example the first Inception iteration may have the goal of "Determine high level requirements and probable feasibility". The second iteration's objective might be "Determine feasibilty, final concept, and get all stakeholder agreement."

The Elaboration phase involves much more work. A "Go" decision has been made. Emphasis shifts to somewhat finalizing Requirements and doing high level Design, aka architecture. Since architecture involves key decision, finalizing the architecture also resolves most risk. Other risks, such as staff availablity, market window timing, quality levels, etc, are met in a variety of ways as the project elaborates on the concept produced by the Inception phase. Interations are used to compose an architecture the product can be built on, while addressing wave after wave of risk. The phase and last iteration are done when all major risk is resolved and the architecture is crystal clear. Usually this involves a working system that expresses the core aspects of the architecture. Some may call it a prototype, but it's best to consider it the first version of the real thing by calling it the "architecture baseline".

In the Construction phase the iterations build upon the architectural baseline. If you've done a good job of Requirement, Design and Risk Management, the Construction phase should go smoothly. There are a variety of ways to organize the workflows here. We've used a part centric approach, expresed by the Core Tech, Part Shop and Assembly workflows. Basically Core Tech builds or supplies the crucial frameworks, tools and parts. The Part Shop builds or supplies average parts. Assembly has the domain experts who assemble parts into the product with little or no code. The phase ends when the product is code complete or further final work is best done in the customer's environment, such as when legacy data, embedded work or complex system changeover is present.

The Transition phase focuses transition to the customer's control. Actual transition may involve packaging, old system migration, hardward integration, training, or other domain specific transition work. It ends when the customer is satisfied they can begin using the product well. At this point the "project" is over.

Final Quality Assurance approval may occur at the end of the Construction phase or somewhere in the Transition phase. This depends on the domain or customer. The important thing is due to continual QA as we go, Risk Management, good Requirements and Design, and careful iterations, there should be absolutely no large quality problems that delay the schedule or upset the customer.

The Support phase is the rest of the product's lifetime. The goal of this phase is to help the customer achieve the highest reasonable level of satisfaction related to product use. The Assistance workflow involves such work as help desk, new feature requests, defect reporting, patches, version upgrades, customer satisfaction surveys, etc. To support product modifications, the other workflows are somewhat dormant but available for further work.

---

Phase Objectives

---

Workflow Objectives

---

Workflow Artifacts

---

Starting a Project Cookbook

---

How to Tune for Your Project

xxxx