1. Chapter 24 Project Scheduling and Tracking
Software Engineering: A Practitioner’s Approach, 6th edition
by Roger S. Pressman

2. Why Are Projects Late?

3. Projects Are Late Because
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

4. Your Response per Napoleon
“Any commander in chief [software engineering manager] who undertakes to carry out a plan which he considers defective is at fault; he must put forth his reasons, insist on the plan being changed, and finally tender his resignation rather than be the instrument of his army’s [project team’s] downfall.”

5. How to Change an Unrealistic Deadline?
imposed deadline is unrealistic by showing data

6. Change an Unrealistic Deadline
The project needs to complete one year and if the customer imposes wrong deadline like to complete it in 9 months then:
Showing the history of previous projects.
Using an incremental process model, develop a strategy to deliver critical functionality by the deadline – document the plan.
Suggesting him to increase the budget to allocate more resources to complete the project within 9 months.
imposed deadline is unrealistic by showing data

7. Scheduling Principles
compartmentalization—define distinct tasks
interdependency—indicate task interrelationship
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

8. Relationship between People and Effort
There is misconception among most of the project managers that if the project is late from its delivery dates then by increasing more people in the development team can complete the project on time.
It does not work in the SW development environment because increasing more people will delay the project even further. The main reasons are as follows.
New people need time to synchronize with the existing team.
New people need training to work on the project.
There will be no or little work on the project because trainers are the team members working on the current project.
It is a fact in the SW development environment that project schedules are flexible i.e., can be reduced or extended.
Putting extra effort and resources can reduce schedules. Reducing the effort and resources can extend schedules.

9. What is Putnam Norden Raleigh (PNR) Curve?

10. Putnam Norden Raleigh (PNR) Curve
PNR curve is used to establish a relation between effort and delivery dates of the project by representing effort as a function of delivery time.
The main benefit of this method is that it is possible to complete the same project by extending the project schedule with less number of people.
The line of code (LOC) is related to effort and development time.

11. Putnam Norden Raleigh (PNR) Curve
Effort
Time

12. Empirical Relationship: P vs. E
L = P * E ^ 1/3 * T^4/3 Or
E = L3 / (P3t4)
L = LOC
P = Productivity parameter (2000 < P <12000)
E = Effort in person month (PM)
T = Project duration in months or years

13. Example 1 Software ‘X’ having 33000 LOC, estimated effort is 12
persons year; productivity is12,000 and number of
people required for the project is 8. Calculate the time
required for the project. Calculate the relation between
effort and people if we delay the project for six months.
Formula L = P * E ^ 1/3 * T^4/3

14. Solution of Example 1 E = L^3/P^3 * T^4
= 1.15 years
T = ½ = 1.65
E = LOC ^ 3/ P^3 * T ^ 4
E = (33000)^3/(12000)^3 * (1.65)^4 = 3 persons year
Initial effort was 12 and current effort is 3 i.e., 4 times reduced

15. Example 2 Software ‘Y’ having 45000 LOC, estimated effort is 12
persons year; productivity is 4000 and number of
people required for the project is 8. Calculate the time
required for the project. Calculate the relation between
effort and people if we have to deliver the project in 24
plus or minus 12 months.

16. Effort Distribution
Traditional rule for effort distribution is
40% of the total project effort should spend on analysis and design.
20% percent of the effort spends on coding.
40% of the effort spends on testing, maintenance, installation, training and security.
Effort distribution rule is a guideline because characteristics of each project are different.
These are the characteristics of the project that are used to set the distribution of effort.

17. Effort Distribution
These are the general guidelines to set the distribution of effort
2-3% on planning.
10-25% on analysis.
20-25% on design.
15-20% on coding.
30-40% on the remaining activities.

18. Another Approach to Allocate Effort
40-50%
“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
15-20%
30-40%

19. Effort Allocation
The rule does not apply on safety critical projects and agile projects.
Agile methodologies enforce the developers to spend little effort on analysis and design and more effort on development and maintenance to complete the project within 2-3 months.

20. Defining Task Sets determine type of project:
new application development;
application enhancement;
application maintenance;
reengineering projects.

21. Defining Task Sets
These are the main factors that affect the task sets.
Size of the project.
Number of users.
Complexity (AI based projects)
Stability of the requirements.
Ease of communication between development team and the customer.
Performance constraints.
Project team members.
Reengineering factors.

22. Task Set Refinement
1.1 Concept scoping determines the overall scope of the project.
Task definition: Task 1.1 Concept Scoping
1.1.1 Identify need, benefits and potential customers;
1.1.2 Define desired output/control and input events that drive the application;
Begin Task 1.1.2
FTR: Review written description of need
FTR indicates that a formal technical review (Chapter 26) is to be conducted.
Derive a list of customer visible outputs/inputs
FTR: Review outputs/inputs with customer and revise as required;
endtask Task 1.1.2
1.1.3 Define the functionality/behavior for each major function;
Begin Task 1.1.3
FTR: Review output and input data objects derived in task 1.1.2;
Derive a model of functions/behaviors;
FTR: Review functions/behaviors with customer and revise as required;
endtask Task 1.1.3
1.1.4 Isolate those elements of the technology to be implemented in software;
1.1.5 Research availability of existing software;
1.1.6 Define technical feasibility;
1.1.7 Make quick estimate of size;
1.1.8 Create a Scope Definition;
endTask definition: Task 1.1
is refined to

23. Define a Task Network

24. Timeline Charts Tasks Week 1 Week 2 Week 3 Week 4 Week n Task 1 Task 2

25. Use Automated Tools to Derive a Timeline Chart

26. 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 (diamonds in previous slide) have been accomplished by the scheduled date.
compare actual start-date to planned start-date for each project task listed in the resource table
meet informally with practitioners to obtain their subjective assessment of progress to date and problems on the horizon.
use critical path modeling and earned value analysis to assess progress quantitatively.

27. What is FTR?

28. FTR Meeting
FTR meeting is a review session in which the review leader presents the contents of agenda to be reviewed.
One member of review session acts the role of recorder.
The review members highlight the issues on the basis of their homework due to distribution of document and agenda well in advance.
There are three main functioning of FTR meeting participants to accept, reject or recommend modifications in the product to be reviewed.

29. Objectives of FTR Meeting
The objectives of the formal technical review are as follows to:
uncover errors in function, logic, or implementation for any representation of the software;
verify that the software under review meets its requirements;
ensure that the software has been represented according to predefined standards;
achieve software that is developed in a uniform manner;
make projects more manageable.

30. Critical Path Modeling
CPM is used to estimate the slack time.
Maximum amount of time that an activity can be delayed without delaying the entire project is called as slack time.
A network diagram is used to model the CPM.
Each node represents a task.
A table is drawn having three columns: activity number, minimum time and time reduction cost per day.

31. Critical Path Modeling Example 1
There are four activities.
The duration required to complete the activity number 1 is 5 days if we follow ‘Path A’ and 7 days if we follow ‘Path B’.
The duration required to complete the:
activity number 2-4 is 5 days;
activity number 3-4 is 4 days.
The fixed project cost is $100 per day. What is the lowest-cost time schedule?

32. Critical Path Modeling Example 1
The fixed project cost is $100 per day. What is the lowest-cost time schedule?

33. Critical Path Modeling Example 1
Critical path is determined first.

34. Critical Path Modeling Example 1
ii. Select an activity that can reduce the critical path ‘B’. The activity # 1-3 can be reduced for maximum two days at the cost of $55 for the first day.

35. Critical Path Modeling Example 1
iii. Reduce an activity from each path because both are critical.

36. Critical Path Modeling Example 1
iv. Reduce an activity again from each path because both are critical again.

37. Critical Path Modeling Example 2
A network diagram for a sample project is as follows. There are four activities. The duration required to complete the activity number 1 is 5 days if we follow ‘Path A’ and 4 days if we follow ‘Path B’. The duration required to complete the:
activity number 2 is 4 days;
activity number 3 is 6 days.

38. Critical Path Modeling Example 2

39. Critical Path Modeling Example 2
Critical path is determined first.

40. Critical Path Modeling Example 2

41. Earned Value Analysis (EVA)
is a measure of progress
enables us to assess the “percent of completeness” of a project using quantitative analysis rather than rely on a gut feeling
“provides accurate and reliable readings of performance from as early as 15 percent into the project.” [FLE98]

42. Computing Earned Value-I
The budgeted cost of work scheduled (BCWS) is determined for each work task represented in the schedule.
BCWSi is the effort planned for work task i.
To determine progress at a given point along the project schedule, the value of BCWS is the sum of the BCWSi values for all work tasks that should have been completed by that point in time on the project schedule.
The BCWS values for all work tasks are summed to derive the budget at completion, BAC. Hence,
BAC = ∑ (BCWSk) for all tasks k

43. Computing Earned Value-II
Next, the value for budgeted cost of work performed (BCWP) is computed.
The value for BCWP is the sum of the BCWS values for all work tasks that have actually been completed by a point in time on the project schedule.
“the distinction between the BCWS and the BCWP is that the former represents the budget of the activities that were planned to be completed and the latter represents the budget of the activities that actually were completed.” [WIL99]
Given values for BCWS, BAC, and BCWP, important progress indicators can be computed:
Schedule performance index, SPI = BCWP/BCWS
Schedule variance, SV = BCWP – BCWS
SPI is an indication of the efficiency with which the project is utilizing scheduled resources.

44. Computing Earned Value-III
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.
Actual cost of work performed, ACWP, is the sum of the effort actually expended on work tasks that have been completed by a point in time on the project schedule. It is then possible to compute
Cost performance index, CPI = BCWP/ACWP
Cost variance, CV = BCWP – ACWP

45. Computing Earned Value-III
Estimate Cost at Completion = Total Budget at Completion/Cost Performance Indicator
= BAC/CPI
Cost Variance at completion (CVAC) = BAC – Estimate at Completion (EAC)
Estimated Schedule at Completion = Total Schedule /Schedule Performance Indicator
= Total Schedule/SPI
Schedule Variance at completion (SVAC) = Total schedule – Estimate Schedule

46. Computing Earned Value-III
CV = BCWP – ACWP
CPI = BCWP/ACWP
SV = BCWP – BCWS
SPI = BCWP/BCWS
ECAC = BAC/CPI
CVAC = BAC – ECAC
ESAC = Total Schedule/SPI
SVAC = Total Schedule – ESAC

47. Problem1
A pipeline is to be constructed from New York to Washington DC for a distance of 280 kms within duration of 15 months at a cost of $2.8 billion. Engineering department estimates that pipeline should be constructed at a construction rate of .62 km per day. Budgeted cost per pipeline km is $ 10 million. Perform the EVA analysis after 45 days. Engineering department estimated that 24 Km pipeline has constructed. Account department found that $300 million has spent after 45 days.
Budgeted Cost of Work Performed (BCWP) = 24 * $10 million = $ 240 million
Actual Cost Of Work Performed (ACWP) = $ 300 million
Budgeted Cost of Work Scheduled (BCWS) = 45* 0.62 * 10 = $ 279 million
CV = BCWP – ACWP = 240 – 300 = - $60 million (over budget)
CPI = BCWP/ACWP = 240/300 = 0.8
SV = BCWP – BCWS = 240 – 279 = - $39 million
SPI = BCWP/BCWS = 240/279 = 0.86
ECAC = BAC/CPI = 2.8/0.8 = $3.5 billion
CVAC = BAC – ECAC = 2.8 – 3.5 = - $700 million extra money has to spend
ESAC = Total Schedule/SPI = 450/0.86 = 523 days
SVAC = Total Schedule – ESAC = 450 – 523 = -73 days extra required to complete the project.

48. Example 2
The project is to develop software that has 11 modules over a period of 11 months at the cost of $ The BCWS is $100/month. This EVA analysis was calculated after 4 months. The budgeted cost of work scheduled (BCWS) was to spend $ 100 per month. But at the end of April 30 budgeted cost of work performed was spent $ 450 and it is more than the BCWS. Actual cost of work performed was $ 500.

49. Problem 2: Solution
Total project duration= 11 months= 11 * 30= 330 days
BAC = $ 2,000
BCWP after 4 months = $ 450
ACWP after 4 months = $ 5,00
BCWS after 4 months = $ 400
CV = BCWP- ACWP = 450 – 500 = - 50
SV = BCWP – BCWS = = 50
CPI = BCWP/ACWP = 450/500 = 0.9
SPI = BCWP/BCWS = 450/400 = 1.125
ECAC = BAC/CPI = 2000/0.9 = $
CVAC = BAC – ECAC
= = $ extra has to spend to complete the project
ESAC = Total Project Duration/SPI = 330/1.125 = Days
SVAC = = 36 days= 1.2 months before than the planned Schedule.