CS2 Software Engineering note 3 Project Management in the ...

CS2 Software Engineering note 3 CS2Ah 01.10.29
CS2 Software Engineering note 3
Project Management in the Rational Unified
Process
In the last two Software Engineering lectures we have considered the outline
description of the Rational Unified Process and in Lecture 2 we considered the
Requirements workflow as an example of a typical workflow. In this and the next
lecture we consider some of the the workflows of the RUP in a little more detail.
This lecture considers the project management workflow.
The Project Management Workflow
The RUP is an essentially iterative process. The iterative approach has been
chosen to limit exposure to project risk. This lecture introduces two key concepts
in project management:
• Risk: this is used to assess the potential of a project to fail to deliver the
required product.
• Metrics: these are the measurements we make of a development process in
an attempt to assess and control risk through the planning process.
The purpose of the Project Management workflow is threefold:
1. To provide a framework for managing project risk, through
2. The provision of practical guidance on how to plan, execute and monitor
projects within,
3. A framework of planning structured around the coordination of the RUP
workflows and phases oriented to generating a flexible plan exploiting the
strengths of the iterative approach.
Planning an iterative project
Using an iterative approach in planning the development of software projects
has many benefits mainly because it is easier to keep the project aligned to the
requirements which are usually undergoing rapid evolution driven by a variety
of factors, involving many different stakeholders. However, in some respects,
taking an iterative approach raises additional questions:
1

CS2 Software Engineering note 3 CS2Ah 01.10.29
• How many iterations should be planned?
• How long should each iteration last?
• What are the aims, objectives and deliverables of each iteration?
• How should an iteration be monitored?
The project plan encapsulates the process the project should follow. In particular
it:
• Expresses:
– The decomposition of the overall task into sub-tasks.
– The allocation of tasks to people/teams
– The setting of timescales for the task
• Evolves through the lifetime of the project:
– To reflect changes in the desired outcome of the project.
– To take account of earlier deviations from the plan.
– In response to monitoring and measurement of the process and product.
Two level plans: In many Project Planning environments because many similar
projects have been undertaken previously it is possible to identify the deliverables
that are required and the phasing of sub-tasks to achieve the goal of
the project. Unfortunately this is rarely the case in software projects. The usual
approach is to take a two level approach with a coarse-grained phase plan that
looks at the project across the four main phases of the RUP and then consider
detailed iteration plans for each iteration undertaken on the project.
The phase plan is very rough and consists of the outline for the whole project.
It should include at least:
• Dates of the major milestones, i.e. the move from one phase to another.
• Staffing estimates for each phase (this is usually based on historical evidence).
• An idea of the number of iterations included in each phase and rough dates
for the end of each iteration. The number of iterations for each phase is
reasonably closely related to the size of the system. Larger systems require
more iterations.
2

CS2 Software Engineering note 3 CS2Ah 01.10.29
The iteration plans usually include the current plan that is being used to
manage the current iteration. This provides a framework against which progress
can be measured. Each iteration includes: Requirements, analysis and design,
implementation, deployment, test, and evaluation so milestones for each activity
should be established and decomposition of larger tasks into sub-tasks should
ensure the milestones are achievable. In addition, there should be at least a
plan under development for the next iteration and possibly some scheduling of
particular tasks into later iterations. In complex systems, the early iterations
may exclude much of the functionality and the iteration plans may capture the
“road map” of when particular features are scheduled to be introduced.
The approach to generating the iteration plans is entirely conventional. We
identify subtasks, their interdependence, and make effort estimates for each
task. From this we establish start and end dates for each task that respects the
resource requirements we have and the dependency between tasks. This plan is
usually captured by a Gantt chart showing when each task starts and ends.
Project Risk
A risk comprises three elements: an undesirable event, an estimate of the severity
of the consequences of the event, and a liklihood that the event will occur.
The amount of risk a project is exposed to is a good measure of the viability of
the project. If a project carries too much liklihood of high consequence events
it should probably be cancelled because the chances of delivering an acceptable
product are too low. Risk is often classified into Direct risk that the manager can
control to some extent and Indirect risk that the manager cannot influence. In
managing a project the aim is to control risk.
Risk control
involves three strategies:
• Risk avoidance involves reorganizing the project so you are not exposed to
the risk. E.g. Change the supplier of some key component from a supplier
who is promising a high quality product but has yet to deliver to a supplier
who has a tried-and-tested product in the area.
• Risk transfer involves finding other stakeholders to share the risk with.
E.g. if you are producing the product for a particular customer but hope to
market it to other customers it might be possible to share get the custome
to accept more of the development costs in return for a stake in future sales
to other customers.
• Risk acceptance involves deciding to live with the risk and to take the occurrence
of of the risk as a possible contingency to be taken account of in
the planning process. Accepting a risk involves:
– Risk mitigation where we try to reduce the liklihood or the impact of a
risk. E.g. if we decide to choose a particular supplier for a component
3

CS2 Software Engineering note 3 CS2Ah 01.10.29
we can identify an alternative supplier with a similar product that could
be used if the original supplier fails to deliver.
– Contingency planning construct “what if” plans on the basis of the risk
occurring.
Metrics
A metric is some measurement we can make of a product or process in the overall
development process. Usually metrics are split into two broad categories:
Knowledge oriented metrics: these are oriented to tracking the process to evaluate,
predict or monitor some part of the process. E.g. Goals of this kind of
measurement include: Are we progressing according to plan? Is the workload
to high for the team? How much reuse is the team achieving?
Achievement oriented metrics: these are often oriented to measuring some
product aspect, often related to some overall measure of quality of the product.
E.g. goals of this kind of measurement include: Have we achieved the
usability target?
Metrics have a number of issues we need to consider. Without gathering some
metrics we cannot expect adequately to control a process. However:
• It can be very expensive to gather metric data — we should only gather
the necessary data and no more. What we need to measure may change
through the different process phases.
• We should be modest about what metrics we can measure — E.g. measuring
attributes like “usability” can only be very crude.
Artifacts Generated by the Project Management workflow
The Project management workflow aims to create a number of key artifacts for
the management of the project. These are:
• The software development plan that comprises:
– Product acceptance plan
– Risk list and risk management plan
– Problem resolution plan
– Metric list and measurement plan
• Business case
• Detailed plan for each iteration
4

CS2 Software Engineering note 3 CS2Ah 01.10.29
• Assessment of each iteration
• Periodic status assessment
• Work schedule
• Project measurement database.
Project Management Workflow
In this final section we briefly outline the nine workflow items comprising this
workflow. This is sufficient to understand the overall process but more detail is
required if we are to apply this successfully.
At project inception on the first iteration we require to carry out three workflow
items:
Conceive new project: This provides a preliminary business case and identifies
some of the risks and begins assessment.
Evaluate project scope and risk: This carries out more detailed development of
the business case and the associated risks.
Develop software development plan: This develops much of the detailed plan
by developing the:
• measurement plan
• risk management plan
• product acceptance plan
• problem resolution plan
• project organisation and staffing
• monitoring and control processes
• plan phases and iterations
During each iteration, we have three further workflow items:
Monitor and Control Project: This work item continually checks the project is
on plan by monitoring the process and checking the monitoring results
against the plan. Deviations from plan may result in replanning.
Plan for next iteration: This workitem develops the plan for the next iteration,
taking into account progress on the current iteration and the overall plan.
Manage iteration: This work items monitors progress and next iterations planning
to inform decision making on whether to transfer to the next iteration
or abandon the project because risks or cost estimates have become unacceptable.
In addition there are further workflow items than manage phase transitions
and bringing projects to an end.
5

CS2 Software Engineering note 3 CS2Ah 01.10.29
Summary
This note has provided a brief overview of the project management workflow of
the RUP. In particular we have:
• Seen how planning uses two levels of plan
• Considered how the planning process is risk driven
• Measurement and metrics are used to assess progress and modify plans
6