Chapter 5: Principles of Project Management II

Slides:



Advertisements
Similar presentations
COCOMO and Function Point Analysis
Advertisements

Early Effort Estimation of Business Data-processing Enhancements CS 689 November 30, 2000 By Kurt Detamore.
W5HH Principle As applied to Software Projects
Software project management (intro)
Information Technology Project Management
Project Management and Scheduling
2 PROJECT MANAGEMENT. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap: Chapter.
1 Cost Estimation CIS 375 Bruce R. Maxim UM-Dearborn.
Information System Economics Software Project Cost Estimation.
Copyright © The David Consulting Group, Inc. 1 UNDERSTANDING and EFFECTIVELY USING FUNCTIONAL MEASUREMENT Presented By The David Consulting Group.
Introduction to Software Quality Assurance (SQA)
Cmpe 589 Spring Software Quality Metrics Product  product attributes –Size, complexity, design features, performance, quality level Process  Used.
1 ECE 453 – CS 447 – SE 465 Software Testing & Quality Assurance Lecture 22 Instructor Paulo Alencar.
COCOMO Models Ognian Kabranov SEG3300 A&B W2004 R.L. Probert.
Estimation Why estimate? What to estimate? When to estimate?
Software Engineering Modern Approaches
Chapter 6 : Software Metrics
By K Gopal Reddy.  Metrics in software are of two types.direct and indirect.  Function points as indirect metrics.  Function points are used to measure.
CS /39 Illinois Institute of Technology CS487 Software Engineering David A. Lash.
Quality Assurance vs. Quality Control Quality Assurance An overall management plan to guarantee the integrity of data (The “system”) Quality Control A.
Software Estimation How hard can it be? Peter R Hill.
Requirements Engineering PROJECT MANAGEMENT Part II.
Software Engineering SM ? 1. Outline of this presentation What is SM The Need for SM Type of SM Size Oriented Metric Function Oriented Metric 218/10/2015.
UKSMA 2005 Lessons Learnt from introducing IT Measurement Peter Thomas –
1 Estimation Function Point Analysis December 5, 2006.
Lecture 4 Software Metrics
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 3 1 Software Size Estimation I Material adapted from: Disciplined.
Project Estimation Model By Deepika Chaudhary. Factors for estimation Initial estimates may have to be made on the basis of a high level user requirements.
Software Project Planning Part II. Troutman's Postulates Profanity is the one language understood by all programmers. Not until a program has been in.
Disciplined Software Engineering Lecture #3 Software Engineering Institute Carnegie Mellon University Pittsburgh, PA Sponsored by the U.S. Department.
Introduction to Software Project Estimation I (Condensed) Barry Schrag Software Engineering Consultant MCSD, MCAD, MCDBA Bellevue.
Software Engineering Modern Approaches
SFWR ENG 3KO4 Slide 1 Management of Software Engineering Chapter 8: Fundamentals of Software Engineering C. Ghezzi, M. Jazayeri, D. Mandrioli.
Software Project Estimation IMRAN ASHRAF
Function Points Synthetic measure of program size used to estimate size early in the project Easier (than lines of code) to calculate from requirements.
CSC 480 Software Engineering Lecture 6 September 11, 2002.
Estimating “Size” of Software There are many ways to estimate the volume or size of software. ( understanding requirements is key to this activity ) –We.
Effort Estimation In WBS,one can estimate effort (micro-level) but needed to know: –Size of the deliverable –Productivity of resource in producing that.
MSE Presentation 1 Lakshmikanth Ganti
Project, People, Processes and Products Project management skills – schedule, monitoring, risk management, … People management skills – delegation, mentoring,
540f07cost12oct41 Reviews Postmortem u Surprises? u Use white background on slides u Do not zip files on CD u Team leader should introduce team members.
Intro to Estimating Part Art, Part Science. Importance of Good Estimates Time (Realistic Deadlines) most software projects are late because the time was.
Software Engineering Modern Approaches Eric Braude and Michael Bernstein 1.
Project Planning Goal 1 - Estimates are documented for use in tracking and planning project. Goal 2 - Project Activities and commitments planned and documented.
2 PROJECT MANAGEMENT. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap: Chapter.
Cost9b 1 Living with Function Points Bernstein and Lubashevsky Text pp
COCOMO Software Cost Estimating Model Lab 4 Demonstrator : Bandar Al Khalil.
Estimation Questions How do you estimate? What are you going to estimate? Where do you start?
Cost23 1 Question of the Day u Which of the following things measure the “size” of the project in terms of the functionality that has to be provided in.
THE FAMU-CIS ALUMNI SYSTEM
Alternative Software Size Measures for Cost Estimation
The Work Breakdown Structure and Project Estimation
Project Management Chapter 3.
IEEE Std 1074: Standard for Software Lifecycle
Software Engineering: A Practitioner’s Approach, 6/e Chapter 23 Estimation for Software Projects copyright © 1996, 2001, 2005 R.S. Pressman & Associates,
The Work Breakdown Structure and Project Estimation
Constructive Cost Model
Software Development & Project Management
COCOMO Model Basic.
Function Point.
Chapter 5: Software effort estimation- part 2
Software Metrics “How do we measure the software?”
Activities During SPP Size Estimation
More on Estimation In general, effort estimation is based on several parameters and the model ( E= a + b*S**c ): Personnel Environment Quality Size or.
COCOMO Models.
Chapter 6: Principles of Requirements Analysis
Software Engineering: A Practitioner’s Approach, 6/e Chapter 23 Estimation for Software Projects copyright © 1996, 2001, 2005 R.S. Pressman & Associates,
Software Project Management
Chapter 26 Estimation for Software Projects.
COCOMO MODEL.
Presentation transcript:

Chapter 5: Principles of Project Management II Eric Braude and Michael Bernstein

Learning goals of this chapter Planning Maintenance Learning goals of this chapter How do you estimate the cost of a software job? What are good ways to go about creating a project schedule? What does a Software Project Management Plan look like? How are projects planned in practice? Testing The Software Development Lifecycle Requirements analysis Implementation Design Phase most relevant to this chapter is shown in bold

Range of Errors in Estimating Cost $4 Rough range of cost estimates after conceptualization phase. Assumes eventual, actual cost of $1 Conceptual- ization phase $1 $3 25c Rough range of cost estimates after requirements analysis Requirements analysis $1 $2 $1 Design Range of Errors in Estimating Cost $1 Implementation Integration/Test

A Cost Estimation Roadmap 1 Use comparisons with past jobs to estimate cost & duration directly or to estimate lines of code. and / or Use function point method to estimate lines of code .1 Compute un-adjusted function points. .2 Apply adjustment process. 2 Use lines of code estimates to compute labor and duration using COCOMO (II) formulas.

Function Point Computation for a Single Function (IFPUG) External Inquiries (EIN) Internal Logical Files (ILF)* Function Logical group of user data Logical group of user data Logical group of user data External Outputs (EO) External Inputs (EI) External Logical Files (ELF) file * Internal logical grouping of user data into files file file

Function Point Computations (IFPUG) (Unadjusted -- to be followed by applying adjustment process) PARAMETER simple complex Ext. inputs EI … 3 or… 4 or ... 6 = ___ Ext. outputs EO … 4 or … 5 or ... 7 = ___ Ext. inquiries EIN … 3 or … 4 or ... 6 = ___ Int. logical files ILF ... 7 or …10 or ... 15 = ___ Ext. logical files ELF ... 5 or …7 or ... 10 = ___ countTotal

Unadjusted Function Point Computation for First Encounter Functions:“Set up Player Character”

Unadjusted Function Point Computation for Second Encounter Functions: “Encounter Foreign Character”

General Characteristics for FP Adjustment 1-7 incidental average essential 1 2 3 4 5 none moderate significant Case study 1. Requires backup/recovery? 0-2 2. Data communications required? 0-1 3. Distributed processing functions? 0 4. Performance critical? 3-4 5. Run on existing heavily utilized environment? 0-1 6. Requires on-line data entry? 5 7. Multiple screens for input? 4-5

General Characteristics for FP Adjustment 8-14 incidental average essential 1 2 3 4 5 none moderate significant Case study 8. Master fields updated on-line? 3-4 9. Inputs, outputs, inquiries of files complex? 1-2 10. Internal processing complex? 1-3 11. Code designed for re-use? 2-4 12. Conversion and installation included? 0-2 13. Multiple installation in different orgs.? 1-3 14. Must facilitate change & ease-of-use by user? 4-5

COCOMO I Constructive Cost Model Created by Barry Boehm in 1981 Essentially: Effort = a*SIZEb Based on large number of 70’s projects Very simple estimation tool which may or may not work depending on how closely project fit in with original study

Estimating is hard to do

Basic Idea Small Project (Small team 2-3 person) Large Project Effort = a*SIZE+b Large Project Effort = a*SIZEb Variable a and b are scaling factors Effort -> Person months SIZE -> DSI or SLOC DSI (Delivered Source Instructions) is a physical lines SLOC (Source Line of Code) is a statement For example, "if-then-else" counted as one SLOC, but might be counted as several DSI

Project Type Organic Routine project Well understood domain Team works well and efficiently together Project expected to run smoothly Typically a smaller system

Project Type Semi-Detached In the middle Complex system, but something the company is familiar with Team may be made up of experienced and inexperienced members System not huge, but not small either

Project Type Embedded Difficulties expected Project that is hard (control software for nuclear plant, or spacecraft) Team has little experience in domain New or inexperienced team Tend to be large projects with lots of constraints

What is a and b? Organic Semi-Detached Embedded More Adjustable Person-months = 2.4*KDSI1.05 Semi-Detached Person-months = 3.0*KDSI1.12 Embedded Person-months = 3.6*KDSI1.20 More Adjustable Person-months = EAF*a*SIZEb EAF (Effort Adjustment Factor)

Using COCOMO I to Estimate Encounter Effort

COCOMO II Effort Equation Schedule Equation Effort = a*EAF*SIZEE EAF = multiplication of 17 Cost Drivers (EMi) E = summation of 5 Scale Drivers (SFi) Schedule Equation Duration = b*EffortSE SE = summation of 5 Scale Drivers of Schedule

Basic COCOMO II Cost Drivers Due to http://sunset.usc.edu/research/COCOMOII/

Estimating Story Points 10 Upper bound Estimated size in story points Actual size in person-hours 1. Compute past error % 2. Estimate using comparison, 3. factored by trend in past errors % 1 2 3 4 5 6 7 8 Cycle #

Velocity in Agile Development Definition: Number of story points team can execute per cycle Relies on history of performance and consistency of story points Within this project and past ones Depends on accurate story points

Building a Schedule 1: Setting Milestones

Building a Schedule 2: Showing Phases

Building a Schedule 3: Showing Work Breakdown Structure

Dependencies in Schedules Dependencies: subset of schedule Critical paths: sequences of dependencies

IEEE 1058-1998 SPMP Table of Contents 1. Overview 1.1 Project summary 1.2 Evolution of the SPMP 2. References 3. Definitions 4. Project organization 4.1 External interfaces 4.2 Internal structure 4.3 Roles and responsibilities 5. Managerial process plans 5.1 Project startup plan 5.2 Work plan 5.3 Control plan 5.4 Risk management plan 5.5 Project closeout plan 6. Technical process plans 6.1 Process model 6.2 Methods, tools and techniques 6.3 Infrastructure plan 6.4 Product acceptance plan 7. Supporting process plans 7.1 Configuration management plan 7.2 Verification and validation plan 7.3 Documentation plan 7.4 Quality assurance plan 7.5 Reviews and audits plan 7.6 Problem resolution plan 7.7 Subcontractor management plans 7.8 Process improvement plan 8. Additional plans

Gaming Industries Consolidated President IV&V . . . VP Marketing VP Engineering Software Engineering Labs . . . Game Lab . . . Game 123 Encounter SQA

Encounter Project Responsibilities' Mem-ber Team leader CM Leader QA leader Require-ments manage-ment leader Design leader Implementa-tion Leader   Liaison Respon-sibility VP Engi-neering Market-ing Software engineer-ing lab Docu-ment Respon-sibility SPMP SCMP SQAP STP SRS SDD Code base

Maximum of minimums and maximum of maximums. Method* Mini Max Comment (1) 7.5** 170   (2) 4.2 300 (3) 11.4 46 1.9 - 2.3 for two identified functions: 6-20 times as many in complete application Most conservative Maximum of minimums and maximum of maximums. Least conservative Minimum of minimums and minimum of maximums. Widest range Minimum of minimums and maximum of maximums. Narrowest range Maximum of minimums and minimum of maximums. Very Rough Estimate of Application Size Prior to Requirements Analysis

Program Monitoring & Control

Implemen- tation Leader Name Team Leader CM Leader QA Leader Requ. Mngmnt Leader Design Leader Implemen- tation Leader Ed Braun X   Al Pruitt Fern Tryfill Hal Furnass Karen Peters Liaison with VP Eng. Market- ing Soft. Eng. Lab Encounter Staffing Plan

Encounter Project Responsibilities Member Team leader CM Leader QA leader Require-ments manage-ment leader Design leader Implemen-tation Leader   Liaison respon-sibility VP Engin-eering Marketing Software engineer-ing lab Docu-ment responsi-bility SPMP SCMP SQAP STP SRS SDD Code base

High-Level Task Chart with Fixed Delivery Date: Order of Completion Month 1 Month 2 Month 3 Month 4 Month 5 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 SCMP complete Begin system testing SQAP complete Milestones Delivery SPMP rel. 1 complete Freeze requirements Iteration 1 Iteration 2 Risk identification & retirement Prep. for maintenance

Work Breakdown Structure Excluding Secretarial Month 1 Month 2 Month 3 Month 4 Month 5 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 SCMP Complete testing Milestones SQAP Freeze requirements Delivery SPMP rel. 1 Iteration 1 Tasks Risk I&R Iteration 2 E. Braude 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 J. Pruitt 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 F. Tryfill 1 1 1 1 1 1 1 1 1 1 1 1 1 H. Furnass 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 K. Peters 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 F. Smith (tech support) .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 TOTAL 5.5 5.5 5.5 5.5 5.5 5.5 5.5 5.5 4.5 4.5 4.5 4.5 4.5 4.5 4.5 4.5 4.5 4.5 3.5 3.5

Sample Risk Analysis for Encounter Case Study #  Risk title (details given above) Like-lihood 1-10  1=least likely Im-pact 1=least impact Retire-ment cost 1-10 1=lowest cost Pri-ority  lowest number handled first Retirement / mitigation plan Respon-sible engineer Target com-pletion date   1 Super-imposing images 3 10 8 Experiment with Java images. P. R. 2/1/99  2 Deficient Java skills 9 6 80 H.T., K.M., V.I. and L.D. to attend training course beginning 1/5/99 at Ultra Training Corp, obtain Java level 2 certification by 3/1/99 and level 3 certification by 4/15/99 H. L. 4/15/99 Alan Gray may be pulled off this project 7 288 Susan Ferris to inspect all of Alan's work S.F. Contin-ual .. ...

http://www.eclipse.org/org/documents/Eclipse%20Development%20Process%202003_11_09%20FINAL.pdf