Project Management in the Rational Unified Process

Transcription

1 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

2 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

3 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

4 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

5 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

6 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