Process Essentials

Introduction
Define a Vision
Use an Architecture
Plan and Assess
Implement and Test Iteratively
Control Changes
Deploy a Usable Product
Tailor the Process
Conclusion

Additional Concepts:

Additional Guidance:

Introduction

The key to achieving the delicate balance between delivering quality software and delivering it quickly (the e-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.

Define a Vision

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

The Vision 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 should answer the following questions, which might be broken out to separate, more detailed, artifacts, as needed:

The vision captures the essence of the Requirements discipline, and the Best Practice: Manage Requirements: analyzing the problem, understanding stakeholder needs, defining the system, and managing the requirements as they change.

Use an 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.

Plan and Assess

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.

Manage to the Plan

The Software Development Plan (SDP) gathers all information required to manage the project. It may enclose a number of separate artifacts developed during the Inception phase and is maintained throughout the project.

The SDP 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 (Project Plan, Iteration Plan, Resources, Tools), Requirements Management Plan, Configuration Management Plan, Problem Resolution Plan, QA Plan, Test Plan, Test Cases, Evaluation Plan, and Product Acceptance Plan. For a small project, these do not have to be maintained as separate artifacts. The could be addressed as merely a section -- or even a paragraph -- in the SDP.

In a simple project, these may include only one or two sentences each. For example a CM Plan 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 Software Development Plan itself is not as important as the activity and thought that go into producing it. It doesn't matter what it looks like – or what tools you use to build it. As Dwight D. Eisenhower said, “The plan is nothing; the planning is everything.”

“Risks” – Identify and Mitigate Risks

It is essential to identify and attack the highest risk items early in the project. 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.

“Issues” – Assign and Track Issues

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.

“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

“Evaluation” – Regularly Assess Results

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."

Implement and Test Iteratively

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.

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.

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.

Tailor the Process

It is essential that a process not be followed blindly - the process and tools must be configured to meet the needs of the organization and the project. This is the essence of the Environment discipline.

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:

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.