Project Scheduling & Tracking

1. Project Scheduling & Tracking

2. 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

3. “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 criticaltasks • track the progress of these tasks • recognize the delay “one day at a time”

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

5. 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

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

7. 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

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

9. 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%

10. Effort Distribution (2-3%) (20-25%) (30 - 40%) (20-25%) (15 -20%)

11. 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 software engineering tasks

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

13. 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

14. 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

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

16. Defining a task Network • Task Network is a graphic representation of the task flow for the project. • It shows all the SE tasks • First it is created at a macroscopic level • Tasks on the critical path (chain of tasks determining the duration of the project) are marked • Size of the Project

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

20. 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

21. 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

22. 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

23. Timeline/Gantt Chart Project Activities Jan Feb Mar Apr May June Milestone

24. Project Table

25. 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

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

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