developed by reneta barneva, suny fredonia project scheduling and tracking

Developed by Reneta Barneva, SUNY Fredonia

Project Scheduling and Tracking


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.


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.


Software Project SchedulingSoftware 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.


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.


Software Project SchedulingTime 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.


Software Project SchedulingDefined 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.


The Relation Between People and Effort

Example: 4 software engineers, each capable of producing 5000 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 = 1680 LOC for the two months.

Team productivity now is 20,000 + 1680 - (250 x 14) = 18,180 LOC/year.



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.



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.



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.


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


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.



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.



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.



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.



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.



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.



Adaptation criteria: used to determine the recommended degree of rigor.

The following adaptation criteria are defined for software projects:

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 constraints

Embedded and non-embedded characteristics

Project staff

Reengineering factors



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 1.2 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.



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.



How to use task set selector value?

Degree of rigor

TSS < 1.2 casual

1.0 < TSS < 3.0 structured

TSS > 2.4 strict


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.


Refinement of Major TasksAfter 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).


Defining a Task NetworkIndividual 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.


Defining a Task Network


Defining a Task NetworkProject 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



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.



Examples of timeline chart and

project table follow



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.


Tracking the ScheduleTracking 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.


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.



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.



Schedule performance index:

SPI is an indication of the efficiency with which the project is utilizing scheduled resources. An SPI value close to 1.0 indicates efficient execution of the project schedule.

SPI = BCWP/BCWS



Schedule variance:

SV is an absolute indication of variance from the planned schedule.

SV = BCWP - BCWS



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.


The Project PlanEach 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.


The Project PlanThe 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.