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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 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.

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 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?

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 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.

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 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

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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version RELATIVE TIME RELATIVE EFFORT EFFORT = CONSTANT / TIME4 Putnam’s “SLIM” Time vs. Size Equation

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 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.

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 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.)

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 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

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

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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 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.)

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 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.

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 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.

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version  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

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

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

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

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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 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 Task 1Task 3Task 6Task 7 Task 8 Task 4 Task 9

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version  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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M21 - Version References A Professional's Guide to Systems Analysis, Martin E. Modell, 2nd. Ed. McGraw Hill, 1996 U. of West Florida, PERT Home page, ounts/rnew/perthome.html

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