CS/SWE 321 Sections -001 & -003 Software Project Managementrpettit/files/lectures/321L09.pdf · Overview of Software Project Management • Project Planning • Project Scheduling

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


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


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


• 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


• 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


• Project planning and scheduling

• Project cost estimation

• Project monitoring and reviews

• Team selection and evaluation

• Report writing and presentations

Project Management Activities

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


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


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

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


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/



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



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-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

– 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

– Cost24


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-months28


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


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


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

Documents

CS/SWE 321 Sections -001 & -003 Software Project Managementrpettit/files/lectures/321L09.pdf · Overview of Software Project Management • Project Planning • Project Scheduling