1. Chapter 24 Project Scheduling and Tracking
SWE311_Ch24 (071) Software & Software Engineering

2. Why Are Projects Late?
an unrealistic deadline established by someone outside the software development group
changing customer requirements that are not reflected in schedule changes;
an honest underestimate of the amount of effort and/or the number of resources that will be required to do the job;
predictable and/or unpredictable risks that were not considered when the project commenced;
technical 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;
a failure by project management to recognize that the project is falling behind schedule and a lack of action to correct the problem
SWE311_Ch24 (071) Software & Software Engineering

3. How to Deal With Unrealistic Schedule Demands
Perform a detailed project estimate for project effort and duration using historical data.
Use an incremental process model that will deliver critical functionality imposed by deadline, but delay other requested functionality.
Meet with the customer and explain why the deadline is unrealistic using your estimates based on prior team performance.
Offer an incremental development and delivery strategy as an alternative to increasing resources or allowing the schedule to slip beyond the deadline.
SWE311_Ch24 (071) Software & Software Engineering

4. Project Scheduling Perspectives
One view is that the end-date for the software release is set externally and that the software organization is constrained to distribute effort in the prescribed time frame.
Another view is that the rough chronological bounds have been discussed by the developers and customers, but the end-date is best set by the developer after carefully considering how to best use the resources needed to meet the customer's needs.
SWE311_Ch24 (071) Software & Software Engineering

5. Scheduling Principles
compartmentalization— the product and process must be decomposed into a manageable number of activities and tasks
interdependency—indicate task interrelationship
Time allocation - every task has start and completion dates that take the task interdependencies into account
effort validation—be sure resources are available
defined responsibilities— every scheduled task needs to be assigned to a specific team member
defined outcomes—each task must have an output
defined milestones— a milestone is accomplished when one or more work products from an engineering task have passed quality review
SWE311_Ch24 (071) Software & Software Engineering

6. Relationship Between People and Effort
Common myth:
Adding people to a project after it is behind schedule often causes the schedule to slip further
The relationship between the number of people on a project 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 work in cooperation with one another)
The main reasons for using more than 1 person on a project are to get the job done more rapidly and to improve software quality.
SWE311_Ch24 (071) Software & Software Engineering

7. Effort and Delivery Time
SWE311_Ch24 (071) Software & Software Engineering

8. The project scheduling process
Estimate resources
for activities
Identify activity
dependencies
Identify
activities
Allocate people
to activities
Software
requirements
Create project
char ts
Activity, bar, Gantt Charts
SWE311_Ch24 (071) Software & Software Engineering

9. Effort Allocation “front end” activities 40-50%
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%
SWE311_Ch24 (071) Software & Software Engineering

10. Project Effort Distribution
The rule (a rule of thumb):
40% front-end analysis and design
20% coding
40% back-end testing
Generally accepted guidelines are:
02-03 % planning
10-25 % requirements analysis
20-25 % design
15-20 % coding
SWE311_Ch24 (071) Software & Software Engineering

11. Software Project Types
Concept development - initiated to explore new business concept or new application of technology
New application development - new product requested by customer
Application enhancement - major modifications to function, performance, or interfaces (observable to user)
Application maintenance - correcting, adapting, or extending existing software (not immediately obvious to user)
Reengineering - rebuilding all (or part) of a legacy system
SWE311_Ch24 (071) Software & Software Engineering

12. Factors Affecting Task Set
A task set is a collection of software engineering work tasks, milestones, and work products that must be accomplished to complete a particular project
Size of project
Number of potential users
Mission criticality
Application longevity
Requirement stability
Ease of customer/developer communication
Maturity of applicable technology
Performance constraints
Embedded/non-embedded characteristics
Project staffing
Reengineering factors
SWE311_Ch24 (071) Software & Software Engineering

13. Defining Task Sets Activity Major work unit Start date End date
Consumes resources
Results in work products (and milestones)
Step 1
Step 2
Activity 1
Activity 2
Activity 3
Phase 1
Step 1
Step 2
Activity 1
Activity 2
Task 1
Task 2
Task 3
Project
Phase 2
Step 1
Step 2
Phase N
SWE311_Ch24 (071) Software & Software Engineering

14. Scheduling
Task networks (activity networks) are graphic representations that can be of the task interdependencies and can help define a rough schedule for particular project
Scheduling tools should be used to schedule any non-trivial project.
PERT (program evaluation and review technique) and CPM (critical path method) are quantitative techniques that allow software planners to identify the chain of dependent tasks in the project work breakdown structure that determine the project duration time.
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 effort, start time, and duration for each task).
The best indicator of progress is the completion and successful review of a defined software work product.
SWE311_Ch24 (071) Software & Software Engineering

15. Task durations and dependencies
SWE311_Ch24 (071) Software & Software Engineering

16. Activity network
SWE311_Ch24 (071) Software & Software Engineering

17. Activity timeline
SWE311_Ch24 (071) Software & Software Engineering

18. Staff allocation
SWE311_Ch24 (071) Software & Software Engineering

19. Use Automated Tools to Derive a Timeline Chart
SWE311_Ch24 (071) Software & Software Engineering

20. Schedule Tracking
conduct periodic project status meetings in which each team member reports progress and problems.
evaluate the results of all reviews conducted throughout the software engineering process.
determine whether formal project milestones (the diamonds shown in Figure 24.3) have been accomplished by the scheduled date.
compare actual start-date to planned start-date for each project task listed in the resource table (Figure 24.4).
meet informally with practitioners to obtain their subjective assessment 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

21. Progress on an OO Project-I
Technical milestone: OO analysis completed
All classes and the class hierarchy have been defined and reviewed.
Class attributes and operations associated with a class have been defined and reviewed.
Class relationships (Chapter 8) have been established and reviewed.
A behavioral model (Chapter 8) has been created and reviewed.
Reusable classes have been noted.
Technical milestone: OO design completed
The set of subsystems (Chapter 9) has been defined and reviewed.
Classes are allocated to subsystems and reviewed.
Task allocation has been established and reviewed.
Responsibilities and collaborations (Chapter 9) have been identified.
Attributes and operations have been designed and reviewed.
The communication model has been created and reviewed.
SWE311_Ch24 (071) Software & Software Engineering

22. Progress on an OO Project-II
Technical milestone: OO programming completed
Each new class has been implemented in code from the design model.
Extracted classes (from a reuse library) have been implemented.
Prototype or increment has been built.
Technical milestone: OO testing
The correctness and completeness of OO analysis and design models has been reviewed.
A class-responsibility-collaboration network (Chapter 8) has been developed and reviewed.
Test cases are designed and class-level tests (Chapter 14) have been conducted for each class.
Test cases are designed and cluster testing (Chapter 14) is completed and the classes are integrated.
System level tests have been completed.
SWE311_Ch24 (071) Software & Software Engineering

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

24. What’s more Important? Knowing where you are on schedule?
Knowing where you are on budget?
Knowing where you are on work accomplished?
SWE311_Ch24 (071) Software & Software Engineering

25. EVA Integrates All Three
It compares the PLANNED amount of work with what has actually been COMPLETED, to determine if COST , SCHEDULE, and WORK ACCOMPLISHED are progressing as planned.
Work is “Earned” or credited as it is completed.
SWE311_Ch24 (071) Software & Software Engineering

26. Earned Value needed because...
Have an accurate estimate of project status
Provides an “Early Warning” signal for prompt corrective action.
Bad news does not age well.
Still time to recover
Timely request for additional funds
SWE311_Ch24 (071) Software & Software Engineering

27. Basic Earned 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 - Budget At Completion
SWE311_Ch24 (071) Software & Software Engineering

28. Derived Earned Value Measures continued
SPI: Schedule Performance Index
SPI = BCWP/BCWS
SPI < 1  project is behind schedule
The closer SPI to 1 indicates more efficient execution of project
CPI: Cost Performance Index
CPI = BCWP/ACWP
CPI < 1  project is over budget
CSI: Cost Schedule Index
CSI = CPI x SPI
The further CSI is from 1.0, the less likely project recovery becomes.
SWE311_Ch24 (071) Software & Software Engineering

29. Derived Earned Value Measures
SV: Schedule Variance (BCWP-BCWS)
A comparison of amount of work performed during a given period of time to what was scheduled to be performed.
A negative variance means the project is behind schedule
CV: Cost Variance (BCWP-ACWP)
A comparison of the budgeted cost of work performed with actual cost.
A negative variance means the project is over budget.
SWE311_Ch24 (071) Software & Software Engineering

30. Derived Earned Value Measures continued
Percent scheduled for completion = BCWS/BAC
provides an indication of the percentage of work that should have been completed by time t.
Percent complete = BCWP/BAC
provides a quantitative indication of the percent of completeness of the project at a given point in time, t.
SWE311_Ch24 (071) Software & Software Engineering