PROJECT SCHEDULING LECTURE NOTES

1. PROJECT SCHEDULINGLECTURE NOTES

2. PROJECT SCHEDULING Software Project Scheduling is an activity that distributes Estimated Effort across the Planned Project Duration by allocating the Effort to specific Software Engineering Task. Project Scheduling is the culmination of a Project Planning activity that is a primary component of Software Project Management. Project Scheduling establishes a “Road Map” for the Project ManagerWhen combined with Estimation Methods and Risk Analysis.

3. PROJECT SCHEDULING Scheduling begins with Process Decompositions. The characteristics of the Project are used to adapt an appropriate task set for the Work to be done. A Task Network depicts each engineering task, its dependency on other tasks and its projected duration. The Task Network is used to compute the Critical Path, a Timeline Chart and a variety of project information. Using the Project Schedule as a guide, the Project Manager can track and control each step in the Software process.

4. BASIC SCHEDULING CONCEPT • The reasons for Software Project failure or late delivery has been mentioned in • the “Project Management” chapter earlier on. Such causes can be summarized • as follows: • WHY SOFTWARE IS DELIVERED LATE? • Most late delivery can be traced to one or more of the following root causes: • An unrealistic deadlines established by someone outside The Software Engineering • group, and forced on Managers and Software practitioners within the group. • 2. Changing Customer Requirements that are not reflected in Schedule changes. • 3. An unhonest underestimate of the amount of effort and / or the number of resources • that will be required to do the job. • 4. Predictable and/or unpredictable risk, that were not considered when the project • commenced. • 5. Technical difficulties that could not have been foreseen in advance. • 6. Miscommunication among project staff that results in delay. • 7. A failure by project Management to recognize that the project is falling behind the • Schedule and a lack of action to correct the problem.

5. BASIC SCHEDULING CONCEPT UNREALISTIC OR UNDERESTIMATED DEADLINES Assume that a Software Engineering team has been asked to build a Real time System that is to be introduced in the Market in nine months. After Careful Estimation and Risk Analysis the Project Manager comes to the conclusion that the Software will receive 14 months to be developed with available staff. HOW SHOULD A PROJECT MANAGER PROCEED IF DEADLINE IS UNDERESTIMATED? - First of all it is unrealistic to march into the customer’s office and demand that the “Delivery Date” be changed. Since the external Market pressure has dictated the date and that the product must be releases. - Secondly, It is equally fool-hardy to refuse undertake (accept) the work from a career stand point. So what to do?

6. BASIC SCHEDULING CONCEPT • The following steps are recommended for Underestimated Deadlines:- • Perform a detailed Estimate using historical data from past projects. Determine the estimated effort and duration for the project. • Using an Incremental Process Model, develop a Software Engineering Strategy that will deliver ‘’Critical functionality’’ by the imposed deadline, but delay other functionality until later and Document the Plan. • 3. Meet Customer with the Project Plan, explain Why the imposed deadline is unrealistic. • Be certain to note that Estimates are based on performance on past projects. • Also be certain to indicate the percent improvement that would be required to archive the • deadline as it currently exists. • 4. Offer the Incremental Development Strategy as an alternative • The Options open to the Project Manager to propose are:- • a) Increase of Budget and buying additional Resources so that you can get the job done in 9 months as required. • b) Propose a reduction in Project Scope in the First Project phase, so that you can deliver the “Core System Functions” in 9 months and then at Phase 2 you can deliver the other secondary functions at the end of 14 months. • c) Dispense with reality and Wish that the project complete in 9 months (Believe a Software Myth). In which we will not be able to deliver anything to customer.

7. PROJECT SCHEDULING The reality of a Technical Project is that hundreds of small tasks must occur in order to accomplish a large goal. Some of these tasks lie outside the main stream and may be completed without worry abut impact On Project Completion Date. Other tasks lie on the “Critical Path”. These tasks are called “Critical Tasks” fall behind schedule the completion date on the entire project is put into jeopardy. The Project Managers Objectives with regards to Project Scheduling are: 1. Define all Tasks. 2. Build a Network that depicts that’s dependencies. 3. Identify the tasks that are Critical within the Network. 4. Track task progress to ensure that delay is recognized. “ One Day at a time “.

8. EVOLUTION OF PROJECT SCHEDULES • It is important to note that the a Project Schedule evolves Over the time. • During early stages of Project Planning, a Macroscopic Schedule is developed. This • type of Schedule identifies all major Process Framework activities and the Product • functions to which they are applied. • As the project gets underway, each entry on the Macroscopic Schedule is refined • into a Detailed Schedule, where specific Software tasks are identified and Scheduled. • Scheduling for Software Engineering Projects can be viewed from two rather different Perspectives :- 1. An End-date for release of Computer-based System has already been established (irrevocable End-date). The Software organization is constrained to distribute Effort within the prescribed Time frame. • 2. Rough chronological bounds have been discussed but that the End-date is set • by the Software Engineering Organization. Effort is distributed to make best use of Resources and the End-date is defined after careful analysis of the Software. • Unfortunately the first situation is encountered for more frequently than the second one.

9. BASIC PRINCIPLES OF SCHEDULING • A number of Basic Principles guide Software Project Scheduling:- • Compartmentalization • Interdependency • Time Allocation • Effort Validation • Defined Responsibilities • Defined Outcomes • Defined Milestones

10. THE RELATIONSHIP BETWEEN PEOPLE AND EFFORT • In a small Software Development Project a Single Person can Analyze Requirements, Perform • Design, Generate codes and Conduct Tests. As the Size of Project increases, more people must • become involved because no company afford the luxury of a 10 man year effort with one person • working on it for 10 years). • There is a common myth that is still believed by many Managers who are responsible for • Software – • ‘’I f we fall behind Schedule, we can always add more Programmers and catch up later in the Project.” • Unfortunately, adding people late in a Project has a two destructive effects on the Project, • causing Schedules to skip even further. • a) The People who are added must learn the System and the People who teach them are the • same people who are doing the work. Therefore, during teaching no work is done, and • the Project falls further behind. • b) More people increase the number of communication paths and the complexity of • communication through additional time. • Over the years Empirical Data and Theoretical Analysis have demonstrated that Project • Schedules are ‘’Elastic’’ since it is possible to compress a desired Project’s Completion date by • adding additional resources to some extent. • It is also possible to extend a Completion date (by reducing the number of Resources).

11. EFFORT COST $ E0 = m ( td4/ta4 ) Ed Impossible Region E0 DEVELOPMENT TIME MAN/YEAR t d t 0 (2td) TMIN=0.75 Td THE PUTNAM- NORDEN- RAYLEIGH CURVE (PNR CURVE) PNR Curve provides an indication of the relationship between Effort applies and Delivery Time for a Software Project. E0 = m ( td4 / ta4 ) Where; E0 = Effort in Person-months td = Nominal Delivery time for schedule t0 = Optimal Development time (in Cost) ta = Actual Delivery time desired.

12. PNR EXAMPLE:Assume that a Project team has estimated a Level of Effort (Ea), that will be required to achieve a Nominal Delivery Time (td), that is Optimal in terms of Schedule and Available Resources. Although it is possible to accelerate Delivery, the Curve rises very properly to the left of t(d). In fact, the PNR Curve indicates that the Project Delivery time cannot be compressed much beyond 0.75(td) . If we attempt to further Compress, the Project moves into the “Impossible Region”, and risk of failure becomes Very high. The PNR curve also indicates that the lowest Cost Delivery option (t0) = 2td.The implication here is that Delaying Project Delivery can reduce Costs; Of course this must be weighted against the Business Costs associated with delay. The number of Source Statement or Delivery Lines of Code (L) is related to Effort and Development Time by the equation. 1/3 4/3 L = (P * E t ) Where, E = Development Effort (Person-months). P = Productivity Parameter (Reflects a variety of factors that lead to high quality Software Engineering work.) Typical Values for P = Ranges between 2000 - 12000. t = is the Project Duration in Calendar Months.

13. Rearranging this Software Equation we can assume that an expression for Development effort. 3 3 4 E = L / (P * t ) where E = Effort expanded in Person-Years over Development and Maintenance. t = Development Time in Person - years. This leads to some interesting results. Let us Consider a complex Real-time Software Project estimated at 33.000 LOC. - Estimated Line of Code 33,000. - 12 Person - years of Effort. - Assigned 8 people Project team. The Project can be completed in approx 1.3 Person -Years. If however, we extend the End-Date to 1.75 Person - years, the highly nonlinear nature of the model yields. 3 3 4 E = L /(P * t ) = ~3.8 yearsThis implies that extending the End-date for six months, we can reduce the Number of people from Eight to Four. Benefits can be gained by using fewer people over a somewhat longer time span to accomplish the same objective

14. EFFORT DISTRIBUTIONThe Software Project Estimation techniques leads to Estimate of Work Unit (e.g. person-month) required to complete Software development.A recommended Distribution of Effort across the Software Process is often referred to as 40-20-40 % Rule. - 40% of all Effort is allocated to Project front-end Analysis and Design phases - 20% for coding (construction phase) - 40% is applied to back-end Testing PhaseThe Effort Distribution Rule should be used as a guideline only.

15. The Characteristic of each Project must dictate the Distribution of Effort. • WorkExpended on Project Planning rarely accounts for more than 2 -3 % • of Effort, unless the Plan commits to large expenditures with high risk. Requirements Analysis may consume 10-25 % of Project Efforts. Analysis of Prototyping should increase in direct proportion with Project Size and Project Complexity. A range of 20-25% of Effort is normally applied to Software Design. • Testing and subsequent Debugging can account for 30-40 % of Development Effort. (The criticality of Software dictates the amount of testing that is required. If software is human life related the Testing rate will be • even higher).

16. CRITICS FOR 40 - 20 - 40 RULE The 40-20-40 Rule is under attack since some Software Engineering Managers believe that More than 40% of overall Effort should be expended during Analysis and Design. Some proponents of Agile Development Method argue that Less time should be expended on “Front-end’’ of Project Phase and that a team should move quickly to Construction Phase (Build phase).

17. DEFINING A TASK SET FOR THE SOFTWARE PROJECT To develop a Project Schedule a Task Set must be distributed on the Project Timeline. The Task Set will vary depending upon the Project Type and the degree of rigor with which the Software Team decides to do its work. Although it is difficult to develop a comprehensive Taxonomy of Software Project types, most Software organizations encountered the following Projects Types:- 1. CONCEPT DEVELOPMENT PROJECTS.(PILOT PROJECT) Initiated to explore some New Business concept of Application or some new Technology. ( When the potential for some new Technology must be explored) 2. NEW APPLICATION DEVELOPMENT PROJECTS Projects undertaken as a consequence of a specific customer request.

18. DEFINING A TASK SET FOR THE SOFTWARE PROJECT 3. APPLICATION ENHANCEMENT PROJECTS Occur when Existing Software Undergoes major modifications to function, Performance on interfaces that an observable by the end-user. 4. APPLICATION MAINTENANCE PROJECTS That connect, adapt or extend Existing Software on ways that may not be immediately obvious to the end-user. 5. REENGINEERING PROJECTS Project undertaken with the intent of rebuilding an Existing System in whole or part. Even within a single Project type, many factors influence the Task set to be chosen.

19. DEFINING A TASK SET FOR THE SOFTWARE PROJECT • The factors that influences the Task Set selection include : • - Size of the Project • - No. Of potential users • - Mission Criticality • - Application longevity • - Stability of requirements • - Ease of customer/developer communication • - Maturity of applicable technology • - Performance consideration • - Embedded/non embedded characteristics • - Project Staff • Re-engineering factors • When taken in combination, these factors provide an indication of the • Degree of rigor with which the Software Process should be applied.

20. DEFINING A TASK SET FOR THE SOFTWARE PROJECT • AN EXAMPLE TASK SET • Some Major Task set that can be considered in a Concept Development Project are : • 1.1 CONCEPT SCOPING • 1.2 PRELIMINARY CONCEPT PLANNING • 1.3 TECHNOLOGY RISK ASSESSMENT • 1.4 PROOF OF CONCEPT • 1.5 CONCEPT IMPLEMENTATION • 1.6 CUSTOMER REACTION • These Major Tasks may be used to define a Macroscopic Schedule for a Project. • However the macroscopic Schedule must be refined to create a Detailed Project Schedule. • Requirement begins by taking each Major Task and decomposing it into a set • of subtasks with relatedWork Products and Milestones

21. DEFINING A TASK SET FOR THE SOFTWARE PROJECT • An Example of Task Decomposition • Consider decomposition of Major Task 1 (CONCEPT SCOPING) • TASK 1. CONCEPT SCOPING • 1 .1. IDENTIFY NEED BENEFITS AND POTENTIAL CUSTOMER • 1. 2 DEFINE DESIRED OUTPUT/CONTROL AND INPUT EVENTS • 1..3 REVIEW WRITTEN DESCRIPTION OF NEED • ......................... • 1.3.1 DEFINE THE FUNCTIONALITY/BEHAVIOR OF EACH MAJOR FUNCTION • 1.3.2 REVIEW OUTPUT/INPUT OBJECTIVES • 2. PRELIMINARY INVESTIGATION . • etc….. • The Tasks and Sub-tasks form the basis for a Detailed Schedule for the Concept Scoping Activity.

22. DEFINING A TASK NETWORK Individual Tasks and subtasks have ‘Interdependencies’ based on their sequence. In addition, when more than one person is involved in a Software Engineering Project it is likely that development activities and Tasks will be performed in Parallel. When this occurs, Concurrent tasks must be coordinated so that they will be Complete when Later Tasks require their Work products. A TASK NETWORK, also called ‘’Activity Network’’, is a graphical representation of the Task flow for a Project. It is sometimes used as the mechanism through which Task sequence and dependencies are input to an automated Project Scheduling tool.

23. DEFINING A TASK NETWORK The concurrent nature of Software Engineering activities leads to a number of important Scheduling requirements. Because parallel tasks occur asynchronously the Project Planner must determine ‘Inter- task Dependencies’ to ensure continuous progress toward completion. In addition, the Project Manager should be aware ofCritical Taskswhich are those Tasks that lie on theCritical Path. Critical Tasks must be completed on time if the Project as a whole is to be completed on Schedule. Interdependencies among Tasks may be defined using a Task Network.

24. PROJECT SCHEDULING METHODS Scheduling of a Software Project does not differ greatly from Scheduling of any multitask Engineering effort. Therefore, generalized project Scheduling tools and techniques can be applied with little modification for Software Projects. PERT (Program (Project) Evaluation and Review Technique) and the CPM (Critical Path Method are two Project Scheduling Methods that can be applied to Software development. Both techniques are driven by information already developed in early Project Planning activities such as:- - Estimates of Effort - A decomposition of Product function - Selection of the appropriate Process Model and task set - Decomposition of Tasks

25. PROJECT SCHEDULING METHODS Tasks sometimes called the Project Work Breakdown Structure (WBS), are defined for the Product as a whole or for individual function. Both PERT and CPM provide Quantitative Tools that allow the Software Planner to: a) Determine the Critical Path b) Establish “Most Likely” Time Estimates for individual tasks c) Calculate “Boundary times” that define a time Window for a particular task.

26. Work BreakedownStructure (WBS)

27. REPRESENTING & SCHEDULING PROJECT PLANS The Most commonly used methods are :- GANTT CHART NETWORK DIAGRAMS (PERT CHART)

28. GANTT CHART • A graphical representation of a Project that shows each task as a horizontal bar whose length is proportional to its time for completion. • A GANTT Chart is a horizontal bar chart that illustrates a Project schedule. • In the GANTT Chart Time is displayed on the horizontal axis and the Tasks/ Activities are arranged vertically from top to bottom, in order of their start dates. • A detailed GANTT Chart for a large project might be quite complex and hard to understand. To simplify the chart Project manager can combine related activities into one Task.

29. GANTT CHART A graphical representation of a Project that shows each task as a horizontal bar whose length s proportional to its time for completion. GANTT CHART do not show how tasks must be ordered (precedence) but simply show when a task should begin and should end GANTT Chart is often more useful to for depicting relatively simple projects or sub projects of a large project, the activities of a single worker, or for monitoring the progress of activities compared to scheduled completion dates..

30. GANTT CHART

31. NETWORK DIAGRAM PROJECT EVALUATION AND REVIEW TECHNIQUE (PERT) PERT Is a graphical depiction of Project tasks and their inter-relationships. The distinguishing feature of a Network Diagram is that the ordering of Tasks is shown by connecting with its Predecessor and Successor tasks. Network Diagramming is a Critical Path Scheduling Technique used for controlling Resources. CRITICAL PATH SCHEDULING A scheduling technique whose order and duration of a sequence of task activities directly affect the Completion Date of a Project

32. PERT CHART You would use a Network Diagram when Project Tasks:- Are well defined and have clear beginning and end point Can be worked on independently of other tasks Are ordered Serve the purpose of project

33. PERT CHART • One of the most difficult and most error prone activities when constructing a Project Schedule is the determination of the TIME DURATION for each task within a Work Breakdown Structure (WBS), specially when there is a high degree of complexity and uncertainty about a task. • PERT is a technique used to calculate the Expected Duration for a tasks. • PERT is a technique that uses Estimates for: • Optimistic time (O), • Pessimistic time (P) • Realistic Time (R) • To calculate the EXPECTED DURATION (ED) of a particular task.

34. PROGRAM EVALUATION REVIEW TECHNIQUE (PERT) • PERT is a technique that uses Optimistic time (O), Pessimistic time (P) and Realistic Time (R) estimates to calculate the EXPECTED Duration (ED) of a particular task. • The Optimistic time (O) and Pessimistic time (P) reflects the minimum and maximum possible periods of time for an activity to be completed. • The Realistic time (R) or the Most likely time , reflects the Project Manager’s “Best Guess” of the amount of time required for a task completion.

35. PROGRAM EVALUATION REVIEW TECHNIQUE (PERT) CALCULATING EXPECTED COMPLETION TIME (ET) ED = [O + (4* R) + P] / 6 Because the Expected Duration should be closer to the Realistic Time (R), it is typically weighed Four times more than the Optimistic time (O) and the Pessimistic time (P). Once you add these values together , it must be divided by 6 to determine the Expected Duration for a task.

36. HOW TO CONSTRUCT A NETWORK DIAGRAM (PERT CHART) DEVELOPING A NETWORK DOAGRAM IS A FOUR STEP PROCESS:- • Identify each Project Task to be completed • Determine Time Estimates and calculate Expected Duration for each Activity • For each Task, identify the immediatePredecessor Tasks • Enter the Task with connecting Arrows based onDependenciesand calculate Start and End-Times based on Duration and Resources.

37. PERT CHART SYMBOLS PERT Chart is consisted of TASKS and EVENTS.An EVENT is called a Milestone, representing a point in time, such as the Start or Completion of a Task. A circle or a Rectangle shape NODE is used to represent an EVENT. Event ID ECT (Earlier Completion Time) LCT (Latest Completion Time) Every PERT Chart has one Beginning and one End NODE that represents the Start and Finish of a Project. The Earliest and Latest Completion Time is both Zero in Starting Event. Task ID A TASK is depicted by an ARROW Connecting Events. A Dashed Arrow represents a DUMMY TASK which is the dependency between two Events without requiring any resource (Duration is zero).

38. SLACK TIME:- The Slack Time available for any Task is equal to the difference between the Earliest Completion Time (ECT) and the Latest Completion Time (LCT) SLACK TIME = (LCT – ECT) CRITICAL PATH Is a sequence of Dependent Tasks that have the Largest sum of Estimated DURATION (ed) . Critical Path is the Path that has no Slack Time built in. • The Critical Path on PERT chart is shown with thick Dark line. To find the Critical Path begin with identifying all alternative Paths that exist from First Event to the FinalEvent on the PERT Chart.

40. PERT CHART A PERT CHART EXAMPLE A Project Planning Table is used to draw a PERT Chart. The Project Planning Table is created from the Project Work Breakdown Structures (WPDS) Table, with some additional Project information such As:- • Expected Duration (calculated using Three point Estimation Equation) • Preceding Event, • Succeeding Event, • Earliest Completion Time / Date (ECT) • Latest Completion Time / Date (LCT)

42. CRITICAL PATH = (A + B + C + D + DUMMY TASK + H) (3 + 2 + 2 + 7 + 0 + 5 ) = 19 Person - day A PROJECT PLANNING TECHNIQUE

43. GANTT CHART vs PERT CHART • GANTT Chart visually shows the Duration of Tasks; whereas a PERT Chart visually shows the Sequence dependencies between tasks. • GANTT Chart visually shows theTime Overlap of Tasks;whereas a PERT Chart does not show time overlap but does show which Tasks could be done in parallel. • Some form of GANTT Chart can visually showSlack Timeavailable within an Earliest Start Time and Latest Finish (Completion) Time.. • Giving that all Software Project have some Intertask Dependency as well as offering opportunities for Task Overlapping, PERT and GANTT Charts should not be considered as alternative Project Management approaches but rather Complementary techniques for Project planning, Scheduling, Evaluation and Control of Software Project development. • PERT Chart is recommended for Large Projects with high ‘’Inter-task Dependencies’’ and the GANTT chart for simpler Projects.

44. GANTT CHART vs PERT CHART • Most Project Managers find PERT Chart very helpful for Scheduling, Monitoring and Controlling Projects. • However, still most Software Project Managers seem to prefer GANTT Chart because of its simplicity and ability to produce various levels of Project Schedules (ie. Project Schedules for individual resorce etc.) as well as easyness of Reporting Project progress to all concerns. • Most Project Planning CASE tools allow GANTT Chart to be temporarly displayed as PERT Chart for a different prespective. • Microsoft Project CASE tool is a typical example that works this way.

45. GANTT CHART v.s PERT CHART

46. EARNED VALUE ANALYSIS (EVA)

47. EARNED VALUE ANALYSIS Earned Value Analysis is a Quantitative technique for assessing progress as the software Project team moves through the work tasks allocated to the Project Schedule Provides a common value scale for every project task Total Hours to do the Project are estimated, and every task is given an Earned Value based on its Estimated (%) of Total . Earned Value is a measure of ‘’Progress’’ to assess ‘’Percentage of Completeness’’

48. EARNED VALUE ANALYSIS (EVA) STEPS IN DETERMINING EVA The Budgeted Cost of Work Schedule (BCWS) for each task determined in Person-hours during estimation. The BCWS value for all work tasks are summed to derive the ‘’Project Budget At Completion’’ (BAC) BAC = ∑ (BCWS )

49. EARNED VALUE ANALYSIS (EVA) STEPS IN DETERMINING (EVA) 3. Compute Budgeted Cost of Work Performed (BCWP) BCWP = ∑ (BCWS) BCWP is the sum of BCWS for all work tasks has actually been completed by a point in time on the project Schedule.) BCWS represents the Budget of Activities that were Planned to be Completed. BCWP represents the Budget of Activities that were actually completed.

50. EARNED VALUE ANALYSIS (EVA) STEPS IN DETERMINING (EVA) Given Value for BCWS, BAC and BCWP important Progress Indicators can be computed. SHEDULED PERFORMANCE INDEX (SPI) SPI = (BCWP / BCWS) SPI is an Indication of the Efficiency with which the Project is utilizing Scheduled resources. SPI close to (1.0) indicates efficient execution of the Project Schedules.