2. Plan—Manage to the Plan
“The product is only as good as the plan for the product”
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.
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.
They 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.”
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. In RUP,
this is the essence of the Environment
discipline.
Process adaptation in general is covered in detail in the Environment
discipline and in the Process Engineer Toolkit
section. The configured process is documented in Artifact:
Development Case. Which artifacts are developed, and the extent to which
they are developed, will vary from project to project depending on team size
and risk. It is very unlikely that any project will use all artifacts to their
fullest extent. For more information on adapting RUP to your project and organization,
see: Concepts: Implementing
the Rational Unified Process.
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.
Copyright
© 1987 - 2001 Rational Software Corporation
Overview >
Process Essentials
