Presentation is loading. Please wait.

Presentation is loading. Please wait.

1-1 Information Technology Project Management by Jack T. Marchewka Power Point Slides by Richard Erickson, Northern Illinois University Copyright 2003.

Similar presentations


Presentation on theme: "1-1 Information Technology Project Management by Jack T. Marchewka Power Point Slides by Richard Erickson, Northern Illinois University Copyright 2003."— Presentation transcript:

1 1-1 Information Technology Project Management by Jack T. Marchewka Power Point Slides by Richard Erickson, Northern Illinois University Copyright 2003 John Wiley & Sons, Inc. all rights reserved. Reproduction or translation of this work beyond that permitted in Section 117 of the 1976 United States Copyright Act without the express permission of the copyright owner is unlawful. Request for further information information should be addressed to the Permissions Department, John Wiley & Sons, Inc. The purchaser may make back-up copies for his/her own use only and not for distribution or resale. The Publisher assumes no responsibility for errors, omissions, or damages caused by the use of these programs or from the use of the information contained herein.

2 1-2 Chapter 6 The Work Breakdown Structure and Project Estimation

3 1-3 Chapter 6 Objectives Develop a work breakdown structure.Develop a work breakdown structure. Describe the difference between a deliverable and a milestone.Describe the difference between a deliverable and a milestone. Describe and apply several project estimation methods. These include the Delphi technique, time boxing, top-down estimation, and bottom-up estimation.Describe and apply several project estimation methods. These include the Delphi technique, time boxing, top-down estimation, and bottom-up estimation. Describe and apply several software engineering estimation approaches. These include lines of code (LOC), function point analysis, COCOMO, and heuristics.Describe and apply several software engineering estimation approaches. These include lines of code (LOC), function point analysis, COCOMO, and heuristics.

4 1-4 Project Time Management as defined in PMBOK Activity definitionActivity definition Activity sequencingActivity sequencing Activity duration estimationActivity duration estimation Schedule developmentSchedule development Schedule controlSchedule control

5 1-5 The Work Breakdown Structure (WBS) The WBS represents a logical decomposition of the work to be performed and focuses on how the product, service, or result is naturally subdivided. It is an outline of what work is to be performed. Gregory T. Haugan (2002)

6 1-6 Work Package

7 1-7 Deliverables and Milestones DeliverablesDeliverables –Tangible, verifiable work products –Reports, presentations, prototypes, etc. MilestonesMilestones –Significant events or achievements –Acceptance of deliverables or phase completion –Cruxes (proof of concepts) –Quality control –Keeps team focused

8 1-8 Developing the WBS Develop work packages for each of the phases and deliverables defined in the Deliverable Structure Chart (DSC)Develop work packages for each of the phases and deliverables defined in the Deliverable Structure Chart (DSC)

9 1-9 Work Breakdown Schedule

10 1-10 Developing the WBS The WBS Should Be Deliverable-OrientedThe WBS Should Be Deliverable-Oriented The WBS Should Support the Project's MOVThe WBS Should Support the Project's MOV –Ensure WBS allows for the delivery of all the project’s deliverables as defined in project scope –100 percent rule The Level of Detail Should Support Planning and ControlThe Level of Detail Should Support Planning and Control Developing the WBS Should Involve the People Who Will Be Doing the WorkDeveloping the WBS Should Involve the People Who Will Be Doing the Work Learning Cycles and Lessons Learned Can Support the Development of a WBSLearning Cycles and Lessons Learned Can Support the Development of a WBS

11 1-11 The seeds of major software disasters are usually sown in the first three months of commencing the software project. Hasty scheduling,irrational commitments, unprofessional estimating techniques,and carelessness of the project management function are the factors that tend to introduce terminal problems. Once a project blindly lurches forward toward an impossible delivery date, the rest of the disaster will occur almost inevitably. T. Capers Jones

12 1-12 Project Estimation GuesstimatingGuesstimating Delphi TechniqueDelphi Technique –Involves multiple, anonymous experts –Each expert makes an estimate –Estimates compared If close, can be averagedIf close, can be averaged Else do another iteration until consensus is reachedElse do another iteration until consensus is reached Time BoxingTime Boxing

13 1-13 Project Estimation Top-Down EstimatingTop-Down Estimating –Often couched in terms of what a project should cost and how long it should take as decreed by a member of top management who thinks those parameters are appropriate. –May be a response to the business environment –May lead to a death march project.

14 1-14 Project Estimation Bottom-Up EstimatingBottom-Up Estimating –Most common form of project estimation –Divide project into small modules and directly estimate time and effort in person-hours, weeks, or months for each module. –Analogous estimating based on similarity between current projects and others. –Estimate a function of activity itself and the duration is dependent on: complexity of modulecomplexity of module structure of modulestructure of module resources and support assigned to moduleresources and support assigned to module

15 1-15 Project Estimation Analogous estimating based on similarity between current projects and others.Analogous estimating based on similarity between current projects and others. Estimate a function of activity itself and the duration is dependent on:Estimate a function of activity itself and the duration is dependent on: –complexity of module –structure of module –resources and support assigned to module

16 1-16 Software Engineering Metrics and Approaches software engineeringsoftware engineering –focuses on the processes, tools, and methods for developing a quality approach to developing software metricsmetrics –provide the basis for software engineering and refers to a broad range of measurements for objectively evaluating computer software.

17 1-17 Determinates of application estimate

18 1-18 Software Engineering Metrics and Approaches Lines of Code (LOC)Lines of Code (LOC) –Most traditionally used metric for project sizing –Most controversial Count comments?Count comments? Declaring variables?Declaring variables? Efficient code vs. code bloatEfficient code vs. code bloat Language differencesLanguage differences Easier to count afterwards than to estimateEasier to count afterwards than to estimate

19 1-19 Software Engineering Metrics and Approaches Function PointsFunction Points –analysis based on evaluation of data and transactional types: Internal Logical File (ILF)Internal Logical File (ILF) External Interface File (EIF)External Interface File (EIF) External Input (EI)External Input (EI) External Output (EO)External Output (EO) External Inquiry (EQ)External Inquiry (EQ)

20 1-20 Software Engineering Metrics and Approaches Function PointsFunction Points –Value Adjustment Factor based on Degrees of Influence (DI) aka Processing Complexity Adjustment (PCA)Degrees of Influence (DI) aka Processing Complexity Adjustment (PCA) General Systems Characteristics (GSC)General Systems Characteristics (GSC) –Total Adjusted Function Points (TAFP) transformed into development estimatestransformed into development estimates converted in equivalent LOCconverted in equivalent LOC –Backfiring

21 1-21 The Application Boundary for Function Point Analysis

22 1-22 COCOMO – COnstructive COst MOdel Parametric ModelParametric Model Project typesProject types –Organic – Person-Months = 2.4 x (KDSI) 1.05 –Embedded – Person-Months = 3.0 x KDSI 1.12 –Semi-detached – Person Months 3.36 x KDSI 1.20 –KDSI = thousands of delivered source instructions, i.e. LOC

23 1-23 COCOMO – COnstructive COst MOdel COCOMO Model TypesCOCOMO Model Types –Basic –Intermediate –Advanced –COCOMO II SLIM vs. COCOMOSLIM vs. COCOMO

24 1-24 Software Engineering Metrics and Approaches HeuristicsHeuristics –Rules of thumb approach to estimating –Estimating Software Costs - Jones Automated Estimating ToolsAutomated Estimating Tools –COCOMO II –SLIM –CHECKPOINT

25 1-25 The Mythical Man-Month – Frederick Brooks First, our techniques of estimation are poorly developed.More seriously, they reflect an unvoiced assumption which is quite untrue i.e., that all will go well.First, our techniques of estimation are poorly developed.More seriously, they reflect an unvoiced assumption which is quite untrue i.e., that all will go well. Second, our estimating techniques fallaciously confuse effort with progress, hiding the assumption that men and months are interchangeable.Second, our estimating techniques fallaciously confuse effort with progress, hiding the assumption that men and months are interchangeable.

26 1-26 The Mythical Man-Month – Frederick Brooks Third, because we are uncertain of our estimates,software managers often lack the courteous stubbornness of Antoines chef): Good cooking takes time. If you are made to wait, it is to serve you better,and to please you. (From the menu of Antoines,a restaurant in New Orleans)Third, because we are uncertain of our estimates,software managers often lack the courteous stubbornness of Antoines chef): Good cooking takes time. If you are made to wait, it is to serve you better,and to please you. (From the menu of Antoines,a restaurant in New Orleans) Fourth, schedule progress is poorly monitored.Techniques proven and routine in other engineering disciplines are considered radical innovations in software engineering.Fourth, schedule progress is poorly monitored.Techniques proven and routine in other engineering disciplines are considered radical innovations in software engineering.

27 1-27 The Mythical Man-Month – Frederick Brooks Fifth, when schedule slippage is recognized, the natural tendency (and traditional) response it to add more manpower. Like dousing a fire with gasoline,this makes matters worse, much worse. More fire requires more gasoline, and thus begins a regenerative cycle which ends in disaster.Fifth, when schedule slippage is recognized, the natural tendency (and traditional) response it to add more manpower. Like dousing a fire with gasoline,this makes matters worse, much worse. More fire requires more gasoline, and thus begins a regenerative cycle which ends in disaster.

28 1-28 The Mythical Man-Month – Frederick Brooks Brooks Law: “Adding manpower to a late software project makes it later.”

29 1-29 What Is the Best Way to Estimate IT Projects? Use more than one technique for estimatingUse more than one technique for estimating If estimates from different techniques close, average themIf estimates from different techniques close, average them Adjust estimate based on experienceAdjust estimate based on experience Negotiation may lead to unrealistic estimationsNegotiation may lead to unrealistic estimations


Download ppt "1-1 Information Technology Project Management by Jack T. Marchewka Power Point Slides by Richard Erickson, Northern Illinois University Copyright 2003."

Similar presentations


Ads by Google