Software Engineering I Session 9 Software Project Management and Planning

Software Engineering and Project Management Software engineering, as a discipline, is concerned with both the technical and project management aspects of software development. The technical aspect of software engineering is focused on individual technical skills. The project management aspect of software engineering is focused on activities with project wide scope, such as planning, risk management, people management, budget control, etc. In professional practice, is it possible to be a project manager without first being a software engineer? Software project management is an essential part of SE

You are a software project manager Today You are a software project manager Not a software engineer (programmer, testing engineer, requirement analyst, …)

Software Project Management The primary objectives of software project management are to: Deliver the software to the customer on time (time) Keep overall costs within budget (cost) Deliver software that meets customer expectations (quality) Maintain a coherent and well-functioning development team (person) 1. Why is software project management inherently more difficult than project management in other engineering disciplines?

Software Project Management Software project management shares many similarities with project management in other engineering disciplines. However, several key factors make software engineering different from other disciplines make software project management particularly challenging: The product is intangible. Projects are often one-off. Software processes are variable and organisation specific. In what way are software products more complex than other products (for example, in construction)? It is not surprising that some software projects are late, overbudget, and behind schedule.

Software Project Management Software project management practices tend to differ from organisation to organisation. Factors influencing difference in organisational practice include: Organisation size Customer demands Software size Software type Organisational culture Software development processes Project managers may work in quite different ways There are several cornerstone activities that are common to all software project management endeavours: Risk management Project planning scheduling and costing Proposal writing People management Reporting Give examples of two software process models that require radically different approaches to project management. How might organisational culture affect software project management? Despite differences dictated by project and organisation specifics,

Risk management

Risk Management Risk management is concerned with identifying threats to project success and drawing up plans to eliminate those threats or minimise their effect. Risks can be categorised as follows: Project risks Affecting schedule and/or resources. Loss of key staff. Budget shortfall. Management change. Tool unavailability, etc. Product risks Affecting quality or performance of software being developed. Requirements change. Substandard craftsmanship. Tool under-performance, etc. Business risks Affecting the organisation developing or procuring the software. Emergence of competitor product. Product redundancy due to changes in underlying technologies, etc. 1. Give further examples of project, product and business risks.

Examples of project, product, and business risks

The risk management process (IAPM) Risk identification Identify project, product and business risks; Risk analysis Assess the likelihood and consequences of these risks; Risk planning Draw up plans to avoid or minimise the effects of the risk; Risk monitoring Monitor the risks throughout the project;

Risk Identification A checklist of common risks may be used to identify actual risks in a project，including: Technology risks Organisational risks People risks Requirements risks Estimation risks Identified risks should be added to a risk register. 1. Give examples of one risk from each of the listed categories.

Examples of different risk types Possible risks Estimation The time required to develop the software is underestimated. The rate of defect repair is underestimated. The size of the software is underestimated. Organisational The organisation is restructured so that different management are responsible for the project. Organisational financial problems force reductions in the project budget. People It is impossible to recruit staff with the skills required. Key staff are ill and unavailable at critical times. Required training for staff is not available. Requirements Changes to requirements that require major design rework are proposed. Customers fail to understand the impact of requirements changes. Technology The database used in the system cannot process as many transactions per second as expected. Reusable software components contain defects that mean they cannot be reused as planned. Tools The code generated by software code generation tools is inefficient. Software tools cannot work together in an integrated way.

Risk Analysis In risk analysis, identified risks should be ranked on the basis of their probability/likelihood and their likely effect/impact.   Low Likelihood Medium Likelihood High Likelihood Low Impact Low Risk Medium Risk Medium Impact High Risk High Impact 1. How are impact and likelihood calculated?

Risk types and examples (1)

Risk types and examples (2)

Risk Planning Risk planning first involves deciding which risks to manage: No risks are acceptable: all risks should be managed. Low risks are acceptable: only medium and high risks should be managed. Low and medium risks are acceptable: only high risks should be managed. Risk planning also involves the choice of one of the following risk management strategies: Avoidance (Stop the risk arising). Minimisation (Reduce the impact). Contingency plans (Deal with the risk outcome). Is it ever possible to manage all the risks in a project? How many risks should be managed?

What-if questions What if several engineers are ill at the same time? What if an economic downturn leads to budget cuts of 20% for the project? What if the performance of open-source software is inadequate and the only expert on that open source software leaves? What if the company that supplies and maintains software components goes out of business? What if the customer fails to deliver the revised requirements as predicted?

Strategies to help manage risk (1)

Strategies to help manage risk (2)

Risk Monitoring Risk management is not a one-off activity Risk monitoring is a process of checking that The assumption about the product, process, and business risks have been changed Existing risks should be regularly reassessed changes to their likelihood? changes of their potential impact? New risks should be identified, analysed and managed. Risk monitoring may also assess the effectiveness of current risk management processes with a view to refining practice. factored into risk management measures

Risk indicators

Project planning

Project Planning Project planning is axiomatic to project success. Project planning involves: Breaking down the overall task into manageable sub-tasks. Assigning sub-tasks to project team members. Anticipating problems that might arise and preparing tentative solutions to those problems. The project plan is a formal, approved document used to guide both project execution and project control. The primary uses of the project plan are to: Document planning assumptions and decisions Facilitate communication among project stakeholders Document approved scope, cost, and schedule baselines Measure progress 1. How can a project plan be used to measure progress?

Planning Stages Project planning is an ongoing and iterative activity takes place at different stages in the project lifecycle Proposal stage At the point of bidding for a contract. Outline plan showing major project milestones. Provides pricing information. Start-up stage Once contract is secured. Detailed plan showing detailed decomposition of task. Shows resource requirements and allocation. Details project risks and risk management. Development stage Once the project is underway. Refines start-up plan, resource issues and risk management. 1. Who are the primary audience for project planning documents at the proposal, start-up and development stages of a project?

Configuration management planning Deployment planning Detailed Planning In addition to planning the project schedule, risk management and resource allocation, software project planning will generally involve one or more of the following: Test planning Configuration management planning Deployment planning Quality assurance planning Maintenance planning. 1. What do you think is contained in a configuration management plan?

Approaches to Planning The approach to planning used for a project is entirely determined by the preferred software process model. Projects using plan-driven approaches to software development require detailed, up-front planning resulting in a comprehensive set of planning documents. Projects utilising agile methods, work on value-driven principles and principles of adaptability plan only as far as the next iteration and release.

Plan-driven Approaches to Project Planning The planning process for plan-driven projects.

Plan-driven Approaches to Project Planning In a plan-driven development project, the project plan sets out the tasks to be completed, the resources available to the project, and a schedule for carrying out the tasks. Indicative plan sections (document) include: Introduction Project organisation Risk analysis Hardware and software resource requirements Work breakdown Project schedule Monitoring and reporting mechanisms Supplementary plans: Configuration management plan Deployment plan Maintenance plan quality plan Validation plan

Project scheduling

Plan-driven Project Scheduling Project scheduling involves: Subdividing the project into separate tasks. Estimating how long each task will take to complete. Estimating the effort (in person hours) required to complete each task. Estimating the human resources required to complete each task. Estimating other resources (e.g. specialised hardware and software, office space, travel costs, etc.). Allocating human and other resources to specific tasks. Most scheduling work is dependent on estimates. Good estimates are a result of experience gained in a project manager role. What factors will a project manager bring to bear when making estimates for project duration, resources required, etc.? Can project estimation ever be an exact science?

Project Schedule Representation Project schedules are most often represented in GANTT chart format. GANTT charts are designed to show: Decomposition of project into sub-tasks. Duration of each task. Start and end date for each task. Dependencies between tasks (e.g. tasks B and C cannot begin before task A is complete). Allocation of resources to tasks. GANTT charts are generally drawn using specialist project management software such as Microsoft Project and Wrike. 1. What are the advantages of using specialised tools for project planning?

Project Schedule Representation GANTT chart showing tasks, task durations, dependencies and allocated human resources.

Project Schedule Representation Another way of representing a project schedule is to use a PERT chart. PERT=Program Evaluation Review Technique PERT charts are used by project managers to: Show the interdependence of tasks. Calculate the amount of time it will take to complete a project. Determine a project’s critical path. Set start and end dates for tasks. They are generally used at the start of a project. They are not usually used as a communication tool between project managers and project staff. A GANTT chart is used for this purpose. A PERT chart is a project management tool used to schedule, organize, and coordinate tasks within a project. PERT stands for Program Evaluation Review Technique, a methodology developed by the U.S. Navy in the 1950s to manage the Polaris submarine missile program. A similar methodology, the Critical Path Method (CPM) was developed for project management in the private sector at about the same time.

Project Schedule Representation PERT chart showing task dependencies and time estimates. 1. How might a PERT chart like the one above help us to schedule a project and allocate resources to tasks?

Quiz

Estimation techniques

Estimation techniques Organisations need to make software effort and cost estimates. There are two types of technique that can be used to do this: Experience-based techniques The estimate of future effort requirements is based on the manager’s experience of past projects and the application domain. Essentially, the manager makes an informed judgment of what the effort requirements are likely to be. Algorithmic cost modeling In this approach, a formulaic approach is used to compute the project effort based on estimates of product attributes, such as size, and process characteristics, such as experience of staff involved.

Estimate uncertainty

Algorithmic cost modelling Chapter 23 Project Planning 10/12/2014 Algorithmic cost modelling Cost is estimated as a mathematical function of product, project and process attributes whose values are estimated by project managers: Effort = A*SizeB *M A is an organisation-dependent constant, B reflects the disproportionate effort for large projects, and M is a multiplier reflecting product, process and people attributes. The most commonly used product attribute for cost estimation is code size. Most models are similar but they use different values for A, B and M.

Algorithmic cost modelling Cost is estimated as a mathematical function of product, project and process attributes whose values are estimated by project managers: Effort = A*SizeB *M A is an organisation-dependent constant, B reflects the disproportionate effort for large projects, and M is a multiplier reflecting product, process and people attributes. The most commonly used product attribute for cost estimation is code size Most models are similar but they use different values for A, B and M.

Estimation accuracy The size of a software system can only be known accurately when it is finished. Several factors influence the final size Use of reused systems and components; Programming language; Distribution of system. As the development process progresses, the size estimate becomes more accurate. The estimates of the factors contributing to B and M are subjective and vary according to the judgment of the estimator.

Effectiveness of algorithmic models Algorithmic cost models are a systematic way to estimate the effort required to develop a system. However, these models are complex and difficult to use. There are many attributes and considerable scope for uncertainty in estimating their values. This complexity means that the practical application of algorithmic cost modeling has been limited to a relatively small number of large companies, mostly working in defense and aerospace systems engineering.

COCOMO cost modelling

COCOMO cost modelling COCOMO= Constructive Cost Model An empirical model based on project experience. Well-documented, ‘independent’ model which is not tied to a specific software vendor. Long history from initial version published in 1981 (COCOMO-81) through various instantiations to COCOMO 2. COCOMO 2 takes into account different approaches to software development, reuse, etc.

COCOMO 2 models COCOMO 2 incorporates a range of sub-models that produce increasingly detailed software estimates. Application composition model Used when software is composed from existing parts. Early design model Used when requirements are available but design has not yet started. Reuse model Used to compute the effort of integrating reusable components. Post-architecture model Used once the system architecture has been designed and more information about the system is available.

Application composition model Chapter 23 Project Planning 10/12/2014 Application composition model Supports prototyping projects and projects where there is extensive reuse. Based on standard estimates of developer productivity in application (object) points/month. Takes software tool use into account. Formula is PM = (NAP *(1 - %reuse/100 ) ) / PROD PM is the effort in person-months, NAP is the number of application points and PROD is the productivity. Developer’s experience and capability Very low Low Nominal High Very high ICASE maturity and capability PROD (NAP/month) 4 7 13 25 50

Application points NAP The number of separate screens or web pages that are displayed The number of reports that are produced The number of modules in imperative programming languages The number of lines of scripting language or database programming code

Early design model Estimates can be made after the requirements have been agreed. Based on a standard formula for algorithmic models Effort = A * SizeB * M where M = PERS * RCPX * RUSE * PDIF * PREX * FCIL * SCED; A = 2.94 in initial calibration, Size in KSLOC (number of thousands of lines of source code), B varies from 1.1 to 1.24 depending on novelty of the project, development flexibility, risk management approaches and the process maturity Multipliers reflect the capability of the developers, the non-functional requirements, the familiarity with the development platform, etc. PERS - personnel capability; RCPX - product reliability and complexity; RUSE - the reuse required; PDIF - platform difficulty; PREX - personnel experience; SCED - required schedule; FCIL - the team support facilities.

Chapter 23 Project Planning 10/12/2014 Reuse model estimates Black-box reuse where code is not modified. An effort estimate (PM) is computed. For generated code: PM = (ASLOC * AT/100)/ATPROD ASLOC is the number of lines of generated code AT is the percentage of code automatically generated. ATPROD is the productivity of engineers in integrating this code. White-box reuse where code is modified. When code has to be understood and integrated: ESLOC = ASLOC * (1-AT/100) * AAM. ASLOC and AT as before. AAM is the adaptation adjustment multiplier computed from the costs of changing the reused code, the costs of understanding how to integrate the code, and the costs of reuse decision making. Effort = A ´ ESLOC B ´ M

Post-architecture level PM = A * SizeB * M Uses the same formula as the early design model but with 17 rather than 7 associated multipliers. The code size is estimated as the sum of: Number of lines of new code to be developed (SLOC); Estimate of equivalent number of lines of new code computed using the reuse model (ESLOC); An estimate of the number of lines of code that have to be modified according to requirements changes.

The exponent term (B) This depends on 5 scale factors (see next slide). Their sum/100 is added to 1.01 A company takes on a project in a new domain. The client has not defined the process to be used and has not allowed time for risk analysis. The company has a CMM level 2 rating. Precedenteness - new project (4) Development flexibility - no client involvement - Very high (1) Architecture/risk resolution - No risk analysis - Very Low (5) Team cohesion - new team - nominal (3) Process maturity - some control - nominal (3) Sum=4+1+5+3+3=16 Scale factor is therefore 1.17 (16/100+1.01=1.17)

Chapter 23 Project Planning 10/12/2014 Scale factors used in the exponent computation in the post-architecture model Scale factor Explanation Architecture/risk resolution Reflects the extent of risk analysis carried out. Very low means little analysis; extra-high means a complete and thorough risk analysis. Development flexibility Reflects the degree of flexibility in the development process. Very low means a prescribed process is used; extra-high means that the client sets only general goals. Precedentedness Reflects the previous experience of the organization with this type of project. Very low means no previous experience; extra-high means that the organization is completely familiar with this application domain. Process maturity Reflects the process maturity of the organization. The computation of this value depends on the CMM Maturity Questionnaire, but an estimate can be achieved by subtracting the CMM process maturity level from 5. Team cohesion Reflects how well the development team knows each other and work together. Very low means very difficult interactions; extra-high means an integrated and effective team with no communication problems.

Multipliers (M) Product attributes Computer attributes Concerned with required characteristics of the software product being developed. Computer attributes Constraints imposed on the software by the hardware platform. Personnel attributes Multipliers that take the experience and capabilities of the people working on the project into account. Project attributes Concerned with the particular characteristics of the software development project.

The effect of cost drivers on effort estimates Chapter 23 Project Planning 10/12/2014 The effect of cost drivers on effort estimates Exponent value 1.17 System size (including factors for reuse and requirements volatility) 128,000 DSI Initial COCOMO estimate without cost drivers 730 person-months Reliability Very high, multiplier = 1.39 Complexity Very high, multiplier = 1.3 Memory constraint High, multiplier = 1.21 Tool use Low, multiplier = 1.12 Schedule Accelerated, multiplier = 1.29 Adjusted COCOMO estimate 2,306 person-months Exponent value 1.17 Reliability Very low, multiplier = 0.75 Complexity Memory constraint None, multiplier = 1 Tool use Very high, multiplier = 0.72 Schedule Normal, multiplier = 1 Adjusted COCOMO estimate 295 person-months

Project duration and staffing As well as effort estimation, managers must estimate the calendar time required to complete a project and when staff will be required. Calendar time can be estimated using a COCOMO 2 formula TDEV = 3 * (PM)(0.33+0.2*(B-1.01)) The nominal schedule for the project (in calendar months) PM is the effort computation B is the exponent computed as discussed before (B is 1 for the early prototyping model). This computation predicts the nominal schedule for the project. The time required is independent of the number of people working on the project.

Agile planning

Agile Planning Agile methods of software development are iterative approaches where the software is developed and delivered to customers in increments. Unlike plan-driven approaches, the functionality of these increments is not entirely planned in advance, but is decided during development. The decision on what to include in an increment depends on progress and on customer priorities. Customer priorities and requirements change so it makes sense to have a flexible plan that can accommodate these changes.

Agile Planning Agile methods have a two stage approach to planning: Release planning, which looks ahead for several months and decides on the features that should be included in a release of a system. Iteration planning, which has a shorter term outlook (2-3 weeks), and focuses on planning only the next increment of a system. Each agile method has its own unique approach to planning: Scrum – project backlogs, daily reviews and sprints. Extreme Programming – The Planning Game.

The Planning Game – Release Planning Release planning involves selecting and refining the stories that will reflect the features to be implemented in a release of a system, and the order in which the stories should be implemented. Release planning has three phases: Exploration Phase: Customer provides a shortlist of high-value requirements for the system in user story format. Commitment Phase: Customer and developers commit to the functionality to be included in the next release and the release date. Steering Phase: The plan can be adjusted, new requirements can be added and/or existing requirements can be changed or removed.

The Planning Game – Iteration Planning A release is broken down into iterations. Stories to be implemented in each iteration are chosen, with the number of stories reflecting the time to deliver an iteration (usually 2-3 weeks). Iteration planning is also broken down into three key phases: Exploration Phase: User stories are broken down into tasks. Tasks are recorded on task cards. Commitment Phase: Programmers choose tasks to implement. The time it takes to complete tasks is estimated. Steering Phase: Tasks are carried out in pairs. Tests are run (e.g. TDD).

The Planning Game – Scheduling – Estimation Developers use relative estimation to assign a story point value to a story dependent on story size. Note the use of the Fibonacci series for the scale.

The Planning Game – Scheduling – Estimation Customers then rank the stories in terms of the value they deliver.

The Planning Game – Scheduling – Estimation The bang for the buck score is then calculated by dividing the value points by the story points for each story. The BFTB score represents the most value attainable in the shortest time.

The Planning Game – Scheduling – Estimation Stories are then ranked in terms of BFTB score (high to low). This gives an initial sequence in which tasks should be performed. However, tasks will normally need to be reordered again to account for dependencies. Task Story P Value P BFTB C 3 13 4.33 E 21 55 2.62 G 5 2.6 A 34 1.68 F 1.61 B 0.62 D 0.05 Task Story P Value P BFTB C 3 13 4.33 G 5 2.6 E 21 55 2.62 A 34 1.68 F 1.61 B 0.62 D 0.05

Scheduling – Estimation – Velocity The initial velocity of a project is set at the number of story points completed in iteration one. Based on the velocity, we can then calculate how long it will take to complete each remaining story point, and to schedule tasks accordingly. To calculate how long a single story point takes to complete, we divide the time taken to complete the iteration by the velocity: 50 hours / 55 = 0.9 hours At the end of every iteration, the velocity is recalculated and the project schedule adjusted in response.