Chapter-8

The chapter describes the process of building and monitoring schedules for software
development projects. To build complex software systems, many engineering tasks need to occur
in parallel with one another to complete the project on time. The output from one task often
determines when another may begin. Software engineers need to build activity networks that take
these task interdependencies into account. Managers find that it is difficult to ensure that a team
is working on the most appropriate tasks without building a detailed schedule and sticking to it.
This requires that tasks are assigned to people, milestones are created, resources are allocated
for each task, and progress is tracked.
Root Causes for Late Software

 Unrealistic deadline established outside the team

 Changing customer requirements not reflected in schedule changes
 Underestimating the resources required to complete the project
 Risks that were not considered when project began
 Technical difficulties that complete not have been predicted in advance
 Human difficulties that complete not have been predicted in advance
 Miscommunication among project staff resulting in delays
 Failure by project management to recognize project failing behind schedule and failure to
take corrective action to correct problems

How to Deal With Unrealistic Schedule Demands

1. Perform a detailed project estimate for project effort and duration using historical data.
2. Use an incremental process model that will deliver critical functionality imposed by deadline,
but delay other requested functionality.
3. Meet with the customer and explain why the deadline is unrealistic using your estimates
based on prior team performance.
4. Offer an incremental development and delivery strategy as an alternative to increasing
resources or allowing the schedule to slip beyond the deadline.

Project Scheduling Perspectives

 Project scheduling is an activity that distributes estimated effort across the planned project
duration by allocating the effort to specific software engineering tasks.
 One view is that the end-date for the software release is set externally and that the software
organization is constrained to distribute effort in the prescribed time frame.
 Another view is that the rough chronological bounds have been discussed by the developers
and customers, but the end-date is best set by the developer after carefully considering how
to best use the resources needed to meet the customer’s needs.
 Schedules evolve over time as the first macroscopic schedules are refined into the detailed
schedule for each planned software increment.

Software Project Scheduling Principles

 Compartmentalization - the product and process must be decomposed into a manageable

number of activities and tasks
 Interdependency - tasks that can be completed in parallel must be separated from those that
must completed serially
 Time allocation - every task has start and completion dates that take the task
interdependencies into account
 Effort validation - project manager must ensure that on any given day there are enough staff
members assigned to completed the tasks within the time estimated in the project plan
 Defined Responsibilities - every scheduled task needs to be assigned to a specific team
member

Gaurav sardhara Page 1

 Chapter-8
 Defined outcomes - every task in the schedule needs to have a defined outcome (usually a
work product or deliverable)
 Defined milestones - a milestone is accomplished when one or more work products from an
engineering task have passed quality review

Relationship between People and Effort

 Adding people to a project after it is behind schedule often causes the schedule to slip further
 The relationship between the number of people on a project and overall productivity is not
linear (e.g. 3 people do not produce 3 times the work of 1 person, if the people have to work
in cooperation with one another)
 The main reasons for using more than 1 person on a project are to get the job done more
rapidly and to improve software quality.

Scheduling

 Task networks (activity networks) are graphic representations can be of the task
interdependencies and can help define a rough schedule for particular project
 Scheduling tools should be used to schedule any non-trivial project.
 Program evaluation and review technique (PERT) and critical path method (CPM) ) are
quantitative techniques that allow software planners to identify the chain of dependent tasks
in the project work breakdown structure (WBS) that determine the project duration time.
 Timeline (Gantt) charts enable software planners to determine what tasks will be need to be
conducted at a given point in time (based on estimates for effort, start time, and duration for
each task).
 The best indicator of progress is the completion and successful review of a defined software
work product.
 Time-boxing is the practice of deciding a priori the fixed amount of time that can be spent on
each task. When the task's time limit is exceeded, development moves on to the next task
(with the hope that a majority of the critical work was completed before time ran out).

Tracking Project Schedules

 Periodic project status meetings with each team member reporting progress and problems
 Evaluation of results of all work product reviews
 Comparing actual milestone completion dates to scheduled dates
 Comparing actual project task start-dates to scheduled start-dates
 Informal meeting with practitioners to have them asses subjectively progress to date and
future problems
 Use earned value analysis to assess progress quantitatively

Estimation approaches

The top level categories are the following:

 Expert estimation: The quantification step, i.e., the step where the estimate is produced
based on judgmental processes.
 Formal estimation model: The quantification step is based on mechanical processes, e.g., the
use of a formula derived from historical data.
 Combination-based estimation: The quantification step is based on a judgmental or
mechanical combination of estimates from different sources.

Gaurav sardhara Page 2

 Chapter-8

Below are examples of estimation approaches within each category.

Estimation Examples of support of implementation of

Category
approach estimation approach

Analogy-based Formal estimation

ANGEL, Weighted Micro Function Points
estimation model

WBS-based (bottom Project management software, company specific activity

Expert estimation
up) estimation templates

Formal estimation
Parametric models COCOMO, SLIM, SEER-SEM
model

Size-based Function Point Analysis,[12] Use Case Analysis, SSU

Formal estimation
estimation (Software Size Unit), Story points-based estimation
model
models[11] in Agile software development

Group estimation Expert estimation Planning poker, Wideband Delphi

Mechanical Combination- Average of an analogy-based and a Work breakdown

combination based estimation structure-based effort estimate

Judgmental Combination- Expert judgment based on estimates from a parametric

combination based estimation model and group estimation

Following three macro-estimation techniques:

Estimating using equations

One technique for software project estimation involves the use of regression equations. These
equations allow you to calculate an estimate for a particular project metric such as effort or
duration by simply inserting the calculated, or estimated, size of your project into the appropriate
equation.

This estimation technique is commonly used to produce indicative or "ballpark" project estimates
early in the life of a project. This technique is not sufficiently accurate to produce an estimate that
could be relied on for quoting or business case requirements. A "ballpark" estimate can be used
for an early indication of whether a project idea is feasible, or when you are short of time and
detailed information.

These equations to calculate the following project metrics:

 Project Delivery Rate (person hours per fsm unit)

 Effort (person hours)
 Duration (elapsed hours)
 Speed of delivery (fsm units delivered per elapsed calendar month)

Gaurav sardhara Page 3

 Chapter-8
Equations are provided for:

 Platform, (Mainframe, Mid-range, PC & Mixed)

 Language Type (3GL, 4GL & Application Generator)

Estimation using comparison

Estimation using comparison allows you to achieve more detailed estimates than can be gained
using regression equations. Estimates using comparison are aligned more specifically to the
attributes of the project being planned rather than being based on those of the "average" project
Estimation using comparison involves a technique based on comparison of your planned project
with a number of projects.

Estimating using analogy

Analogy based estimation is another technique for early life cycle macro-
estimation. Analogy based estimation involves selecting one or two completed
projects that most closely match the characteristics of your planned project

Analogy based estimation differs from the comparison based estimation above,
in that comparison based estimation uses the medians from a group of similar
projects. Analogy operates with one, or perhaps two past projects selected on
the basis of their close similarity to the proposed project. Comparing a planned
project to a past project is commonly used in an informal way when
"guesstimating", consequently it is a familiar technique to the practitioner.

Project Scheduling (Basic Principles)

Software project scheduling is an activity that distributes estimated effort across

the planed project duration by allocating the effort to specific software
engineering tasks.

First, a macroscopic schedule is developed.

---> A detailed schedule is redefined for each entry in the macroscopic schedule.

A schedule evolves over time.

Basic principles guide software project scheduling:

 Compartmentalization
 Interdependency
 Time allocation
 Effort allocation
 Effort validation
 Defined responsibilities

Gaurav sardhara Page 4

 Chapter-8

 Defined outcomes
 Defined milestones

Defining a Task Network

Individual tasks and subtasks have interdependencies based on their sequence.

A task network is a graphic representation of the task flow for a project. Figure
shows a schematic network for a concept development project.

Critical path:

- The tasks on a critical path must be completed on schedule to make the whole
project on schedule.

T7 T8

T1 T2 T3 T4

T5 T6

Scheduling
Scheduling of a software project does not differ greatly from scheduling of any
multitask Engineering effort.
Two project scheduling methods:
- Program Evaluation and Review Technique (PERT)
- Critical Path Method (CPM)
Both methods are driven by information developed in earlier project planning
activities:
- Estimates of effort
- A decomposition of product function
- The selection of the appropriate process model
- The selection of project type and task set
Both methods allow a planer to do:
- determine the critical path

Gaurav sardhara Page 5

 Chapter-8
- Time estimation
- calculate boundary times for each task
Boundary times:
- The earliest time and latest time to begin a task
- The earliest time and latest time to complete a task
- The total float.

How is task network defined for SE?

The task network is a useful mechanism for depicting inters task dependencies
and determining the critical path. When more people are working on a software
engineering project, tasks and sub-tasks have their own inter-dependencies and
also as the number of people increases, the development activities and tasks are
performed in parallel. These concurrent tasks must be coordinated so that so that
they will be complete when later tasks require their work products.

What is a task network?

It is also known as activity network. It is a graphic representation of how the tasks
are flowing in a software engineering project. There is a pattern and a sequence
that is followed by tasks. This task network can be used as a mechanism or a
way to know this sequence and pattern of the tasks that can act as an input to an
automated project scheduling tool.
On a macroscopic view, take network depicts the software engineering tasks. On
a microscopic view, each and every task in the task network is expanded. For a
concept development project, task network includes the following tasks:
- Concept Scoping
- Concept Planning
- Technology and Risk Assessment (It constitutes three tasks).
- Proof of Concept
- Concept Implementation (It constitutes three tasks).
- Integrate the three tasks which constitute concept implementation.
- Customer Reaction

Gaurav sardhara Page 6

 Chapter-8
Software engineering activities are concurrent in nature. This nature leads to
scheduling requirements. The project manager should keep in mind the following
points to ensure continuous progress:
- He should determine the inter-task dependencies.
- He should be aware of tasks that lie on critical path which means the
tasks that should be completed on schedule if project has to complete on
schedule.

Purpose of a Task Network

• Also called an activity network

• It is a graphic representation of the task flow for a project
• It depicts task length, sequence, concurrency, and dependency
• Points out inter-task dependencies to help the manager ensure continuous
progress toward project completion
• The critical path
– A single path leading from start to finish in a task network
– It contains the sequence of tasks that must be completed on
schedule if the project as a whole is to be completed on schedule
– It also determines the minimum duration of the project

Gaurav sardhara Page 7

 Chapter-8
Timeline Chart
Timeline chart refers to user items that create a chart where a series of events are
arranged on a bar graph. Where by every event could be a single point in time or
date range.

• Also called a Gantt chart; invented by Henry Gantt, industrial engineer,

1917
• All project tasks are listed in the far left column
• The next few columns may list the following for each task: projected start
date, projected stop date, projected duration, actual start date, actual stop
date, actual duration, task inter-dependencies (i.e., predecessors)
• To the far right are columns representing dates on a calendar
• The length of a horizontal bar on the calendar indicates the duration of the
task
• When multiple bars occur at the same time interval on the calendar, this
implies task concurrency
• A diamond in the calendar area of a specific task indicates that the task is
a milestone; a milestone has a time duration of zero

Task # Task Name Duration Start Finis Pred.

h
1 Task A 2 months 1/1 2/28 None

2 Milestone N 0 3/1 3/1 1

Gaurav sardhara Page 8

 Chapter-8
PERT chart (Program Evaluation Review Technique)
A PERT chart is a project management tool used to schedule, organize, and coordinate
tasks within a project. PERT stands for Program Evaluation Review Technique, a
methodology developed by the U.S. Navy in the 1950s to manage the Polaris submarine
missile program. A similar methodology, the Critical Path Method (CPM) was developed
for project management in the private sector at about the same
time.

A PERT chart presents a graphic illustration of a project as a network diagram consisting

of numbered nodes (either circles or rectangles) representing events, or milestones in
the project linked by labeled vectors (directional lines) representing tasks in the project.
The direction of the arrows on the lines indicates the sequence of tasks. In the diagram,
for example, the tasks between nodes 1, 2, 4, 8, and 10 must be completed in sequence.
These are called dependent or serial tasks. The tasks between nodes 1 and 2, and nodes
1 and 3 are not dependent on the completion of one to start the other and can be
undertaken simultaneously. These tasks are called parallel or concurrent tasks. Tasks
that must be completed in sequence but that don't require resources or completion
time are considered to have event dependency. These are represented by dotted lines
with arrows and are called dummy activities. For example, the dashed arrow linking

Gaurav sardhara Page 9

 Chapter-8

nodes 6 and 9 indicates that the system files must be converted before the user test can
take place, but that the resources and time required to prepare for the user test (writing
the user manual and user training) are on another path. Numbers on the opposite sides
of the vectors indicate the time allotted for the task.

The PERT chart is sometimes preferred over the Gantt chart, another popular project
management charting method, because it clearly illustrates task dependencies. On the
other hand, the PERT chart can be much more difficult to interpret, especially on
complex projects. Frequently, project managers use both techniques.

In short what it is:

A PERT chart is a graphic representation of a project’s schedule, showing the
sequence of tasks, which tasks can be performed
Simultaneously, and the critical path of tasks that must be completed on time in
order for the project to meet its completion deadline. The
chart can be constructed with a variety of attributes, such as earliest and latest
start dates for each task, earliest and latest finish dates for
Each task and slack time between tasks. A PERT chart can document an entire
project or a key phase of a project. The chart allows a
Team to avoid unrealistic timetables and schedule expectations, to help identify
and shorten tasks that are bottlenecks, and to focus
Attention on most critical tasks.
When to use it:
Because it is primarily a project-management tool, a PERT chart is most useful
for planning and tracking entire projects or forScheduling and tracking the
implementation phase of a planning or improvement effort.
How to use it:
Identify all tasks or project components. Make sure the team includes people
with firsthand knowledge of the project so thatDuring the brainstorming session
all component tasks needed to complete the project are captured. Document the
tasks on small note Cards.
Identify the first task that must be completed. Place the appropriate card at
the extreme left of the working surface.
Identify any other tasks that can be started simultaneously with task #1.
Align these tasks either above or below task #1on the working surface.
Identify the next task that must be completed. Select a task that must wait to
begin until task #1(or a task that starts simultaneously with task #1) is completed.
Place the appropriate card to the right of the card showing the preceding task.
Identify any other tasks that can be started simultaneously with task #2.
Align these tasks either above or below task #2 on the working surface.

Gaurav sardhara Page 10

 Chapter-8
Continue this process until all component tasks are sequenced.Identify
task durations. Using the knowledge of team members, reach a consensus on
the most likely amount of time each task will Require for completion. Duration
time is usually considered to be elapsed time for the task, rather than actual
number of hours/days spe
Identify task durations. Using the knowledge of team members, reach a
consensus on the most likely amount of time each task will require for
completion. Duration time is usually considered to be elapsed time for the task,
rather than actual number of hours/days spent doing the work. Document this
duration time on the appropriate task cards.
Construct the PERT chart. Number each task, draw connecting arrows, and
add task characteristics such as duration, anticipated Start date, and anticipated
end date.
Determine the critical path. The project’s critical path includes those tasks that
must be started or completed on time to avoid delays to the total project. Critical
paths are typically displayed in red.
Note: Most commercially available project management software will routinely
generate a PERT chart.
Monitoring & Control
The Monitoring and Controlling process oversees all the tasks and metrics
necessary to ensure that the approved and authorized project is within scope, on
time, and on budget so that the project proceeds with minimal risk. This process
involves comparing actual performance with planned performance and taking
corrective action to yield the desired outcome when significant differences exist.
Monitoring and Controlling process is continuously performed throughout the life
of the project.
Monitoring and Control definition
Monitoring what is happening, taking the appropriate actions when:
– we have delays,
– the costs are over planed, or
– Some of the previous conditions, accorded before, and that were
important in the planning and acceptance, are missed.
Goals
– Determine if the project is under control.
– Identify if the project is out of control

Gaurav sardhara Page 11

 Chapter-8
Determine if the project is under control
– We arrive to the milestones:
– On time.
– With the expected resources.
– With the quality expected.
– It’s economically acceptable.

Identify if the project is out of control

As soon as we observe some deviations, we must:
– Revise the plan.
– Negotiate the new plan with.

Definition: Controlling a software project." Defined as all the management

activities that ensure that the actual work goes according to plan
– It measures performance against goals and plans,
– reveals when and were deviations exists, and
– by putting in motion actions to correct deviations,
Helps ensure accomplishment of plans” (Thayer 1988)

Definition: “Control is the process of making things happen in an ordered

manner or according to plan.” (Reifer)

Why we need control?

Because when we plan, we use “estimations” of:
– Software size.
– Necessary tasks.
– Necessary resources for each task.
– Expected Productivity.
– Usually plan differs from realty.
– Software projects substantially differ from one to the next.

Gaurav sardhara Page 12

 Chapter-8
Work flow when controlling a project

Development start

Gather actual project

information

Plan (Expected)
Compare progress with Corrective
target and standards actions
Standards of
performance
NO
Satisfactory?

Yes
¿Project NO
finished?
Yes
Development end

Controlling activities:
Develop standards of performance.
Set conditions or measurements that will exists when tasks are
correctly done.
Establish monitoring and reporting systems.
Determine necessary data, who will receive it, and when they will
receive it
Reward and discipline
Praise, remunerate, and discipline applicable personnel.
Document controlling methods.
Document the standards, methods of reporting and control, bonus
plans et al., decisions points, and so on.

Gaurav sardhara Page 13