Objectives

1. Objectives • Develop the necessary understanding and skills to produce and manage a simple project schedule.

2. Scheduling and Planning • So far we have a project for which we have estimated duration and effort based on a high level understanding of what needs to be done. • The majority of projects are 'completed' late, if at all. • A project schedule is required to ensure that required project commitments are met. • A schedule is required to track progress toward achieving these commitments.

3. Why Software Is Delivered Late? • An unrealistic deadline • Changing but unpredicted customer requirements • Underestimation of efforts needed • Risks not considered at the project start • Unforeseen technical difficulties • Unforeseen human difficulties • Miscommunication among project staff • Failure to recognize that project is falling behind schedule

4. “One day a time” • All technical projects involve 100s of small tasks • Some tasks do no affect the project completion • Other tasks are critical for project completion • Project manager must: • define all project tasks • build a network that depicts their interdependence • identify the critical tasks • track the progress of these tasks • recognize the delay “one day at a time”

5. Two different Perspectives to view Scheduling End date for completion has been finalized Only Rough time-frame is given

6. Basic Principles for SE Scheduling • Compartmentalization – define distinct tasks • Interdependency- parallel and sequential tasks • Time allocation - assigned person days, start time, ending time) • Effort validation - be sure resources are available • Defined responsibilities — people must be assigned • Defined Outcomes- each task must have an output • Defined milestones - review for quality

7. People and Effort “If we fall behind schedule we can always add more programmers and catch to late in the project” Has a disruptive effect on the project Schedules slip even further

8. People and Effort The relationship between the number of people working in software project and overall productivity is not linear Fewer people and longer time period is a better option for software development

9. Effort Distribution 40-20-40 Front-end Analysis & Design Back-end testing Coding

10. Effort Allocation • “front end” activities • customer communication • analysis • design • review and modification • construction activities • coding or code generation • testing and installation • unit, integration • white-box, black box • regression 40-50% 15-20% 30-40%

11. Effort Distribution (2-3%) RA (20-25%) Testing (30 - 40%) (20-25%) SD (15 -20%) Coding

12. Scheduling and Planning In order to make a schedule, the following tasks must be completed: • Identify manageable activities and tasks by decomposing the process and the product. • Determine which tasks are dependent on the completion of others. (Which activities must occur in sequence and which can occur concurrently.) • Allocate each task a number of work-units (often person-days), a start date and a completion date. • Define responsibilities for the tasks (allocate them to a person or persons). • Define outcomes of the tasks (deliverables) and milestones for the schedule. • Review the proposed tasks, their effort allocation and start and end dates with the people involved to ensure there are no conflicts and over allocation.

13. Identifying Tasks The first step : identify the tasks required to be performed. These tasks will comprise software engineering activities broken down for product functions. A schedule is not a fixed entity and as such it will be refined as a project progresses. • Initially rough a project schedule usually refers to the work tasks, deliverables and milestones for major software engineering activities and major product functions • is refined in detail as the project progresses to refer to specific tasks and activities that must be completed for those major activities and functions.

14. Selecting Project Tasks No set of tasks is appropriate for all projects. The set of tasks that are appropriate for a project depends on a number of factors. These include: • The process model selected. An iterative development model would require different tasks, etc... than would a waterfall model or rapid application development model. • The type of project. A new development project has a different set of tasks to a maintenance project or to a concept development. • The size and complexity of the product. • The rigor required in development. This is a factor generally determined by things like product size, mission criticality, stability of requirements, etc...

15. Selecting Project Tasks Many software engineering tasks have deliverables. For example, the Software Requirements Specification (SRS) might be the deliverable produced as a result of requirements analysis. Milestones are objectively identifiable points in a project. They are generally associated with the completion of a major activity. It is often a good idea to associate them with deliverables. For example, a milestone might be established at initial requirements sign-off. This checkpoint will come after the requirements documents have been produced, inspected, corrected and signed off on. The only rule for establishing a checkpoint is that you must be able to objectively determine if that milestone has been reached.

16. Selecting Project Tasks • Milestone = end-point of a specific, distinct software process activity or task (for each milestone a report should be presented to the management) • Deliverable= project result delivered to the client • In order to establish milestones the phases of the software process phases need be divided in basic activities/tasks.

17. Defining Task Sets • determine type of project • assess the degree of rigor required • identify adaptation criteria • compute task set selector (TSS) value • interpret TSS to determine degree of rigor • select appropriate softwareengineering tasks

18. Software Project Types • Concept Development projects • New Application Development Projects • Application Enhancement Project • Application Maintenance Project • Reengineering Project

19. Degree of Rigor • Casual • Minimum task set is required • Umbrella tasks are minimized • Documentation requirements are reduced • Basic principles of SE are applicable • Structured • Framework activities will be applied • Umbrella tasks are applied • Documentation and measurement tasks will be done in a streamlines manner • Strict • Full process will be applied • Degree of discipline ensures high quality • All umbrella activities will be applied • Robust work products will be produced • Quick Reaction • Process framework will be applied • Only essential tasks will be undertaken • Documentation will be provided after product delivery

20. Adaptation Criteria • Size of the Project • Number of potential users • Mission criticality • Application Longevity • Stability requirements • Ease of communication • Maturity of technology • Performance constraints • Embedded and non-embedded characteristics • Project staff • Reengineering factors 1 5

21. Based on adaptation criteria, TSS is computed Task Set selector Casual TSS > 1.2 Structured 1.0 < TSS < 3.0 Strict TSS > 2.4

22. Activity Network Diagrams An activity network diagram provides a notation for documenting • a network of tasks needed to complete a project, • their interdependencies • the times required for each task. There are a number of activity network techniques which are similar in nature. The most commonly used include PERT (Project Evaluation and Review Technique) and CPM (Critical Path Method).

23. Pert Chart A simple PERT chart comprises circles (nodes) to represent events within the development lifecycle For example commencement / completion of tasks, and lines (edges) which represent the the tasks. The lines are additionally labeled by the estimated duration of the task. Note: there are a number of variations to this notation. A real PERT chart shows earliest time to completion, latest time to completion, and slack in the circles also.

24. How to construct a PERT chart The basic steps to constructing a PERT chart are: • Identify tasks and estimate duration of times • Identify a single start and end event • Arrange events in sequence (give events a unique number) • Establish start and finish times of each task. Keep in mind the estimates made for duration and effort. • Determine float • Revise

25. C 2d 2 1 4 5 3 A 2d E 2d B 2d D 5d Pert Chart As an example of using a PERT chart, consider the following simple chart showing a project with tasks A,B,C,D and E This diagram states that tasks A,B,C and E will take 2 days (assume d is abbreviation for days) and task D has a planned duration of 5 days. Task D is dependent on completion of task B, etc.

26. The Critical Path The critical path is the path between the start event and end event which takes the longest time. Note that: • No task on the critical path can take longer without extending the end date of the project. • Tasks on the critical path are called critical tasks. • No critical task can have any slack. • Tasks on the critical path must be carefully monitored.

27. 2 4 C 2d A 2d E 2d 1 5 B 2d D 5d 3 The Critical Path In the example above the critical path can be described by events 1,3 and 5 or by tasks B,D. This is because the time to reach the end event (5) on this path is longer than any other path. This means that task B must take no longer than 2 days and task D no longer than 5 days or the end date for event E will need to be extended. The duration of the other path is 6 days. Because the critical path is 7 days, there is slack (or float) of one day on the other path. This means that this path can take 1 day longer than planned. That is, any one task on this path (A,C or E) can take 1 day longer than expected. Note this slack must be shared between the tasks on this other path. They can not all take an extra day

28. Project Scheduling Program Evaluation and Review Technique(PERT) Critical Path Method (CPM)

29. Project Scheduling Both techniques (PERT and CPM) are driven by information already developed in earlier project planning activities: • Estimates of efforts • Decomposition of product function • selection of appropriate process model and task set • Decomposition of tasks

30. Project Scheduling • Both PERT and CPM provides quantitative tools to • determine the critical path • establish the most likely time estimated for individual tasks by applying statistical models • calculate boundary time (window) for a particular task

31. Project Scheduling Important boundary times for PERT and CPM Total float - the amount of surplus time allowed in scheduling tasks so that the network critical path is maintained on schedule Earliest time a task can begin when all preceding tasks are completed in shores possible time Earliest finish - the sum of the earliest start and the task duration Latest finish - the latest start time added to task duration Latest time for task initiation before the minimum project completion time is delayed

32. Gantt Charts GANTT charts are a project planning tool that can be used to represent the timing of tasks required to complete a project. It describes similar information to a PERT chart. Here is one that was produced automatically with a project management tool from the PERT chart info above:

33. Project Table

34. Tracking the Project Schedule • It is a road map for the Software Project • It defines the tasks and milestones • Tracking can be done by: • Conducting periodic project status meetings • Evaluating the results of all reviews • Determining whether milestones were reached by the scheduled date • Compare actual start date to planned start date • Meeting informally with professionals to get their subjective opinion • Using earned value analysis

35. Tracking Earned Value The earned value system provides a common value scale for every task, regardless of the type of work being performed. The total hours to do the whole project are estimated, and every task is given an earned value based on its estimated percentage of the total. Basically, earned value is useful as it provides a quantitative technique of assessing progress on the project as a whole (even when tasks are completed in an order that differs from the original schedule)

36. Tracking Earned Value Example Consider the following project

37. Calculating the planned Value The planned value for a task is the estimated percentage of the planned duration of that task of the total planned duration of all tasks. Planned ValueT = DT / TD where T is a task, DT is the duration of T and TD is the total planned duration of all tasks. Applying this formula we calculate the planned value for the planning task from the above table. We have estimated that planning will take 180 minutes. The total duration of all of our estimates for development is 2305 minutes. The planned value for the planning task by the formula above is, therefore, given by Planned Value = 180/2305 ~ 7.81%

38. Calculating the planned Value We write this value in the planned value (unit) column for the planning task. We do the same for all of the tasks in the plan. The total of all of the unit planned values will be 100% if this is done correctly.

39. Calculating the planned Value We also wish to document when we expect each task to be completed. In this example, this has been done by filling in the week number in the planned completion column. In order to track progress against this plan, we should have an idea of what percentage complete we expect to be at the end of each week. Notice that in the table below (most of) our tasks are listed in order of expected completion (not necessary, but advisable to start with). We keep a cumulative total of the planned value in the cumulative planned value column. We can use this column to determine what percentage of the project will be complete by the end of week 3, for example. We can see that the sum of all of the planned values for tasks planned to be complete before the end of week 3 is approx. 48.81% (because the tasks are in order, the cumulative planned value for the last week 3 entry gives us this number - if the tasks are listed unordered by completion date, the sum must be calculated by adding the planned values of all tasks due to be completed before the date in question). In the next section, we describe how to use this information to track progress.

40. Tracking a Project with Earned Value Ok we have reached the end of the second week on this project and we need to know how our progress toward completion on time. We haven't done everything in the order in which it was planned, so this may not be easy to guess at. We can use the concept of an earned value. Earned value is assigned only to completed tasks. If I have completed a task with a planned value of p%, then the earned value for that task is p%. Incomplete tasks have no earned value. In the example below, compiled at the end of the second week, we see that the group has completed the following tasks with their associated earned value: • Planning - 7.81% • Scope - 2.64% • Product Features - 2.64% • User Profile - 1.98% • Assumptions - 2.64% • UI requirements - 5.21% By summing the earned values for the completed tasks we determine that at the end of week 2, the cumulative earned value (the percent complete) is 7.81+2.64+2.64+1.98+2.64+5.21=22.91%. Now, knowing the earned value the project group can determine if they are ahead, behind on on schedule to complete on time

41. Tracking a Project with Earned Value Looking at the cumulative planned value in the table, we see that at the end of week 2 to be on schedule, the group should have been 33.19% complete. By the above calculation that they are actually only 22.91% complete, it appears that the project is falling behind schedule.

42. Tracking a Project with Earned Value Knowing this allows the project team to take action. Such action may involve • adjusting work practices, • negotiating with the client for an extension to the deadline, • etc... It is argued that earned value provides accurate and reliable readings of performance as early as 15% into a project. This kind of quantitative project management is essential if projects are to be consistently delivered on time.

43. Tracking the Project Schedule Administer Project Resources Cope with problems Control Direct Project staff

44. Tracking the Project Schedule Project is on schedule and within budget Additional resources focussed on problem area Project Tracking Staff may be redeployed Problem diagnosed Project Schedule can be redefined