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.
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/this-slide-shows-why-healthcare-gov-wouldnt-work-at-launch
• Forbes Magazine report 12/3/2013
– http://www.forbes.com/sites/lorenthompson/2013/12/03/healthcare-gov-diagnosis-the-government-broke-every-rule-of-project-management
Overview of Software Project Management
• Project Planning • Project Scheduling • Risk Management
• Project Planning and Tracking
• Case Study on Software Project Management • Software Cost Estimation
• 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
• 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
Why is Software
• Project planning and scheduling • Project cost estimation
• Project monitoring and reviews • Team selection and evaluation • Report writing and presentations
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
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
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
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
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
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
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
Scheduling Issues
• Cost estimation is difficult
– 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
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
Some Project Risks
• Personnel shortfalls
• Unrealistic schedules and budgets
• Developing wrong software functions • Developing wrong user interface
• Stream of requirements changes • Performance shortfalls
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
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-wouldnt-work-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-rule-of-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,
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
National Public Radio blog on healthcare.gov: Nov 19, 2013
http://www.npr.org/blogs/alltechconsidered/2013/11/19/246132770/this-slide-shows-why-healthcare-gov-wouldnt-work-at-launch
Software Cost Estimation
• Sizing
– 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
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
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
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
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
Algorithmic Cost Modelling
COCOMO
• Cost is estimated as a mathematical function
• Effort (Person-Months) = A x SizeB
– 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 PMD
Cost Modelling with COCOMO
• Effort (person months) = A x SizeB
• 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
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