View
3
Download
0
Category
Preview:
Citation preview
Copyright 2014 H. Gomaa
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
Copyright 2014 H. Gomaa
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
2
Copyright 2014 H. Gomaa
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
Copyright 2014 H. Gomaa
• 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 Project Management
4
Copyright 2014 H. Gomaa
• 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 Management Difficult?
5
Copyright 2014 H. Gomaa
• Project planning and scheduling
• Project cost estimation
• Project monitoring and reviews
• Team selection and evaluation
• Report writing and presentations
Project Management Activities
6
Copyright 2014 H. Gomaa
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
Copyright 2014 H. Gomaa
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
Copyright 2014 H. Gomaa
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
Copyright 2014 H. Gomaa
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
Copyright 2014 H. Gomaa
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
Copyright 2014 H. Gomaa
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
Copyright 2014 H. Gomaa
Example of Project Schedule
13
Copyright 2014 H. Gomaa
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
Copyright 2014 H. Gomaa
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
– Allow contingency in planning
15
Copyright 2014 H. Gomaa
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
Copyright 2014 H. Gomaa
Some Project Risks
• Personnel shortfalls
• Unrealistic schedules and budgets
• Developing wrong software functions
• Developing wrong user interface
• Stream of requirements changes
• Performance shortfalls
17
Copyright 2014 H. Gomaa18
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
Copyright 2014 H. Gomaa
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/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/
Copyright 2014 H. Gomaa
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
Copyright 2014 H. Gomaa
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
Copyright 2014 H. Gomaa
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
Copyright 2014 H. Gomaa
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
– Effort to develop implementation of use cases
23
Copyright 2014 H. Gomaa
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
– Cost24
Copyright 2014 H. Gomaa
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
Copyright 2014 H. Gomaa
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
Copyright 2014 H. Gomaa
Uncertainty in Software Cost Estimation
– Accuracy vs. Phase
Estimates improve as development progresses
(B. Boehm 1995)
Copyright 2014 H. Gomaa
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-months28
Copyright 2014 H. Gomaa
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
– C, D are constants
Copyright 2014 H. Gomaa
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
A=3.6 B = 1.20
Copyright 2014 H. Gomaa
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
Recommended