CS2 Software Engineering note 3 Project Management in the ...
CS2 Software Engineering note 3 Project Management in the ...
CS2 Software Engineering note 3 Project Management in the ...
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
<strong>CS2</strong> <strong>Software</strong> <strong>Eng<strong>in</strong>eer<strong>in</strong>g</strong> <strong>note</strong> 3 <strong>CS2</strong>Ah 01.10.29<br />
<strong>CS2</strong> <strong>Software</strong> <strong>Eng<strong>in</strong>eer<strong>in</strong>g</strong> <strong>note</strong> 3<br />
<strong>Project</strong> <strong>Management</strong> <strong>in</strong> <strong>the</strong> Rational Unified<br />
Process<br />
In <strong>the</strong> last two <strong>Software</strong> <strong>Eng<strong>in</strong>eer<strong>in</strong>g</strong> lectures we have considered <strong>the</strong> outl<strong>in</strong>e<br />
description of <strong>the</strong> Rational Unified Process and <strong>in</strong> Lecture 2 we considered <strong>the</strong><br />
Requirements workflow as an example of a typical workflow. In this and <strong>the</strong> next<br />
lecture we consider some of <strong>the</strong> <strong>the</strong> workflows of <strong>the</strong> RUP <strong>in</strong> a little more detail.<br />
This lecture considers <strong>the</strong> project management workflow.<br />
The <strong>Project</strong> <strong>Management</strong> Workflow<br />
The RUP is an essentially iterative process. The iterative approach has been<br />
chosen to limit exposure to project risk. This lecture <strong>in</strong>troduces two key concepts<br />
<strong>in</strong> project management:<br />
• Risk: this is used to assess <strong>the</strong> potential of a project to fail to deliver <strong>the</strong><br />
required product.<br />
• Metrics: <strong>the</strong>se are <strong>the</strong> measurements we make of a development process <strong>in</strong><br />
an attempt to assess and control risk through <strong>the</strong> plann<strong>in</strong>g process.<br />
The purpose of <strong>the</strong> <strong>Project</strong> <strong>Management</strong> workflow is threefold:<br />
1. To provide a framework for manag<strong>in</strong>g project risk, through<br />
2. The provision of practical guidance on how to plan, execute and monitor<br />
projects with<strong>in</strong>,<br />
3. A framework of plann<strong>in</strong>g structured around <strong>the</strong> coord<strong>in</strong>ation of <strong>the</strong> RUP<br />
workflows and phases oriented to generat<strong>in</strong>g a flexible plan exploit<strong>in</strong>g <strong>the</strong><br />
strengths of <strong>the</strong> iterative approach.<br />
Plann<strong>in</strong>g an iterative project<br />
Us<strong>in</strong>g an iterative approach <strong>in</strong> plann<strong>in</strong>g <strong>the</strong> development of software projects<br />
has many benefits ma<strong>in</strong>ly because it is easier to keep <strong>the</strong> project aligned to <strong>the</strong><br />
requirements which are usually undergo<strong>in</strong>g rapid evolution driven by a variety<br />
of factors, <strong>in</strong>volv<strong>in</strong>g many different stakeholders. However, <strong>in</strong> some respects,<br />
tak<strong>in</strong>g an iterative approach raises additional questions:<br />
1
<strong>CS2</strong> <strong>Software</strong> <strong>Eng<strong>in</strong>eer<strong>in</strong>g</strong> <strong>note</strong> 3 <strong>CS2</strong>Ah 01.10.29<br />
• How many iterations should be planned?<br />
• How long should each iteration last?<br />
• What are <strong>the</strong> aims, objectives and deliverables of each iteration?<br />
• How should an iteration be monitored?<br />
The project plan encapsulates <strong>the</strong> process <strong>the</strong> project should follow. In particular<br />
it:<br />
• Expresses:<br />
– The decomposition of <strong>the</strong> overall task <strong>in</strong>to sub-tasks.<br />
– The allocation of tasks to people/teams<br />
– The sett<strong>in</strong>g of timescales for <strong>the</strong> task<br />
• Evolves through <strong>the</strong> lifetime of <strong>the</strong> project:<br />
– To reflect changes <strong>in</strong> <strong>the</strong> desired outcome of <strong>the</strong> project.<br />
– To take account of earlier deviations from <strong>the</strong> plan.<br />
– In response to monitor<strong>in</strong>g and measurement of <strong>the</strong> process and product.<br />
Two level plans: In many <strong>Project</strong> Plann<strong>in</strong>g environments because many similar<br />
projects have been undertaken previously it is possible to identify <strong>the</strong> deliverables<br />
that are required and <strong>the</strong> phas<strong>in</strong>g of sub-tasks to achieve <strong>the</strong> goal of<br />
<strong>the</strong> project. Unfortunately this is rarely <strong>the</strong> case <strong>in</strong> software projects. The usual<br />
approach is to take a two level approach with a coarse-gra<strong>in</strong>ed phase plan that<br />
looks at <strong>the</strong> project across <strong>the</strong> four ma<strong>in</strong> phases of <strong>the</strong> RUP and <strong>the</strong>n consider<br />
detailed iteration plans for each iteration undertaken on <strong>the</strong> project.<br />
The phase plan is very rough and consists of <strong>the</strong> outl<strong>in</strong>e for <strong>the</strong> whole project.<br />
It should <strong>in</strong>clude at least:<br />
• Dates of <strong>the</strong> major milestones, i.e. <strong>the</strong> move from one phase to ano<strong>the</strong>r.<br />
• Staff<strong>in</strong>g estimates for each phase (this is usually based on historical evidence).<br />
• An idea of <strong>the</strong> number of iterations <strong>in</strong>cluded <strong>in</strong> each phase and rough dates<br />
for <strong>the</strong> end of each iteration. The number of iterations for each phase is<br />
reasonably closely related to <strong>the</strong> size of <strong>the</strong> system. Larger systems require<br />
more iterations.<br />
2
<strong>CS2</strong> <strong>Software</strong> <strong>Eng<strong>in</strong>eer<strong>in</strong>g</strong> <strong>note</strong> 3 <strong>CS2</strong>Ah 01.10.29<br />
The iteration plans usually <strong>in</strong>clude <strong>the</strong> current plan that is be<strong>in</strong>g used to<br />
manage <strong>the</strong> current iteration. This provides a framework aga<strong>in</strong>st which progress<br />
can be measured. Each iteration <strong>in</strong>cludes: Requirements, analysis and design,<br />
implementation, deployment, test, and evaluation so milestones for each activity<br />
should be established and decomposition of larger tasks <strong>in</strong>to sub-tasks should<br />
ensure <strong>the</strong> milestones are achievable. In addition, <strong>the</strong>re should be at least a<br />
plan under development for <strong>the</strong> next iteration and possibly some schedul<strong>in</strong>g of<br />
particular tasks <strong>in</strong>to later iterations. In complex systems, <strong>the</strong> early iterations<br />
may exclude much of <strong>the</strong> functionality and <strong>the</strong> iteration plans may capture <strong>the</strong><br />
“road map” of when particular features are scheduled to be <strong>in</strong>troduced.<br />
The approach to generat<strong>in</strong>g <strong>the</strong> iteration plans is entirely conventional. We<br />
identify subtasks, <strong>the</strong>ir <strong>in</strong>terdependence, and make effort estimates for each<br />
task. From this we establish start and end dates for each task that respects <strong>the</strong><br />
resource requirements we have and <strong>the</strong> dependency between tasks. This plan is<br />
usually captured by a Gantt chart show<strong>in</strong>g when each task starts and ends.<br />
<strong>Project</strong> Risk<br />
A risk comprises three elements: an undesirable event, an estimate of <strong>the</strong> severity<br />
of <strong>the</strong> consequences of <strong>the</strong> event, and a liklihood that <strong>the</strong> event will occur.<br />
The amount of risk a project is exposed to is a good measure of <strong>the</strong> viability of<br />
<strong>the</strong> project. If a project carries too much liklihood of high consequence events<br />
it should probably be cancelled because <strong>the</strong> chances of deliver<strong>in</strong>g an acceptable<br />
product are too low. Risk is often classified <strong>in</strong>to Direct risk that <strong>the</strong> manager can<br />
control to some extent and Indirect risk that <strong>the</strong> manager cannot <strong>in</strong>fluence. In<br />
manag<strong>in</strong>g a project <strong>the</strong> aim is to control risk.<br />
Risk control<br />
<strong>in</strong>volves three strategies:<br />
• Risk avoidance <strong>in</strong>volves reorganiz<strong>in</strong>g <strong>the</strong> project so you are not exposed to<br />
<strong>the</strong> risk. E.g. Change <strong>the</strong> supplier of some key component from a supplier<br />
who is promis<strong>in</strong>g a high quality product but has yet to deliver to a supplier<br />
who has a tried-and-tested product <strong>in</strong> <strong>the</strong> area.<br />
• Risk transfer <strong>in</strong>volves f<strong>in</strong>d<strong>in</strong>g o<strong>the</strong>r stakeholders to share <strong>the</strong> risk with.<br />
E.g. if you are produc<strong>in</strong>g <strong>the</strong> product for a particular customer but hope to<br />
market it to o<strong>the</strong>r customers it might be possible to share get <strong>the</strong> custome<br />
to accept more of <strong>the</strong> development costs <strong>in</strong> return for a stake <strong>in</strong> future sales<br />
to o<strong>the</strong>r customers.<br />
• Risk acceptance <strong>in</strong>volves decid<strong>in</strong>g to live with <strong>the</strong> risk and to take <strong>the</strong> occurrence<br />
of of <strong>the</strong> risk as a possible cont<strong>in</strong>gency to be taken account of <strong>in</strong><br />
<strong>the</strong> plann<strong>in</strong>g process. Accept<strong>in</strong>g a risk <strong>in</strong>volves:<br />
– Risk mitigation where we try to reduce <strong>the</strong> liklihood or <strong>the</strong> impact of a<br />
risk. E.g. if we decide to choose a particular supplier for a component<br />
3
<strong>CS2</strong> <strong>Software</strong> <strong>Eng<strong>in</strong>eer<strong>in</strong>g</strong> <strong>note</strong> 3 <strong>CS2</strong>Ah 01.10.29<br />
we can identify an alternative supplier with a similar product that could<br />
be used if <strong>the</strong> orig<strong>in</strong>al supplier fails to deliver.<br />
– Cont<strong>in</strong>gency plann<strong>in</strong>g construct “what if” plans on <strong>the</strong> basis of <strong>the</strong> risk<br />
occurr<strong>in</strong>g.<br />
Metrics<br />
A metric is some measurement we can make of a product or process <strong>in</strong> <strong>the</strong> overall<br />
development process. Usually metrics are split <strong>in</strong>to two broad categories:<br />
Knowledge oriented metrics: <strong>the</strong>se are oriented to track<strong>in</strong>g <strong>the</strong> process to evaluate,<br />
predict or monitor some part of <strong>the</strong> process. E.g. Goals of this k<strong>in</strong>d of<br />
measurement <strong>in</strong>clude: Are we progress<strong>in</strong>g accord<strong>in</strong>g to plan? Is <strong>the</strong> workload<br />
to high for <strong>the</strong> team? How much reuse is <strong>the</strong> team achiev<strong>in</strong>g?<br />
Achievement oriented metrics: <strong>the</strong>se are often oriented to measur<strong>in</strong>g some<br />
product aspect, often related to some overall measure of quality of <strong>the</strong> product.<br />
E.g. goals of this k<strong>in</strong>d of measurement <strong>in</strong>clude: Have we achieved <strong>the</strong><br />
usability target?<br />
Metrics have a number of issues we need to consider. Without ga<strong>the</strong>r<strong>in</strong>g some<br />
metrics we cannot expect adequately to control a process. However:<br />
• It can be very expensive to ga<strong>the</strong>r metric data — we should only ga<strong>the</strong>r<br />
<strong>the</strong> necessary data and no more. What we need to measure may change<br />
through <strong>the</strong> different process phases.<br />
• We should be modest about what metrics we can measure — E.g. measur<strong>in</strong>g<br />
attributes like “usability” can only be very crude.<br />
Artifacts Generated by <strong>the</strong> <strong>Project</strong> <strong>Management</strong> workflow<br />
The <strong>Project</strong> management workflow aims to create a number of key artifacts for<br />
<strong>the</strong> management of <strong>the</strong> project. These are:<br />
• The software development plan that comprises:<br />
– Product acceptance plan<br />
– Risk list and risk management plan<br />
– Problem resolution plan<br />
– Metric list and measurement plan<br />
• Bus<strong>in</strong>ess case<br />
• Detailed plan for each iteration<br />
4
<strong>CS2</strong> <strong>Software</strong> <strong>Eng<strong>in</strong>eer<strong>in</strong>g</strong> <strong>note</strong> 3 <strong>CS2</strong>Ah 01.10.29<br />
• Assessment of each iteration<br />
• Periodic status assessment<br />
• Work schedule<br />
• <strong>Project</strong> measurement database.<br />
<strong>Project</strong> <strong>Management</strong> Workflow<br />
In this f<strong>in</strong>al section we briefly outl<strong>in</strong>e <strong>the</strong> n<strong>in</strong>e workflow items compris<strong>in</strong>g this<br />
workflow. This is sufficient to understand <strong>the</strong> overall process but more detail is<br />
required if we are to apply this successfully.<br />
At project <strong>in</strong>ception on <strong>the</strong> first iteration we require to carry out three workflow<br />
items:<br />
Conceive new project: This provides a prelim<strong>in</strong>ary bus<strong>in</strong>ess case and identifies<br />
some of <strong>the</strong> risks and beg<strong>in</strong>s assessment.<br />
Evaluate project scope and risk: This carries out more detailed development of<br />
<strong>the</strong> bus<strong>in</strong>ess case and <strong>the</strong> associated risks.<br />
Develop software development plan: This develops much of <strong>the</strong> detailed plan<br />
by develop<strong>in</strong>g <strong>the</strong>:<br />
• measurement plan<br />
• risk management plan<br />
• product acceptance plan<br />
• problem resolution plan<br />
• project organisation and staff<strong>in</strong>g<br />
• monitor<strong>in</strong>g and control processes<br />
• plan phases and iterations<br />
Dur<strong>in</strong>g each iteration, we have three fur<strong>the</strong>r workflow items:<br />
Monitor and Control <strong>Project</strong>: This work item cont<strong>in</strong>ually checks <strong>the</strong> project is<br />
on plan by monitor<strong>in</strong>g <strong>the</strong> process and check<strong>in</strong>g <strong>the</strong> monitor<strong>in</strong>g results<br />
aga<strong>in</strong>st <strong>the</strong> plan. Deviations from plan may result <strong>in</strong> replann<strong>in</strong>g.<br />
Plan for next iteration: This workitem develops <strong>the</strong> plan for <strong>the</strong> next iteration,<br />
tak<strong>in</strong>g <strong>in</strong>to account progress on <strong>the</strong> current iteration and <strong>the</strong> overall plan.<br />
Manage iteration: This work items monitors progress and next iterations plann<strong>in</strong>g<br />
to <strong>in</strong>form decision mak<strong>in</strong>g on whe<strong>the</strong>r to transfer to <strong>the</strong> next iteration<br />
or abandon <strong>the</strong> project because risks or cost estimates have become unacceptable.<br />
In addition <strong>the</strong>re are fur<strong>the</strong>r workflow items than manage phase transitions<br />
and br<strong>in</strong>g<strong>in</strong>g projects to an end.<br />
5
<strong>CS2</strong> <strong>Software</strong> <strong>Eng<strong>in</strong>eer<strong>in</strong>g</strong> <strong>note</strong> 3 <strong>CS2</strong>Ah 01.10.29<br />
Summary<br />
This <strong>note</strong> has provided a brief overview of <strong>the</strong> project management workflow of<br />
<strong>the</strong> RUP. In particular we have:<br />
• Seen how plann<strong>in</strong>g uses two levels of plan<br />
• Considered how <strong>the</strong> plann<strong>in</strong>g process is risk driven<br />
• Measurement and metrics are used to assess progress and modify plans<br />
6