250 likes | 834 Views
Chapter 24. Project Scheduling. Software Engineering: A Practitioner’s Approach 6 th Edition Roger S. Pressman. Reasons for Late Delivery of S/W. An unrealistic deadline Changing customer requirements An honest underestimate of the amount of effort and/or the number of resources
E N D
Chapter 24 Project Scheduling Software Engineering: A Practitioner’s Approach 6th Edition Roger S. Pressman
Reasons for Late Delivery of S/W • An unrealistic deadline • Changing customer requirements • An honest underestimate of the amount of effort and/or the number of resources • Predictable and/or unpredictable risks that skipped consideration • Unforeseen technical difficulties • Unforeseen human difficulties • Miscommunication among project staff • Lack of tracking and corrective activities
How to get rid of an unrealistic deadline? • Perform a detailed estimate using historical data • Use an incremental process model • Deliver critical functionality by the imposed deadline, delay other functionality until later • Meet with the customer and explain why the imposed deadline is unrealistic • Indicate the percent improvement required • Offer the incremental development strategy as an alternative
Project Scheduling • S/W project scheduling is an activity that distributes estimated effort across the planned project duration by allocating the effort to specific s/w engineering tasks • Can be viewed from two different perspectives • Pre-established end-date for release • Encounters far more frequently • End-date set by the s/w engineering organization
Basic Concepts • Compartmentalization • Interdependency • Time allocation • Effort validation • Defined responsibilities • Defined outcomes • Defined milestones
The Relationship Between People and Effort (1) Figure 24.1: Putnam-Norden-Rayleigh (PNR) Curve
The Relationship Between People and Effort (2) • The s/w equation [PUT92] introduced in Chapter 23 is derived from the PNR curve • L = PE1/3t4/3 • [E in person-months, t in months] • E = L3/(P3t4) • [E in person-years, t in years] • Demonstrates the highly nonlinear relationship between time and effort
Effort Distribution • 40-20-40 rule • 40% of effort for front-end analysis and design • 20% of effort for coding • 40% of effort for back-end testing • But the characteristics of each project must dictate the distribution of effort
Defining a Task Set for the Software Project (1) • A task set is a collection of s/w engineering work tasks, milestones, and work products • No single task set is appropriate for all projects • A task set must be distributed on the project time line
Defining a Task Set for the Software Project (2) • Most s/w organizations encounter the following projects • Concept development projects • New application development projects • Application enhancement projects • Application maintenance projects • Reengineering projects
Defining a Task Set for the Software Project (3) • Even within a single project type, many factors influence the task set to be chosen • These include • Size of the project • Number of potential users • Mission criticality • Stability of requirement • And many more
A Task Set Example • Major tasks • Concept scoping • Preliminary concept planning • Technology risk assessment • Proof of concept • Concept implementation • Customer reaction • Refinement of major tasks
Defining a Task Network (1) • A task network, also called an activity network, is a graphic representation of the task flow for a project • The task network depicts major s/w engineering tasks • The project manager should be aware of those tasks that lie on the critical path
Defining a Task Network (2) Figure 24.2:A Task Network for Concept Development
Scheduling (1) • Project scheduling methods • Program Evaluation and Review Technique (PERT) • Critical Path Method (CPM) • Driven by information already developed in earlier project planning activities • Estimates of effort • A decomposition of the product function • The selection of the appropriate process model and task set • Decomposition of tasks
Scheduling (2) • Both PERT and CPM provide quantitative tools that allow the s/w planner to • Determine the critical path – the chain of tasks that determines the duration of the project • Establish “most likely” time estimates for individual tasks by applying statistical models • Calculate “boundary times” that define a time “window” for a particular task
Tracking the Schedule • Ways of tracking - • Conducting periodic project status meetings • Evaluating the results of all reviews conducted • Check for completion of project milestones in due date • Comparing actual start-date to planned start-date • Meeting informally with practitioners to obtain their subjective assessment • Using earned value analysis to assess progress quantitatively • Control is must (light or tight depending on situation) • Can employ time-boxing when faced with severe deadline pressure
Earned Value Analysis (1) • Is a measure of progress • Permits quantitative analysis • Basic terms • BCWS (Budgeted Cost of Work Scheduled) • BCWSi = the effort planned for work task i • BAC (Budget At Completion) • BAC = (BCWSk) for all tasks k • BCWP (Budgeted Cost of Work Performed) • ACWP (Actual Cost of Work Performed)
Earned Value Analysis (2) • Schedule Performance index • SPI = BCWP / BCWS • Schedule Variance • SV = | BCWP – BCWS | • Percent Scheduled for Completion • PSC = BCWS / BAC • Percent Complete • PC = BCWP / BAC • Cost Performance index • CPI = BCWP / ACWP • Cost Variance • CV = | BCWP – ACWP |
Chapter 24 • Everything except 24.5.3 • Exercises • 24.7, 24.12