Presentation is loading. Please wait.

Presentation is loading. Please wait.

Copyright 1995-2008, Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M21 - Version 8.01 SMU CSE 7315 Planning and Managing a Software Project.

Similar presentations


Presentation on theme: "Copyright 1995-2008, Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M21 - Version 8.01 SMU CSE 7315 Planning and Managing a Software Project."— Presentation transcript:

1 Copyright 1995-2008, Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M21 - Version 8.01 SMU CSE 7315 Planning and Managing a Software Project Module 21 Software Scheduling, Part 1

2 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 2 Objectives of This Module  To discuss how to estimate the length of a schedule  To begin the discussion of how to develop a detailed schedule –Basics of PERT charts

3 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 3 Detailed Planning Process Estimate Size Estimate Effort and Cost Estimate Schedule Evaluate Source Information Statement of Work Requirements Constraints Standards Processes History etc. WBSSize Effort & Cost Schedule OK Complete Detailed Planning Revise & Negotiate Not OK

4 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 4 Levels of Schedule Detail  Top Level Project Schedule and Software Schedule –Generally produced during initial planning –Represented in the initial IMS for the project –Based on project constraints, deadlines, etc. –Focuses on  The major phases of software development  How software tasks relate to the rest of the project Prototype Final Design Build Design Prototype Final Design Build Design Prototype Final Design Build Design Prototype Final Design Build Design Prototype Final Design Build Design Prototype Final Design Build Design Prototype Final Design Build Design CodeDesignTest Build DeliveryContract Prototype Final Design Build Design Prototype Final Design Build Design

5 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 5 Note about Generic Schedule (in estimating spreadsheet)  This is initially based on the top level software schedule, but can be refined based on later levels of schedule detail.

6 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 6 Levels of Schedule Detail (continued)  Intermediate Software Schedule –Generally produced during effort estimation, based on information gained from the estimating process –The focus is still on the major (high level) software phases and when they occur in time –But additional detail and refinement are generally included, such as working out iterative development plans or parallel development of major software components  Note that the IMS is typically updated as a result of this

7 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 7 Levels of Schedule Detail (continued)  More Detailed Schedules –Generally produced when you are about to execute the project or a phase of the project –The focus is on how and when you will do the detailed work tasks –Often results in detailed earned value planning (see later module)  IMS must be updated if major phases are shifted in time –But the additional details may or may not be added to the IMS

8 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 8 Schedules are Developed in a Hierarchy Rqmts Deliver Test Code Design Set up Test Development Model Refine Simulate Elaborate EvaluateTest Code Design Top Level SW Schedule Schedule for Design Phase Schedule for Simulate Task

9 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 9 Here We Will Cover Two Topics  How to verify that the top levels of the schedule are realistic –Normally this is done as part of the effort estimating process  How to develop a detailed schedule –This tends to be done when you are just about to begin a particular phase of development –But it can be done at a higher level for other purposes

10 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 10 Verifying that the Schedule is Reasonable Two issues are of concern:  Total time to do the job  Percent of time and effort in each phase of the job How do you know whether the top level schedule is realistic? How do you determine schedule details?

11 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 11 Total Time Needed  Total time needed to do the project is a direct factor of –Size and nature of software developed –Organizational capability –Process and methods –Time constraints –Financial constraints  This can vary significantly from one organization to the next

12 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 12 Estimating the Time Needed  Estimation models like Cocomo can be used to predict the length of the schedule  These models usually predict an ideal or optimal schedule  Each model bases its estimate on a particular set of assumptions, reflecting the experience of those who developed the model

13 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 13 Warning about Schedule Length Estimates  Most models and formulas for schedule length are based on someone else’s data and experience  All such data and experience are obsolete! –We have better tools, faster computers –We may have improved our process cycle time (see later module)  So we usually can do better than the schedules estimated by such models and formulas  Moreover, schedule length is flexible

14 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 14 Schedules Tend to be Somewhat Flexible  You can vary the actual schedule to fit your conditions –You have flexibility in matching the schedule to other project constraints –Cycle time improvement techniques can also improve your schedule  But you can drive up cost and risk as you deviate too far from the optimal

15 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 15 The Optimal Schedule...... depends on people, process, nature of task, environment, etc. …  Until we have a better theoretical foundation, experience remains the best way of predicting your optimal schedule  Remember too that concerted efforts to reduce cycle time can improve your optimal schedule

16 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 16 Total Time to Do the Job Cocomo Formula... e =.38 for organic.35 for semi-detached.32 for embedded Effort is measured in staff-months, as computed by the Cocomo formula (basic, intermediate, or detailed) Schedule is measured in calendar-months Schedule = 2.5 * Effort e

17 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 17 Why is the Exponent Smaller for Embedded?  Note that the variable is EFFORT.  An embedded project of comparable size will have considerably more effort than a non-embedded project, thus the actual schedule will be longer, despite the formula.

18 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 18 Notes on Cocomo Formula  This formula assumes schedule compression adjustment factor = 1 (nominal)  In other words, the schedule computed by the above Cocomo formula is an ideal schedule. –Yours is probably different. Schedule = 2.5 * Effort e

19 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 19 The Cocomo Model of Time vs Effort staff- days required to do the work Calendar Time Allocated for the Work Optimal Schedule

20 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 20 Beware of Circular Relationship  (ideal) schedule length is a function of effort in most models, including Cocomo  If your actual schedule is different from the ideal, then you must: –Change the “schedule compression” cost adjustment factor –Re-compute the effort (it should go up) –Do NOT re-compute schedule length as a function of effort, because the formula is no longer valid

21 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 21 Other Models Give Different Formulas for Time SLIM formula for TOTAL effort (lifetime): SLIM equation for development effort vs development time is slightly different: Size = C k * Effort 1/3 * t 4/3 So t 4/3 = Size / C k * Effort 1/3 ) So t = (Size / C k * Effort 1/3 )) 3/4 DE = Constant / Time 4

22 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 22 0 2 4 6 8 10 12 14 16 18 0.50.60.70.80.911.11.2 RELATIVE TIME RELATIVE EFFORT EFFORT = CONSTANT / TIME4 Putnam’s “SLIM” Time vs. Size Equation

23 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 23 Why Do Models Vary on Schedule?  One reason is that schedules are flexible and you have some control over them.  Grady and Caswell compare 5 different sources (p34, 35) (see references)  Differences they identified stem from: –Type of software being developed –Schedule compression –Organizational differences –Process and methods

24 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 24 What to Do About Variation  Hewlett-Packard recommendations: –Measure actual data & keep for the future –Count everything (overtime, etc.)  Once you know YOUR organizational behavior, you can better calibrate the models to fit your experience

25 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 25 For Small Projects...  General formulas tend to fit large projects better than small ones  And you may not have a good data base of historical schedule information...  So it may be better to estimate the time in a more detailed manner, as will be shown later

26 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 26 Time May Require Adjustment  Your actual project may require a different amount of time than the “ideal” computed by the models or suggested by prior experience  Project constraints may also affect the schedule  You usually have a lot more flexibility with schedule than you do with size or cost

27 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 27 When Will Each Specific Task be Performed?  Many models will estimate this  Your past experience and your method of doing business are good guidelines  But initial estimates will seldom be precisely accurate for detailed tasks  Better accuracy requires developing a more detailed schedule –Which can also be used to give a more accurate estimate of the total time

28 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 28 Schedules are Developed in a Hierarchy Rqmts Deliver Test Code Design Set up Test Development Model Refine Simulate Elaborate EvaluateTest Code Design Top Level SW Schedule Schedule for Design Phase Schedule for Simulate Task

29 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 29 Scheduling Order  Generally you start with the top level software schedule from initial planning (the software part of the integrated master schedule)  Develop the intermediate schedule during the effort estimate, with a more detailed schedule for each of the major phases or tasks –The WBS serves as a guide  Very finely detailed schedules are best done just prior to performing the actual work

30 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 30 Developing the Detailed Schedule I need A detailed schedule! Tell me how long it Will take and when each task will be complete. What do I do now? Yes, sir! Right away, sir.

31 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 31 Information Needed to Develop an Effective Schedule  Desired start and completion dates  Other critical dates (reviews, interim milestones)  Process or lifecycle (major phases, milestones)  Tasks (organized by phase)  Control or review points  Task dependencies (which ones are sequential, which can be done in parallel)  Resources required for each task (personnel, skill levels, special equipment, etc.)

32 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 32 Techniques for Developing & Documenting a Detailed Schedule PERT Chart (PDM) –Shows dependencies and flow –Can expand to show timing and resources Critical Path (CPM) –Shows the longest path in the schedule GANTT Chart –Shows timing and parallelism Network Chart –Combines the benefits of PERT and GANTT –But you need a tool to manage

33 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 33 PERT Charts & Critical Path Analysis

34 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 34 PERT “PERT” stands for “Program Evaluation and Review Technique” See Modell in reference list.

35 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 35 PERT Origins  PERT was developed in the 1940’s as a management tool for complex projects  In its fullest form, PERT involves complex statistical analysis of project schedules and plans

36 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 36 PERT Charts  The basic tool of the PERT technique is the PERT Chart, which represents the schedule and resource needs of a project  The PERT chart uses the Precedence Diagramming Method (PDM), which is similar to a flow chart, to represent the dependencies among activities Task 1 Task 3 Task 6Task 7 Task 8 Task 2Task 5 Task 4 Task 9

37 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 37 A Minimal PERT Chart...  Lists activities to be performed (from WBS)  Indicates dependencies –Activity X must precede activity Y, etc. –This information comes in part from initial planning (life cycle analysis, organizational planning, process definition, etc.)

38 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 38 Sample PERT Chart from Organizational Planning (in early planning steps) PrototypeFinal DesignBuildDesign Keyboard CodeDesign Keyboard Software Test Build Keyboard Emulation Delivery Subcontracted SW for Numeric Key Pad Contract This can be produced by hand or with a project management or scheduling tool.

39 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 39 Steps of PERT Scheduling 1) Basic PERT -- task dependency and flow –shows dependencies, but not timing 2) More Complete PERT -- task duration –shows minimum schedule length 3) Critical path –shows what tasks contribute to minimum schedule length (what tasks need to be shortened to shorten the overall schedule) 4) Full PERT - resource requirements –shows manpower loading, resource needs, etc.

40 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 40  List each task on a “post-it note” or index card  Lay out the tasks on a board  Indicate task dependencies with lines (arcs) Developing a PERT Chart Step 1 - Task Dependencies Task 1 Task 3 Task 6Task 7 Task 8 Task 2Task 5 Task 4 Task 9

41 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 41 Design Test Code Design Spec Integrate Develop Hardware Code VerifyTest Evaluating Dependencies

42 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 42 “Test” Task depends on “Code” and “Test Code” Design Test Code Design Spec Integrate Develop Hardware Code VerifyTest Identifying Dependencies  What depends on what?

43 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 43 Identifying Dependencies  What dependencies are unknown? Design Test Code Design Spec Integrate Develop Hardware Code VerifyTest Who needs this? (no successor)

44 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 44 Identifying Dependencies  What depends on what? Design Test Code Design Spec Integrate Develop Hardware Code VerifyTest External task that we depend on

45 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 45 Finish to Start First task must finish before the second starts Start to Start Second task must start x months after first starts Finish to Finish Second task must finish y months after first finishes Types of PERT Dependencies x y Task 5 Task 2 3 7 6 Task 1Task 3Task 6Task 7 Task 8 Task 4 Task 9

46 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 46  Do not over-constrain -- use only the the essential dependencies  The following PERT chart represents a much more flexible plan With most PERT tools, you can specify a priority among parallel tasks Task 1 Task 3 Task 5 Task 2 Task 4 Task 5 Task 1 Task 3 Task 2 Task 4 Verifying Dependencies

47 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 47 What to Learn from a Task Dependency PERT Chart  Identify dependencies you did not know existed  Identify missing dependencies where you do not know the successor or the predecessor  Identify critical dependencies, such as a hardware activity that will hold you up if it is late

48 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 48 NOTE PERT Charts are a good tool for developing a detailed process description as well as developing a project schedule PrototypeFinal DesignBuildDesign Keyboard CodeDesign Keyboard Software Test Build Keyboard Emulation Delivery Subcontracted SW for Numeric Key Pad Contract

49 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 49 Module Summary  Optimal schedule depends on many factors unique to the project  Models can estimate this, but they are generally inaccurate and you have much flexibility  “Detailed” scheduling uses tools such as PERT, GANTT, and Network charts.  Basic PERT chart shows dependency & flow and can find many problems

50 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 50 References A Professional's Guide to Systems Analysis, Martin E. Modell, 2nd. Ed. McGraw Hill, 1996 U. of West Florida, PERT Home page, http://www.uwf.edu/~coehelp/studentacc ounts/rnew/perthome.html

51 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 8.01 51 END OF MODULE 21


Download ppt "Copyright 1995-2008, Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M21 - Version 8.01 SMU CSE 7315 Planning and Managing a Software Project."

Similar presentations


Ads by Google