Process Essentials

Topics

Introduction

The key to achieving the delicate balance between delivering quality software and delivering it quickly (the software paradox!) is to understand the essential elements of the process and to follow certain guidelines for tailoring the process to best fit your project's specific needs. This should be done while adhering to the best practices that have been proven throughout the industry to help software development projects be successful.  

The following describes the essential principles of an effective software process.

1. Vision-Develop a Vision

In particular, developing a clear Vision is key to developing a product that meets your  stakeholders' real needs".

In RUP, the Vision artifact captures very high-level requirements and design constraints, to give the reader an understanding of the system to be developed. It provides input to the project-approval process, and is therefore intimately related to the Business Case. It communicates the fundamental "why's and what's" related to the project and is a gauge against which all future decisions should be validated.

The contents of the Vision-along with any other related requirements artifacts-should answer the following questions, which might be broken out to separate, more detailed, artifacts, as needed:

• What are the key terms? (Glossary)
• What problem are we trying to solve? (Problem Statement)
• Who are the stakeholders? Who are the users? What are their needs?
• What are the product features?
• What are the functional requirements? (Use Cases)
• What are the non-functional requirements?
• What are the design constraints?

Developing a clear vision and an understandable set of requirements is the essence of the Requirements discipline, and the Best Practice: Manage Requirements. This involves analyzing the problem, understanding stakeholder needs, defining the system, and managing the requirements as they change.   

2. Plan-Manage to the Plan

"The product is only as good as the plan for the product" (FIS96).

Conceiving a new project; evaluating scope and risk; monitoring and controlling the project; planning for and evaluating each iteration and phase - these are the "essence" of the Project Management discipline.

A Software Development Plan gathers the information required to manage the project. It is used to plan the project schedule and resource needs, and to track progress against the schedule. It addresses such areas as:  project organization, schedule, budget, and resources. It may also include plans for requirements management, configuration management, problem resolution, quality assurance, evaluation and test, and product acceptance.

In a simple project, many of these topics can be covered by one or two sentences each. For example, configuration management planning may simply state: "At the end of each day, the contents of the project directory structure will be zipped, copied onto a dated, labeled zip disk, marked with a version number and placed in the central filing cabinet."

The format of the planning artifacts are not as important as the planning activities and the thought that goes into them.  It doesn't matter what the plans look like - or what tools you use to build them.  As Dwight D. Eisenhower said, "The plan is nothing; the planning is everything."

3. Risks-Mitigate Risks and Track Related Issues

It is essential to identify and attack the highest risk items early in the project and track them, along with other related issues.  The Risk List is intended to capture the perceived risks to the success of the project. It identifies, in decreasing order of priority, the events which could lead to a significant negative outcome.

Along with each risk, should be a plan for mitigating that risk.  This serves as a focal point for planning project activities, and is the basis around which iterations are organized.

4. Business Case-Examine the Business Case

The Business Case provides the necessary information, from a business standpoint, to determine whether or not this project is worth investing in.

The main purpose of the Business Case is to develop an economic plan for realizing the project Vision. Once developed, the Business Case is used to make an accurate assessment of the return on investment (ROI) provided by the project. It provides the justification for the project and establishes its economic constraints. It provides information to the economic decision makers on the project's worth, and is used to determine whether the project should move ahead.

The description should not delve deeply into the specifics of the problem, but rather it should create a compelling argument why the product is needed. It must be brief, however, so that it is easy enough for all project team members to understand and remember. At critical milestones, the Business Case is re-examined to see if estimates of expected return and cost are still accurate, and whether the project should be continued

5. Architecture-Design a Component Architecture

In the Rational Unified Process (RUP), the architecture of a software system (at a given point) is the organization or structure of the system's significant components interacting through interfaces, with components composed of successively smaller components and interfaces. What are the main pieces? And how do they fit together?  Do we have a framework on which the rest of the software can be added?

To speak and reason about software architecture, you must first define an architectural representation, a way of describing important aspects of an architecture. This description is captured in the Software Architecture Document, which presents the architecture in multiple views.

Each architectural view addresses some specific set of concerns, specific to stakeholders in the development process: end users, designers, managers, system engineers, maintainers, and so on. This serves as a communication medium between the software architect and other project team members regarding architecturally significant decisions which have been made on the project.

Defining a candidate architecture, refining the architecture, analyzing behavior, and designing components of the system is the "essence" of the Analysis and Design discipline, and the Best Practice: Use Component Architectures.

6. Prototype-Incrementally Build and Test the Product

The RUP is an iterative approach of building, testing, and evaluating executable versions of the product in order to flush out the problems and resolve risks and issues as early as possible.

Incrementally building and testing the components of the system is the "essence" of the Implementation  and Test disciplines, and the Best Practice: Develop Iteratively.

7. Evaluation-Regularly Assess Results

Continuous open communication with objective data derived directly from ongoing activities, and the evolving product configurations are important in any project.  Regular status assessments provide a mechanism for addressing, communicating, and resolving management issues, technical issues, and project risks.  In addition to identifying the issues, each should be assigned a due date, with a responsible person who is accountable for the resolution.  This should be regularly tracked and updated as necessary.

These project snapshots provide the heartbeat for management attention. While the period may vary, the forcing function needs to capture the project history and resolve to remove any roadblocks or bottlenecks that restrict progress.

The Iteration Assessment captures the results of an iteration, the degree to which the evaluation criteria were met, the lessons learned and process changes to be implemented.

The Iteration Assessment is an essential artifact of the iterative approach. Depending on the scope and risk of the project and the nature of the iteration, it may range from a simple record of demonstration and outcomes to a complete formal test review record.

The key here is to focus on process problems, as well as product problems: "The sooner you fall behind, the more time you will have to catch up."

8. Change Requests-Manage and Control Changes

As soon as the first prototype is put before the users (and often even before that), changes will be requested. (One of those certainties of life!) In order to control those changes and effectively manage the scope of the project and expectations of the stakeholders, it is important that all changes to any development artifacts be proposed through Change Requests and managed with a consistent process.

Change Requests are used to document and track defects, enhancement requests and any other type of request for a change to the product. The benefit of Change Requests is that they provide a record of decisions, and, due to their assessment process, ensure that impacts of the potential change are understood by all project team members. The Change Requests are essential for managing the scope of the project, as well as assessing the impact of proposed changes.

Manage and controlling the scope of the project, as changes occur throughout the project lifecycle, while maintaining the goal of considering all stakeholder needs and meeting those, to whatever extent possible - this is the "essence" of the Configuration and Change Management discipline, and the Best Practice: Control Changes.

9. User Support-Deploy a Usable Product

The purpose of a process is to produce a usable product.  All aspects of the process should be tailored with this goal in mind.  The product is typically more than just the software.  At a minimum, there should be a User's Guide, perhaps implemented through online help.  You may also include an Installation Guide and Release Notes.  Depending on the complexity of the product, training materials may also be needed, as well as a bill of materials along with any product packaging. The associated activities form the Deployment discipline.

10. Process-Adopt a Process that Fits Your Project

It is essential that a process be chosen which fits the type of product you are developing. Even after a process is chosen, it must not be followed blindly - common sense and experience must be applied to configure the process and tools to meet the needs of the organization and the project.

Adapting a process for a project is a key part of the Environment discipline.

For more information on adapting RUP to your project and organization, see: Concepts: RUP Tailoring.

Conclusion

The above "essentials" provide a means of quickly assessing a process and identifying areas where improvement is most beneficial.  It is important to explore what will happen if any of these essentials is ignored.  For example:

• No vision? You may lose track of where you are going and may be easily distracted on detours.
• No process? Without a common process, the team may have miscommunications and misunderstandings about who is going to do what - and when.
• No plan? You will not be able to track progress.
• No risk list? You may be focusing on the wrong issues now and may explode on an unsuspected mine 5 months from now.
• No business case? You risk losing time and money on the project. It may be cancelled or go bankrupt.
• No architecture? You may be unable to handle communication, synchronization, and data access issues as they arise; there may be problems with scaling and performance.
• No product (prototype)? As soon as possible, get a product in front of the customer. Just accumulating paperwork doesn't assure you or the customer that the product will be successful-and it maximizes risk of budget and schedule overruns and/or outright failure.
• No evaluation? Don't keep your head in the sand. It is important to face the truth. How close are you really to your deadline? To your goals in quality or budget? Are all issues adequately being tracked?
• No change requests? How do you keep track of requests from your stakeholders? How do you prioritize them? And keep the lower priority ones from falling through the cracks?
• No user support? What happens when a user has a question or can't figure out how to use the product?  How easy is it to get help?

These "essentials" also provide an introduction to each of the disciplines of the RUP, and many of its best practices.  There is one discipline not mentioned-Business Modeling-that has activities related to understanding the structure and the dynamics of the organization.  While not represented here as essential, you may wish to explore this discipline further, as you may decide that some aspects are useful (or even essential) for your organization.

Rational Unified Process