CS/SWE 321 Sections -001 & -003 Software Project Management Copyright 2014 Hassan Gomaa All rights reserved. No part of this document may be reproduced in any form or by any means, without the prior written permission of the author. 1
Readings on Software Project Management Barry Boehm keynote speech at International Conference on Software Engineering (ICSE) 2006 A View of 20th and 21st Century Software Engineering Presentation: http://isr.uci.edu/icse-06/program/keynotes/boehm.html Paper: http://csse.usc.edu/csse/techrpts/2006/usccsse2006-626/usccsse2006-626.pdf Case study on Software Project Management: National Public Radio blog November 19, 2013 http://www.npr.org/blogs/alltechconsidered/2013/11/19/246132770/thisslide-shows-why-healthcare-gov-wouldnt-work-at-launch Forbes Magazine report 12/3/2013 http://www.forbes.com/sites/lorenthompson/2013/12/03/healthcare-govdiagnosis-the-government-broke-every-rule-of-project-management 2
Overview of Software Project Management Project Planning Project Scheduling Risk Management Project Planning and Tracking Case Study on Software Project Management Software Cost Estimation 3
Software Project Management Why project management? Software development is always subject to Budget constraints Schedule constraints Objectives of Project Management Ensure software is delivered On time On schedule Conforming to software requirements 4
Why is Software Project Management Difficult? Software product is intangible Software product is uniquely flexible Software development is human-intensive Software problems are very complex Software development process is not standardised Many software projects are 'one-off' projects 5
Project Management Activities Project planning and scheduling Project cost estimation Project monitoring and reviews Team selection and evaluation Report writing and presentations 6
Project Planning Continuous activity From initial concept To system delivery Plans must be regularly revised Requirements can change As risks become apparent Turnover in staff Software project plan is primarily concerned with Project schedule Budget 7
Structure of Project Plan Project organisation Team responsibilities Risk analysis What are major risks? Hardware and software resource requirements Work breakdown Tasks to be accomplished Project schedule By milestones and tasks Monitoring and reporting mechanisms 8
Milestones and Deliverables Typically organized by project phase Process Model (e.g., Waterfall) Allows definition of project milestones Milestones End-point of a process phase Deliverables Project results delivered to managers and/or customers 9
Software Traceability Show how each requirement is mapped to design, code Use traceability matrix Tool for tracking development progress Row for each requirement Column for each component (e.g., class) Use case based development Use case realized in interaction diagram Interaction diagrams integrated to form software architecture Can trace use case to design and code components that realize use case 10
Project scheduling Split project into tasks Estimate time and resources required to complete each task Organize tasks to work in parallel Make best use of team members Minimize task dependencies Avoid delays because one task is waiting for another to complete 11
Project Scheduling Show project breakdown into tasks Start dates Duration Assigned resources (people) Predecessor and successor tasks Project schedule activity charts show Task duration Task dependencies Critical paths Calendar time for each task 12
Example of Project Schedule 13
Scheduling terms Critical path Path showing critical tasks Tasks shown in red Any delay along critical task results in project delay Slack Amount of time a task can be delayed without affecting schedule Tasks with slack shown in blue No slack along critical path 14
Cost estimation is difficult Scheduling Issues How big is the software system? How complex is the software system? Has this kind of system been developed before? How experienced is the project team? Productivity is NOT proportional to the number of people working on a task Large variations in programmer productivity Adding people to a late project makes it later Because of communication overheads The unexpected always happens Allow contingency in planning 15
Risk Management Risk management Identify project risks A risk is an adverse situation that could occur Project risks Impact schedule and/or resources Product risks Impact quality or performance of the software Estimate probability that risk will occur Develop plan to minimise effect of risk 16
Some Project Risks Personnel shortfalls Unrealistic schedules and budgets Developing wrong software functions Developing wrong user interface Stream of requirements changes Performance shortfalls 17
Project Planning and Tracking documents (provided with each milestone) Work breakdown structure (WBS) Describes the project tasks Project schedule for each milestone Software development plan Includes plans for incremental software development Describes the planned system subsets. E.g., use cases to be implemented and tested Software Implementation plan. Implementation platform and software tools to be used Software inspections Software test plan Plans for unit, integration, and system testing Individual project log Maintained by each member of the team Describes weekly contributions to the project 18
Case study in Project Planning and Management www.healthcare.gov Development of web site for affordable care act Working reasonably well now Had many problems when first released These slides based on NPR and Forbes Magazine studies National Public Radio blog November 19, 2013 http://www.npr.org/blogs/alltechconsidered/2013/11/19/24 6132770/this-slide-shows-why-healthcare-gov-wouldntwork-at-launch Forbes Magazine report 12/3/2013 http://www.forbes.com/sites/lorenthompson/2013/12/03/he althcare-gov-diagnosis-the-government-broke-every-ruleof-project-management/
Case study in Project Planning and Management www.healthcare.gov Forbes magazine report 12/3/2013 Unrealistic requirements for online customer Establish an on-line identity Review large number of health-insurance options Enroll in a specific plan Determine eligibility for federal subsidies Technical complexity Typical user might have to navigate 75 screens to obtain insurance Whole system contains over a thousand screens Total of 55 contractors were hired to produce the various pieces Involved Five federal agencies, 36 states, 300 private-sector insurers offering well over 4,000 plans
Case study in Project Planning and Management www.healthcare.gov Forbes magazine report 12/3/2013 Integration responsibility Not handled well Fragmented authority Inadequate tracking of progress Inadequate testing Almost no end-to-end testing Aggressive schedules Schedule not changed to address delays No phased development All 50 health care exchanges opened on same day
National Public Radio blog on healthcare.gov: Nov 19, 2013 http://www.npr.org/blogs/alltechconsidered/2013/11/19/246132770/this-slideshows-why-healthcare-gov-wouldnt-work-at-launch
Sizing Software Cost Estimation Estimate size of software system compared to other systems Estimate cost (staff, time) based on previous projects Estimate Lines of code Depends on programming language Compare with other projects Function Points Estimate size from number of functions (based on requirements) to be delivered Estimate number of use cases Effort to develop implementation of use cases 23
Function Points Measure or estimate software features External inputs and outputs User interactions External interfaces Files used by system Provide weight for each feature type Function Point Count = SUM (number of features of given type) X (feature weight) Compare with previously developed systems to estimate Size Development time Cost 24
Estimation Based on Use Cases Estimate number of use cases Estimate number of objects to realize each use case Estimate size of each class Attributes Operations Compare with previously developed systems to estimate Size Development time Cost 25
Software Cost Estimation Rules of Thumb, e.g., Requirements and design: 40%, Coding: 20% Testing: 40% Estimates improve as development progresses Need to revise cost estimates after each phase After requirements analysis and specification Number of use cases is known After software architectural (high-level) design Number of components is known 26
Uncertainty in Software Cost Estimation Accuracy vs. Phase Estimates improve as development progresses (B. Boehm 1995)
Software Cost Estimation Models Models are constructed by data collection and analysis from previous projects Size: lines of code Effort: How many person-months, Time: development time (calendar time) COCOMO model (developed by B. Boehm) Statistical model Linear regression Equation for estimating number of person-months Function of estimated lines of code Equation for estimating development schedule Function of estimated number of person-months 28
Algorithmic Cost Modelling COCOMO Cost is estimated as a mathematical function Effort (Person-Months) = A x Size B A, B are constants A is organisation-dependent constant Size is estimate of delivered lines of code B reflects the larger effort required for large projects Development schedule (months) = C x PM D C, D are constants
Cost Modelling with COCOMO Effort (person months) = A x Size B Simple project Well understood application developed by small team A = 2.4 B = 1.05 Moderate project More complex project, less experienced team A = 3.0 B = 1.12 Complex project Strongly coupled hardware, software, external systems, regulations A=3.6 B = 1.20
Summary of Project Management Good project management is essential for project success Most significant activities Project planning Cost estimating Project scheduling. Planning and estimating are iterative Must continue throughout project 31