SWE311_Ch24 (071) Software & Software Engineering Slide 1
Chapter 24Chapter 24Project Scheduling and TrackingProject Scheduling and Tracking
SWE311_Ch24 (071) Software & Software Engineering Slide 2
Why Are Projects Late?Why Are Projects Late? an unrealistic deadline established by someone outside the an unrealistic deadline established by someone outside the
software development groupsoftware development group changing customer requirements that are not reflected in changing customer requirements that are not reflected in
schedule changes;schedule changes; an honest underestimate of the amount of effort and/or the an honest underestimate of the amount of effort and/or the
number of resources that will be required to do the job;number of resources that will be required to do the job; predictable and/or unpredictable risks that were not considered predictable and/or unpredictable risks that were not considered
when the project commenced;when the project commenced; technical difficulties that could not have been foreseen in technical difficulties that could not have been foreseen in
advance;advance; human difficulties that could not have been foreseen in advance;human difficulties that could not have been foreseen in advance; miscommunication among project staff that results in delays;miscommunication among project staff that results in delays; a failure by project management to recognize that the project is a failure by project management to recognize that the project is
falling behind schedule and a lack of action to correct the falling behind schedule and a lack of action to correct the problemproblem
SWE311_Ch24 (071) Software & Software Engineering Slide 3
How to Deal With Unrealistic How to Deal With Unrealistic Schedule DemandsSchedule Demands
Perform a detailed project estimate for project Perform a detailed project estimate for project effort and duration using historical data. effort and duration using historical data.
Use an incremental process model that will Use an incremental process model that will deliver critical functionality imposed by deadline, deliver critical functionality imposed by deadline, but delay other requested functionality. but delay other requested functionality.
Meet with the customer and explain why the Meet with the customer and explain why the deadline is unrealistic using your estimates based deadline is unrealistic using your estimates based on prior team performance. on prior team performance.
Offer an incremental development and delivery Offer an incremental development and delivery strategy as an alternative to increasing resources strategy as an alternative to increasing resources or allowing the schedule to slip beyond the or allowing the schedule to slip beyond the deadline. deadline.
SWE311_Ch24 (071) Software & Software Engineering Slide 4
Project Scheduling PerspectivesProject Scheduling Perspectives
One view is that the end-date for the software release is set One view is that the end-date for the software release is set externally and that the software organization is constrained to externally and that the software organization is constrained to distribute effort in the prescribed time frame. distribute effort in the prescribed time frame.
Another view is that the rough chronological bounds have Another view is that the rough chronological bounds have been discussed by the developers and customers, but the end-been discussed by the developers and customers, but the end-date is best set by the developer after carefully considering date is best set by the developer after carefully considering how to best use the resources needed to meet the customer's how to best use the resources needed to meet the customer's needs.needs.
SWE311_Ch24 (071) Software & Software Engineering Slide 5
Scheduling PrinciplesScheduling Principles compartmentalizationcompartmentalization— the product and process must be — the product and process must be
decomposed into a manageable number of activities and tasks decomposed into a manageable number of activities and tasks
interdependencyinterdependency—indicate task interrelationship —indicate task interrelationship
Time allocationTime allocation - every task has start and completion dates that - every task has start and completion dates that take the task interdependencies into account take the task interdependencies into account
effort validationeffort validation—be sure resources are available—be sure resources are available
defined responsibilitiesdefined responsibilities— every scheduled task needs to be — every scheduled task needs to be assigned to a specific team member assigned to a specific team member
defined outcomesdefined outcomes—each task must have an output—each task must have an output
defined milestonesdefined milestones— a milestone is accomplished when one or — a milestone is accomplished when one or more work products from an engineering task have passed quality more work products from an engineering task have passed quality review review
SWE311_Ch24 (071) Software & Software Engineering Slide 6
Relationship Between People and EffortRelationship Between People and Effort
Common myth: Adding people to a project after it is behind schedule often causes the Adding people to a project after it is behind schedule often causes the
schedule to slip further schedule to slip further
The relationship between the number of people on a project The relationship between the number of people on a project and overall productivity is not linear (e.g., 3 people do not and overall productivity is not linear (e.g., 3 people do not produce 3 times the work of 1 person, if the people have to produce 3 times the work of 1 person, if the people have to work in cooperation with one another) work in cooperation with one another)
The main reasons for using more than 1 person on a project The main reasons for using more than 1 person on a project are to get the job done more rapidly and to improve software are to get the job done more rapidly and to improve software quality.quality.
SWE311_Ch24 (071) Software & Software Engineering Slide 7
Effort and Delivery TimeEffort and Delivery Time
Effort Cost
Impossible region
td
Ed
Tmin = 0.75T d
to
Eo
Ea = m (td4/ ta
4)
development time
Ea = effort in person-months
td = nominal delivery time for schedule
to = optimal development time (in terms of cost)
ta = actual delivery time desired
SWE311_Ch24 (071) Software & Software Engineering Slide 8
The project scheduling processThe project scheduling process
Estimate resourcesfor activities
Identify activitydependencies
Identifyactivities
Allocate peopleto activities
Softwarerequirements
Create projectcharts
Activity, bar, Gantt Charts
SWE311_Ch24 (071) Software & Software Engineering Slide 9
Effort AllocationEffort Allocation
40-50%40-50%
30-40%30-40%
““front end” activitiesfront end” activities customer communicationcustomer communication analysisanalysis designdesign review and modificationreview and modification
construction activitiesconstruction activities coding or code coding or code
generationgeneration testing and installationtesting and installation
unit, integrationunit, integration white-box, black boxwhite-box, black box regression regression
15-20%15-20%
SWE311_Ch24 (071) Software & Software Engineering Slide 10
Project Effort DistributionProject Effort Distribution The 40-20-40 rule (a rule of thumb): The 40-20-40 rule (a rule of thumb):
40% front-end analysis and design 40% front-end analysis and design
20% coding 20% coding
40% back-end testing40% back-end testing
Generally accepted guidelines are: Generally accepted guidelines are: 02-03 % planning 02-03 % planning
10-25 % requirements analysis 10-25 % requirements analysis
20-25 % design 20-25 % design
15-20 % coding 15-20 % coding
SWE311_Ch24 (071) Software & Software Engineering Slide 11
Software Project TypesSoftware Project Types Concept development - initiated to explore new business Concept development - initiated to explore new business
concept or new application of technology concept or new application of technology
New application development - new product requested by New application development - new product requested by customer customer
Application enhancement - major modifications to function, Application enhancement - major modifications to function, performance, or interfaces (observable to user) performance, or interfaces (observable to user)
Application maintenance - correcting, adapting, or extending Application maintenance - correcting, adapting, or extending existing software (not immediately obvious to user) existing software (not immediately obvious to user)
Reengineering - rebuilding all (or part) of a legacy systemReengineering - rebuilding all (or part) of a legacy system
SWE311_Ch24 (071) Software & Software Engineering Slide 12
Factors Affecting Task SetFactors Affecting Task Set A task set is a collection of software engineering work tasks, milestones, A task set is a collection of software engineering work tasks, milestones,
and work products that must be accomplished to complete a particular and work products that must be accomplished to complete a particular projectproject Size of project Size of project Number of potential users Number of potential users Mission criticality Mission criticality Application longevity Application longevity Requirement stability Requirement stability Ease of customer/developer communication Ease of customer/developer communication Maturity of applicable technology Maturity of applicable technology Performance constraints Performance constraints Embedded/non-embedded characteristics Embedded/non-embedded characteristics Project staffing Project staffing Reengineering factorsReengineering factors
SWE311_Ch24 (071) Software & Software Engineering Slide 13
Defining Task SetsDefining Task Sets
ActivityActivity Major work unitMajor work unit Start date Start date End dateEnd date Consumes resourcesConsumes resources Results in work products Results in work products
(and milestones)(and milestones)
Project
Phase 1
Phase 2
Phase N
Step 1
Step 2
Step 1
Step 2
Step 1
Step 2
Activity 1Activity 2Activity 3
Activity 1Activity 2 Task 1
Task 2Task 3
SWE311_Ch24 (071) Software & Software Engineering Slide 14
SchedulingScheduling Task networks (activity networks) are graphic representations that can be Task networks (activity networks) are graphic representations that can be
of the task interdependencies and can help define a rough schedule for of the task interdependencies and can help define a rough schedule for particular project particular project
Scheduling tools should be used to schedule any non-trivial project. Scheduling tools should be used to schedule any non-trivial project.
PERT (program evaluation and review technique) and CPM (critical path PERT (program evaluation and review technique) and CPM (critical path method) are quantitative techniques that allow software planners to method) are quantitative techniques that allow software planners to identify the chain of dependent tasks in the project work breakdown identify the chain of dependent tasks in the project work breakdown structure that determine the project duration time. structure that determine the project duration time.
Timeline (Gantt) charts enable software planners to determine what tasks Timeline (Gantt) charts enable software planners to determine what tasks will need to be conducted at a given point in time (based on estimates for will need to be conducted at a given point in time (based on estimates for effort, start time, and duration for each task). effort, start time, and duration for each task).
The best indicator of progress is the completion and successful review of a The best indicator of progress is the completion and successful review of a defined software work product. defined software work product.
SWE311_Ch24 (071) Software & Software Engineering Slide 15
Task durations and dependenciesTask durations and dependencies
Activity Duration (days) Dependencies
T1 8
T2 15
T3 15 T1 (M1)
T4 10
T5 10 T2, T4 (M2)
T6 5 T1, T2 (M3)
T7 20 T1 (M1)
T8 25 T4 (M5)
T9 15 T3, T6 (M4)
T10 15 T5, T7 (M7)
T11 7 T9 (M6)
T12 10 T11 (M8)
SWE311_Ch24 (071) Software & Software Engineering Slide 16
Activity networkActivity network
start
T2
M3T6
Finish
T10
M7T5
T7
M2T4
M5
T8
4/7/03
8 days
14/7/03 15 days
4/8/03
15 days
25/8/03
7 days
5/9/03
10 days
19/9/03
15 days
11/8/03
25 days
10 days
20 days
5 days25/7/03
15 days
25/7/03
18/7/03
10 days
T1
M1 T3T9
M6
T11
M8
T12
M4
SWE311_Ch24 (071) Software & Software Engineering Slide 17
Activity timelineActivity timeline4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9
T4
T1T2
M1
T7T3
M5
T8
M3
M2
T6
T5
M4
T9
M7
T10
M6
T11M8
T12
Start
Finish
SWE311_Ch24 (071) Software & Software Engineering Slide 18
Staff allocationStaff allocation4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9
T4
T8 T11
T12
T1
T3
T9
T2
T6 T10
T7
T5
Fred
Jane
Anne
Mary
Jim
SWE311_Ch24 (071) Software & Software Engineering Slide 19
Use Automated Use Automated Tools toTools to
Derive a Timeline Derive a Timeline ChartChart
I.1.1 Identify need and benefits Meet with customers Identify needs and project constraints Establish product statement Milestone: product statement definedI.1.2 Define desired output/control/input (OCI) Scope keyboard functions Scope voice input functions Scope modes of interaction Scope document diagnostics Scope other WP functions Document OCI FTR: Review OCI with customer Revise OCI as required; Milestone; OCI definedI.1.3 Define the functionality/behavior Define keyboard functions Define voice input functions Decribe modes of interaction Decribe spell/grammar check Decribe other WP functions FTR: Review OCI definition with customer Revise as required Milestone: OCI defintition completeI.1.4 Isolate software elements Milestone: Software elements definedI.1.5 Research availability of existing software Reseach text editiong components Research voice input components Research file management components Research Spell/Grammar check components Milestone: Reusable components identifiedI.1.6 Define technical feasibility Evaluate voice input Evaluate grammar checking Milestone: Technical feasibility assessedI.1.7 Make quick estimate of sizeI.1.8 Create a Scope Definition Review scope document with customer Revise document as required Milestone: Scope document complete
week 1 week 2 week 3 week 4Work tasks week 5
SWE311_Ch24 (071) Software & Software Engineering Slide 20
Schedule TrackingSchedule Tracking conduct periodic project status meetings in which each team member conduct periodic project status meetings in which each team member
reports progress and problems.reports progress and problems. evaluate the results of all reviews conducted throughout the software evaluate the results of all reviews conducted throughout the software
engineering process.engineering process. determine whether formal project milestones (the diamonds shown in determine whether formal project milestones (the diamonds shown in
Figure 24.3) have been accomplished by the scheduled date.Figure 24.3) have been accomplished by the scheduled date. compare actual start-date to planned start-date for each project task compare actual start-date to planned start-date for each project task
listed in the resource table (Figure 24.4).listed in the resource table (Figure 24.4). meet informally with practitioners to obtain their subjective assessment meet informally with practitioners to obtain their subjective assessment
of progress to date and problems on the horizon.of progress to date and problems on the horizon. use earned value analysis (Section 24.6) to assess progress
quantitatively.
SWE311_Ch24 (071) Software & Software Engineering Slide 21
Progress on an OO Project-IProgress on an OO Project-I Technical milestone: OO analysis completed Technical milestone: OO analysis completed
All classes and the class hierarchy have been defined and reviewed.All classes and the class hierarchy have been defined and reviewed. Class attributes and operations associated with a class have been defined and Class attributes and operations associated with a class have been defined and
reviewed.reviewed. Class relationships (Chapter 8) have been established and reviewed.Class relationships (Chapter 8) have been established and reviewed. A behavioral model (Chapter 8) has been created and reviewed.A behavioral model (Chapter 8) has been created and reviewed. Reusable classes have been noted.Reusable classes have been noted.
Technical milestone: OO design completedTechnical milestone: OO design completed The set of subsystems (Chapter 9) has been defined and reviewed.The set of subsystems (Chapter 9) has been defined and reviewed. Classes are allocated to subsystems and reviewed.Classes are allocated to subsystems and reviewed. Task allocation has been established and reviewed.Task allocation has been established and reviewed. Responsibilities and collaborations (Chapter 9) have been identified.Responsibilities and collaborations (Chapter 9) have been identified. Attributes and operations have been designed and reviewed.Attributes and operations have been designed and reviewed. The communication model has been created and reviewed.The communication model has been created and reviewed.
SWE311_Ch24 (071) Software & Software Engineering Slide 22
Progress on an OO Project-IIProgress on an OO Project-II Technical milestone: OO programming completedTechnical milestone: OO programming completed
Each new class has been implemented in code from the design model.Each new class has been implemented in code from the design model. Extracted classes (from a reuse library) have been implemented.Extracted classes (from a reuse library) have been implemented. Prototype or increment has been built.Prototype or increment has been built.
Technical milestone: OO testingTechnical milestone: OO testing The correctness and completeness of OO analysis and design models has been The correctness and completeness of OO analysis and design models has been
reviewed.reviewed. A class-responsibility-collaboration network (Chapter 8) has been developed and A class-responsibility-collaboration network (Chapter 8) has been developed and
reviewed.reviewed. Test cases are designed and class-level tests (Chapter 14) have been conducted for Test cases are designed and class-level tests (Chapter 14) have been conducted for
each class.each class. Test cases are designed and cluster testing (Chapter 14) is completed and the classes Test cases are designed and cluster testing (Chapter 14) is completed and the classes
are integrated.are integrated. System level tests have been completed.System level tests have been completed.
SWE311_Ch24 (071) Software & Software Engineering Slide 23
Earned Value Analysis
“Earned Value Analysis” is: a quantitative measure given to each task as a percent of project
completed so far an industry standard way to:
measure a project’s progress forecast its completion date and final cost, and provide schedule and budget variances along the way
rather than rely on a gut feeling
By integrating three measurements, it provides consistent, numerical indicators with which you can evaluate and compare projects.
SWE311_Ch24 (071) Software & Software Engineering Slide 24
What’s more Important?What’s more Important? Knowing where you are on schedule?Knowing where you are on schedule?
Knowing where you are on budget?Knowing where you are on budget?
Knowing where you are on work Knowing where you are on work accomplished?accomplished?
SWE311_Ch24 (071) Software & Software Engineering Slide 25
EVA Integrates All ThreeEVA Integrates All Three
It compares the PLANNED amount of work with It compares the PLANNED amount of work with what has actually been COMPLETED, to determine what has actually been COMPLETED, to determine if if COSTCOST , , SCHEDULESCHEDULE, and, and WORKWORK ACCOMPLISHEDACCOMPLISHED are progressing as planned. are progressing as planned.
Work is “Earned” or credited as it is completedWork is “Earned” or credited as it is completed ..
SWE311_Ch24 (071) Software & Software Engineering Slide 26
Earned Value needed because...Earned Value needed because...
Have an accurate estimate of project statusHave an accurate estimate of project status Provides an “Early Warning” signal for prompt corrective Provides an “Early Warning” signal for prompt corrective
action.action.
Bad news does not age well.Bad news does not age well.
Still time to recoverStill time to recover
Timely request for additional fundsTimely request for additional funds
SWE311_Ch24 (071) Software & Software Engineering Slide 27
Basic Earned ValueEarned Value Measures
BCWS - Budgeted Cost of Work Scheduled Planned cost of the total amount of work scheduled to be performed by
the milestone date
ACWP - Actual Cost of Work Performed Cost incurred to accomplish the work that has been done to date
BCWP - Budgeted Cost of Work Performed The planned (not actual) cost to complete the work that has been done
BAC -BAC - Budget At CompletionBudget At Completion
SWE311_Ch24 (071) Software & Software Engineering Slide 28
Derived Earned ValueEarned Value Measures continued
SPI: Schedule Performance IndexSPI: Schedule Performance Index SPI = BCWP/BCWSSPI = BCWP/BCWS SPI < 1 SPI < 1 project is behind schedule project is behind schedule The closer SPI to 1 indicates more efficient execution of projectThe closer SPI to 1 indicates more efficient execution of project
CPI: Cost Performance IndexCPI: Cost Performance Index CPI = BCWP/ACWPCPI = BCWP/ACWP CPI < 1 CPI < 1 project is over budget project is over budget
CSI: Cost Schedule Index CSI: Cost Schedule Index CSI = CPI x SPICSI = CPI x SPI The further CSI is from 1.0, the less likely project recovery becomes.The further CSI is from 1.0, the less likely project recovery becomes.
SWE311_Ch24 (071) Software & Software Engineering Slide 29
Derived Earned ValueEarned Value Measures
SV: Schedule Variance (BCWP-BCWS)SV: Schedule Variance (BCWP-BCWS) A comparison of amount of work performed during a given A comparison of amount of work performed during a given
period of time to what was scheduled to be performed.period of time to what was scheduled to be performed. A negative variance means the project is behind scheduleA negative variance means the project is behind schedule
CV: Cost Variance (BCWP-ACWP)CV: Cost Variance (BCWP-ACWP) A comparison of the budgeted cost of work performed with A comparison of the budgeted cost of work performed with
actual cost.actual cost. A negative variance means the project is over budget.A negative variance means the project is over budget.
SWE311_Ch24 (071) Software & Software Engineering Slide 30
Derived Earned ValueEarned Value Measures continued
Percent scheduled for completion = BCWS/BACPercent scheduled for completion = BCWS/BAC
provides an indication of the percentage of work that provides an indication of the percentage of work that should have been completed by time should have been completed by time t.t.
Percent complete = BCWP/BACPercent complete = BCWP/BAC
provides a quantitative indication of the percent of provides a quantitative indication of the percent of completeness of the project at a given point in time, completeness of the project at a given point in time, t.t.
Top Related