Software project

scheduling
Reasons why software is delivered late, most can be traced to one or more of the following
root causes:
• An unrealistic deadline established by someone outside the software team and forced on
managers and practitioners.
• 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.
The reality of a technical project is that hundreds of small tasks must occur to
accomplish a larger goal. Some of these tasks lie outside the mainstream and may
be completed without worry about impact on project completion date. Other tasks
lie on the “critical path.” If these “critical” tasks fall behind schedule, the completion
date of the entire project is put into jeopardy.

As a project manager, your objective is to

define all project tasks,
build a network that depicts their interdependencies,
identify the tasks that are critical within the network,
and then track their progress to ensure that delay is recognized “one day at a time.”

To accomplish this, you must have a schedule that has been defined at a degree of resolution
that allows progress to be monitored and the project to be controlled.
Scheduling for software engineering projects can be viewed from two different
perspectives.

The first view is , an end date for release of a computer-based system has already (and
irrevocably) been established. The software organization is constrained to distribute effort
within the prescribed time frame.

The second view of software scheduling assumes that rough chronological bounds have
been discussed but that the end date is set by the software engineering organization. Effort
is distributed to make best use of resources, and an end date is defined after careful
analysis of the software.
Basic Principles that guide software project scheduling:
Compartmentalization. The project must be compartmentalized into a number of
manageable activities and tasks. To accomplish compartmentalization, both the product
and the process are refined.

Interdependency. The interdependency of each compartmentalized 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.

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 people on the software team. As
time allocation occurs, you must ensure that no more than the allocated number of people
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 component)
or a part of a work product. Work products are often combined in deliverables.

Defined milestones. Every task or group of tasks should be associated with an project
milestone. A milestone is accomplished when one or more work products has been
reviewed for quality and has been approved.

Each of these principles is applied as the project schedule evolves.

Over the years, empirical data and theoretical analysis have demonstrated that project
schedules are elastic. That is, it is possible to compress a desired project completion date
(by adding additional resources) to some extent. It is also possible to extend a completion
date (by reducing the number of resources).
Defining a task set

A task set is a collection of software engineering work tasks, milestones, work

products, and quality assurance filters that must be accomplished to complete a
particular project.

The task set must provide enough discipline to achieve high software quality. But, at
the same time, it must not burden the project team with unnecessary work.

Regardless of the process model that is chosen, the work that a software team performs
is achieved through a set of tasks that enable you to define, develop, and ultimately
support computer software. No single task set is appropriate for all projects.

The set of tasks that would be appropriate for a large, complex system would likely
be perceived as overkill for a small, relatively simple software product. Therefore, an
effective software process should define a collection of task sets, each designed to
meet the needs of different types of projects
Defining task network

A task network, also called an activity network, is a graphic representation of the

task flow for a project. It is sometimes used as the mechanism through which task
sequence and dependencies are input to an automated project scheduling tool. In its
simplest form (used when creating a macroscopic schedule), the task network
depicts major software engineering actions

The concurrent nature of software engineering actions leads to a number of

important scheduling requirements. Because parallel tasks occur asynchronously,
you should determine inter-task dependencies to ensure continuous progress toward
completion. In addition, you should be aware of those tasks that lie on the critical
path. That is, tasks that must be completed on schedule if the project as a whole is
to be completed on schedule.
Scheduling tools and techniques

Program evaluation and review technique (PERT) and the critical path method (CPM)
are two project scheduling methods that can be applied to software development.

Both techniques are driven by information already developed in earlier project planning
activities:
estimates of effort, a decomposition of the product function, the selection of the
appropriate process model and task set, and decomposition of the tasks that are selected.
Interdependencies among tasks may be defined using a task network.

Tasks, sometimes called the project work breakdown structure (WBS), are defined for
the product as a whole or for individual functions.
Both PERT and CPM provide quantitative tools that allow you 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, and
(3) calculate “boundary times” that define a time “window” for a particular task.
When creating a software project schedule, you begin with a set of tasks (the work
breakdown structure). Effort, duration, and start date are then input for each task. In
addition, tasks may be assigned to specific individuals.

As a consequence of this input, a time-line chart, also called a Gantt chart, is generated. A
time-line chart can be developed for the entire project. Alternatively, separate charts can be
developed for each project function or for each individual working on the project.

Once the information necessary for the generation of a time-line chart has been input, the
majority of software project scheduling tools produce project tables—a tabular listing of
all project tasks, their planned and actual start and end dates, and a variety of related
information. Used in conjunction with the time-line chart, project tables enable you to
track progress.
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 softwareengineering
process
• Determining whether formal project milestones have been accomplished by the
scheduled date
• Comparing the actual start date to the 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
• Using earned value analysis to assess progress quantitatively
Earned Value Analysis
Earned Value Analysis (EVA) is a project management technique used to measure project performance and
progress in an objective manner. In the context of software project scheduling, EVA helps track whether the
project is on schedule and within budget, and it can identify early warning signs of potential issues.

Key Concepts and Terms

Planned Value (PV)
Also called Budgeted Cost of Work Scheduled (BCWS).
It is the estimated value of the work planned to be done by a certain date.
Earned Value (EV)
Also called Budgeted Cost of Work Performed (BCWP).
It is the estimated value of the work actually completed by a certain date.
Actual Cost (AC)
Also called Actual Cost of Work Performed (ACWP).
It is the real cost incurred for the work completed.
Performance Metrics
These values are used to compute key performance indicators:
1. Schedule Variance (SV)
SV=EV−PV Indicates whether you're ahead or behind schedule.
Positive = ahead of schedule
Negative = behind schedule

2. Cost Variance (CV)

CV=EV−AC Shows cost efficiency of the project.
Positive = under budget
Negative = over budget

3. Schedule Performance Index (SPI)

SPI=EV/PV Measures schedule efficiency.
SPI < 1 means less work done than planned.

4. Cost Performance Index (CPI)

CPI=EV/AC​ Measures cost efficiency.
CPI < 1 means spending more than planned.
Example in a Software Project
Suppose a software project is scheduled to finish in 10 weeks with a total budget of ₹10,00,000.
By the end of week 5:
Planned Value (PV) = ₹5,00,000 (planned halfway progress)
Earned Value (EV) = ₹4,00,000 (only 40% of work actually completed)
Actual Cost (AC) = ₹5,50,000
Then,
SV = 4,00,000 - 5,00,000 = -₹1,00,000 → behind schedule
CV = 4,00,000 - 5,50,000 = -₹1,50,000 → over budget
SPI = 0.8 and CPI = 0.73 → not efficient in time or cost

Benefits of EVA in Software Projects

Detects deviations early
Enables corrective action before it's too late
Provides a single system for schedule and cost control
Improves decision-making based on data