1. Project Scheduling and Tracking
Developed by Reneta Barneva, SUNY Fredonia

2. Developed by Reneta Barneva, SUNY Fredonia
Why a project is late?
An unrealistic deadline established by someone outside the software development group and forced on managers and practitioner's within the 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.
Developed by Reneta Barneva, SUNY Fredonia

3. Developed by Reneta Barneva, SUNY Fredonia
Why a project is late?
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.
Developed by Reneta Barneva, SUNY Fredonia

4. Software Project Scheduling
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.
First a macroscopic schedule is developed. It includes all major software engineering activities.
Later it is refined to a detailed schedule. Here, specific software tasks are identified and scheduled.
Developed by Reneta Barneva, SUNY Fredonia

5. Principles of Software Project Scheduling
Compartmentalization. The project must be split into a number of manageable activities and tasks. To accomplish compartmentalization, both the product and the process are decomposed (Chapter 3).
Interdependency. The interdependency of each single activity or task must be determined. Some tasks must occur in sequence while others can occur in parallel. Some activities cannot commence until the work product produced by another is available. Other activities can occur independently.
Developed by Reneta Barneva, SUNY Fredonia

6. Software Project Scheduling
Time allocation. Each task to be scheduled must be allocated some number of work units (e.g., person- days of effort). In addition, each task must be assigned a start date and a completion date that are a function of the interdependencies and whether work will be conducted on a full-time or part-time basis.
Effort validation. Every project has a defined number of staff members. As time allocation occurs, the project manager must ensure that no more than the allocated number of people have been scheduled at any given time.
Developed by Reneta Barneva, SUNY Fredonia

7. Software Project Scheduling
Defined responsibilities. Every task that is scheduled should be assigned to a specific team member.
Defined outcomes. Every task that is scheduled should have a defined outcome. For software projects, the outcome is normally a work product (e.g., the design of a module) or a part of a work product.
Defined milestones. Every task or group of tasks should be associated with a project milestone. A milestone is accomplished when one or more work products has been reviewed for quality and has been approved.
Developed by Reneta Barneva, SUNY Fredonia

8. The Relation Between People and Effort
Example: 4 software engineers, each capable of producing LOC/year working on an individual project.
In a team: six potential communication paths are possible.
Assume we have to subtract 250 LOC/year for each communication path
Team productivity is 20,000 - (250 x 6) = 18,500 LOC/year—7.5 percent less
If two additional people are added to the team two months before the deadline. The number of communication paths becomes 14.
The productivity input of the new staff is the equivalent of 840 x 2 = LOC for the two months.
Team productivity now is 20, (250 x 14) = 18,180 LOC/year.
Developed by Reneta Barneva, SUNY Fredonia

9. The Relation Between People and Effort
There is a nonlinear relationship between chronological time to complete a project and human effort applied to the project.
Recalling the software equation introduced in Chapter 5.
The number of delivered lines of code L is related to effort and development time by the equation:
L = P x E 1/3 t 4/3
E is development effort in person-months,
P is a productivity parameter that reflects a variety of factors that lead to high-quality software engineering work (typical values for P range between 2,000 and 12,000),
t is the project duration in calendar months.
Developed by Reneta Barneva, SUNY Fredonia

10. The Relation Between People and Effort
Rearranging this software equation, we can arrive at an expression for development effort E:
E = L 3 / (P 3 t 4)
E is the effort (in person-years) for the entire life cycle of software development and maintenance
t is the development time in years.
Developed by Reneta Barneva, SUNY Fredonia

11. The Relation Between People and Effort
Example: Consider a complex, real-time software project estimated at 33,000 LOC, 12 person-years of effort. If 8 people are assigned to the project team, the project can be completed in approximately 1.3 years.
If, however, we extend the end-date to 1.75 years, according to the equation on the previous slide:
E = L3/( P3t4) ~ 3.8 person-years.
This implies that, by extending the end-date six months, we can reduce the number of people from eight to four!
We may use less people over a longer time span to accomplish the same objective.
Developed by Reneta Barneva, SUNY Fredonia

12. Distribution of Efforts
Software project estimation techniques lead to estimates of work units (e.g., person-months) required to complete software development.
A recommended distribution of effort across the definition and development phases is often referred to as the
40–20–40 rule
front-end analysis and design - coding - back-end testing
Developed by Reneta Barneva, SUNY Fredonia

13. 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.
The task set to be chosen must provide enough discipline to achieve high software quality. But, at the same time, it must not burden the project team with unnecessary work.
Developed by Reneta Barneva, SUNY Fredonia

14. Defining a Task Set for the Software Project
Task sets are designed to accommodate different types of projects and different degrees of rigor. Most software organizations encounter the following projects:
Concept development projects that are initiated to explore some new business concept or application of some new technology.
New application development projects that are undertaken as a consequence of a specific customer request.
Developed by Reneta Barneva, SUNY Fredonia

15. Defining a Task Set for the Software Project
Application enhancement projects that occur when existing software undergoes major modifications to function, performance, or interfaces that are observable by the end-user.
Application maintenance projects that correct, adapt, or extend existing software in ways that may not be immediately obvious to the end-user.
Reengineering projects that are undertaken with the intent of rebuilding an existing system in whole or in part.
Developed by Reneta Barneva, SUNY Fredonia

16. Defining a Task Set for the Software Project
Four different degrees of rigor can be defined:
Casual. All process framework activities are applied, but only a minimum task set is required. Umbrella tasks will be minimized and documentation requirements will be reduced.
Developed by Reneta Barneva, SUNY Fredonia

17. Defining a Task Set for the Software Project
Structured. The process framework will be applied for this project.
- Framework activities and related tasks appropriate to the project type will be applied
- Umbrella activities necessary to ensure high quality will be applied.
- Documentation will be provided, and
- Measurement tasks will be conducted.
Developed by Reneta Barneva, SUNY Fredonia

18. Defining a Task Set for the Software Project
Strict. The full process will be applied for this project with a degree of discipline that will ensure high quality. All umbrella activities will be applied and robust work products will be produced.
Quick reaction. The process framework will be applied for this project, but because of an emergency situation only those tasks essential to maintaining good quality will be applied. "Back- filling" (i.e., developing a complete set of documentation) will be accomplished after the application/product is delivered to the customer.
Developed by Reneta Barneva, SUNY Fredonia

19. Defining a Task Set for the Software Project
Adaptation criteria: used to determine the recommended degree of rigor.
The following adaptation criteria are defined for software projects:
Maturity of applicable technology
Performance constraints
Embedded and non- embedded characteristics
Project staff
Reengineering factors
Size of the project
Number of potential users
Mission criticality
Application longevity
Stability of requirements
Ease of customer/developer communication
Developed by Reneta Barneva, SUNY Fredonia

20. Defining a Task Set for the Software Project
Computing a Task Set Selector Value:
1. Assign appropriate grades (1 to 5) of each of the adaptation criteria based on the characteristics of the project.
2. Review the weighting factors assigned to each of the criteria. The value of a weighting factor ranges from 0.8 to and provides an indication of the relative importance of a particular adaptation criterion to the types of software developed within the local environment.
3. Multiply the grades by the weighting factors and by the entry point multiplier. The entry point multiplier takes on a value of 0 or 1 and indicates the relevance of the adaptation criterion to the project type.
Developed by Reneta Barneva, SUNY Fredonia

21. Defining a Task Set for the Software Project
Computing a Task Set Selector Value:
Compute the average of
grade x weighting factor x entry point multiplier
for all criteria
This value is called task set selector (TSS) and it is used to help select the task set that is most appropriate for the project.
Developed by Reneta Barneva, SUNY Fredonia

22. Defining a Task Set for the Software Project
Developed by Reneta Barneva, SUNY Fredonia

23. Defining a Task Set for the Software Project
How to use task set selector value?
Degree of rigor
TSS < 1.2 casual
1.0 < TSS < 3.0 structured
TSS > 2.4 strict
Developed by Reneta Barneva, SUNY Fredonia

24. Selecting Software Engineering Tasks
In order to develop a project schedule, a task set must be distributed on the project time line. Depends on the model.
Developed by Reneta Barneva, SUNY Fredonia

25. Selecting Software Engineering Tasks
In order to develop a project schedule, a task set must be distributed on the project time line. Depends on the model.
Developed by Reneta Barneva, SUNY Fredonia

26. Refinement of Major Tasks
After defining the major tasks, a detailed schedule of the project is created.
Refinement begins by taking each major task and decomposing it into a set of subtasks (with related work products and milestones).
Developed by Reneta Barneva, SUNY Fredonia

27. Defining a Task Network
Individual tasks and subtasks have interdependencies based on their sequence.
In addition, when more than one person is involved in a software engineering project, some tasks may be performed in parallel.
A task network (activity network) is a graphic representation of the task flow for a project.
Developed by Reneta Barneva, SUNY Fredonia

28. Defining a Task Network
Developed by Reneta Barneva, SUNY Fredonia

29. Defining a Task Network
Project scheduling methods: Program evaluation and review technique (PERT) and Critical path method (CPM). Both of them use information from 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
Developed by Reneta Barneva, SUNY Fredonia

30. Defining a Task Network
Both PERT and CPM provide quantitative tools that allow the software planner to
(1) determine the critical path—the chain of tasks that determines the duration of the project;
(2) establish "most likely" time estimates for individual tasks by applying statistical models;
(3) calculate "boundary times" that define a time "window" for a particular task.
Developed by Reneta Barneva, SUNY Fredonia

31. Defining a Task Network
Examples of timeline chart and
project table follow
Developed by Reneta Barneva, SUNY Fredonia

32. Defining a Task Network
Both PERT and CPM provide quantitative tools that allow the software planner to
(1) determine the critical path—the chain of tasks that determines the duration of the project;
(2) establish "most likely" time estimates for individual tasks by applying statistical models;
(3) calculate "boundary times" that define a time "window" for a particular task.
Developed by Reneta Barneva, SUNY Fredonia

33. Defining a Task Network
Developed by Reneta Barneva, SUNY Fredonia

34. Developed by Reneta Barneva, SUNY Fredonia
Tracking the Schedule
Tracking can be accomplished in a number of different ways:
Conducting periodic project status meetings in which each team member reports progress and problems.
Evaluating the results of all reviews conducted throughout the software engineering process.
Determining whether formal project milestones have been accomplished by the scheduled date.
Comparing actual start-date to planned start-date for each project task listed in the resource table.
Meeting informally with practitioners to obtain their subjective assessment of progress to date and problems on the horizon.
Developed by Reneta Barneva, SUNY Fredonia

35. Earned Value Analysis - a Method for Tracking the Schedule
To determine the earned value, the following steps are performed:
1. The budgeted cost of work scheduled (BCWS) is determined for each work task represented in the schedule.
During the estimation activity, the work (in person-hours or person-days) of each software engineering task is planned.
BCWSi is the effort planned for work task i.
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.
Developed by Reneta Barneva, SUNY Fredonia

36. Earned Value Analysis - a Method for Tracking the Schedule
2. The BCWS values for all work tasks are summed to derive the budget at completion, BAC.
BAC =  (BCWSi) for all tasks i
3. 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.
Developed by Reneta Barneva, SUNY Fredonia

37. Earned Value Analysis - a Method for Tracking the Schedule
Schedule performance index:
SPI is an indication of the efficiency with which the project is utilizing scheduled resources. An SPI value close to indicates efficient execution of the project schedule.
SPI = BCWP/BCWS
Developed by Reneta Barneva, SUNY Fredonia

38. Earned Value Analysis - a Method for Tracking the Schedule
Schedule variance:
SV is an absolute indication of variance from the planned schedule.
SV = BCWP - BCWS
Developed by Reneta Barneva, SUNY Fredonia

39. Earned Value Analysis - a Method for Tracking the Schedule
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.
Developed by Reneta Barneva, SUNY Fredonia

40. Developed by Reneta Barneva, SUNY Fredonia
The Project Plan
Each step in the software engineering process should produce a deliverable that can be reviewed and that can act as a foundation for the steps that follow.
The Software Project Plan provides baseline cost and scheduling information that will be used throughout the software process.
Developed by Reneta Barneva, SUNY Fredonia

41. Developed by Reneta Barneva, SUNY Fredonia
The Project Plan
The Software Project Plan is a relatively brief document that is addressed to a diverse audience. It must
(1) communicate scope and resources to software management, technical staff, and the customer;
(2) define risks and suggest risk aversion techniques;
(3) define cost and schedule for management review;
(4) provide an overall approach to software development for all people associated with the project; and
(5) outline how quality will be ensured and change will be managed.
Developed by Reneta Barneva, SUNY Fredonia