1. Lecture 7 Project Scheduling and Tracking
Software Engineering
Lecture 7
Project Scheduling and Tracking

2. Why software is delivered late
Unrealistic deadline
Changing Customer Requirements
Underestimate of the amount of effort
Predictable / Unpredictable risks
Technical Difficulties
Human Difficulties
Miscommunication among project staff
Lack of action to overcome the lateness

3. Comments on “Lateness”
It is unrealistic to march into the customer’s office and demand that the delivery date be changed, because:
External market pressures have dictated the date, and the product must be released
Developers cannot refuse to undertake the work (from a career standpoint)

4. Recommended solutions
Perform a detailed estimate using historical data from past projects
Using an incremental process model (deliver critical functionality, delay others)
Meet with the customer and explain why the imposed deadline is unrealistic (using the detailed estimate)

5. Project Scheduling Basic Principles
Project Manager’s Objectives:
Define all project tasks
Build a network of task interdependencies
Identify tasks that lie on the critical path
Software Project Scheduling is an activity that distributes estimated effort across the planned project duration by allocating the effort to specific software engineering tasks.
The schedule evolves over time.

6. Macroscopic vs Detailed Schedule
Macroscopic schedule: identifies all major software engineering activities and the product functions to which they are applied
As the project gets under way, each entry on the macroscopic schedule is refined into a detailed schedule.
Detailed schedule: specific software tasks (required to acomplish an activity) are identified and scheduled

7. Software Project Scheduling Guidelines
Compartmentalization (decompose activities and tasks)
Interdependency (of activities / tasks)
Time Allocation (for each task)
Effort Validation (e.g. 3 person-day for a task)
Defined Responsibilities (task - team member assignment)
Defined Outcomes (e.g. work product)
Defined Milestones (a group of approved work products)

8. Defining a task set for the software project
A task set is a collection of software engineering work tasks, milestones, and deliverables that must be accomplished to complete a particular project
Task sets are designed to accommodate different types of projects and different degrees of rigor

9. Taxonomy of software project types
Concept development projects (explore new business concepts / new technology)
New application development projects
Application enhancement projects (major modifications to functions, performance, or interfaces)
Application maintenance projects (correct, adapt, or extend existing software)
Reengineering projects (rebuild an existing system)

10. Degree of rigor (1)
The degree of rigor is a function of many project characteristics.
Casual
All process framework activities are applied
A minimum task set is required
Umbrella tasks are minimized
Documentation requirements are reduced.
Structured
SQA, SCM, documentation, and measurement tasks will be conducted in a streamlined manner

11. Degree of rigor (2) Strict Quick Reaction
The full process will be applied with a degree of discipline to ensure high quality
All umbrella activities will be applied
Robust work products will be produced
Quick Reaction
The process framework will be applied, but only those tasks essential to maintaining good quality will be applied
Back-filing (documentation, reviews) will be accomplished after the product is delivered

12. Adaptation Criteria
Adaptation criteria are used to determine the recommended degree of rigor with which the software process should be applied on a project.
Evelen adaptation criteria are defined for a software project.
Each of the adaptation criteria is assigned a grade that ranges between 1 and 5.
1 represents a small set of process tasks are required (minimal requirements)
5 represents a complete set of process tasks should be applied (overall methodological and documentation)

13. Eleven adaptation criteria
Size of the project
Number of potential users
Mission criticality
Application longevity
Stability of requirements
Ease of customer/developer communication
Maturity of applicable technology
Performance constrains
Embedded and nonembedded characteristics
Project staff
Reengineering factors

14. Computing The Task Set Selector
Step 2
Grade 1 to 5
Adaptation
Criteria
Grade
Weight
Entry Point Multiplier
Product
Conc
Ndev
Enhan
Maint
Reeng
Size of project
1.20 1
Number of users
1.10
Business criticality
Longevity
0.90
Stability of requirements
Ease of communication
Maturity of technology
Performance constraints
0.80
Embedded/nonembedded
Step 1
Choose the project type
Step 4
Grade x weight x entry point multiplier
Step 3
Weight 0.8 – 1.2
Step 5
TSS = Average(Products)

15. Interpreting the TSS value
Task Set Selector Value
Degree of rigor
TSS < 1.2
Casual
1.0 < TSS < 3.0
Structured
TSS > 2.4
Strict

16. Project Scheduling Methods (1)
PERT (Program Evaluation and Review Technique) and CPM (Critical Path Method) are two project scheduling methods that can be applied to software development.
Interdependencies among tasks may be defined using a task network (activity network), a graphic representation of the task flow for a project.

17. Project Scheduling Methods (2)
Both PERT and CPM provide quantitative tools that allow the software planner to:
Determine the critical path
Establish “most likely” time estimates for individual tasks
Calculate “boundary times” that define a time “window” for a particular task

18. Timeline Charts
A timeline chart, also called a Gantt chart depicts the software project schedule for the entire project.
Alternatively, separate charts can be developed for each project function or for each individual working on the project.

19. Tracking the Schedule Conducting periodic project status meeting
Evaluating the results of all conducted reviews
Determining whether milestones have been accomplished by the scheduled date
Comparing actual start-date to planned start-date for each project task
Meeting informally with practitioners to obtain their subjective assessment of progress to date
Using Earned Value Analysis to assess progress quantitatively

20. Earned Value Analysis (1)
The earned value analysis (Humphrey, 1995) provides a common value scale for every software project task, regardless of the type of work being performed. The total hours to do the whole project are estimated, and every task is given an earned value based on its estimated percentage of the total.
Earned value is simply a measure of progress.

21. Earned Value Analysis (2)
BCWS (Budgeted cost of work scheduled) 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). BAC = å (BCWSk) for all tasks k
BCWP (Budgeted cost of work performed) 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.

22. Earned Value Analysis (3)
Given values for BCWS, BAC, and BCWP, important progress indicators can be computed:
Schedule Performance Index, an indication of the efficiency with which the project is utilizing scheduled resources. SPI = BCWP / BCWS
Schedule Variance, an absolute indication of variance from the planned schedule. SV = BCWP – BCWS
Percent scheduled for completion = BCWS / BAC
Percent complete = BCWP / BAC

23. Earned Value Analysis (4)
ACWP (Actual cost of work performed) is the sum of the effort actually expended on work tasks that have been completed by a point in time on the project schedule.
Cost performance index, CPI = BCWP / ACWP
Cost variance, CV = BCWP – ACWP

24. Summary
Scheduling is the culmination of a planning activity that is a primary component of software project management. When combined with estimation methods and risk analysis, scheduling establishes a road map for the project manager.

25. References
Pressman, Chapter 7