Project
2001
What
is the difference between a
Macroscopic Schedule and a detailed
Schedule? Is it possible to
manage a project if only a macroscopic
schedule is developed? Justify
by taking an example with reasons
PROJECT SCHEDULING
AND TRACKING
We have selected an appropriate
process model, we have identified
the software engineering tasks
that have to be performed, we
eliminated the amount of work
and the number of people, we
know the deadline, we have even
considered the risks. Now it’s
time to connect the dots. That
is, we have to create a network
of software engineering tasks
that will enable we to get the
job done on time. Once the network
is created, you have to assign
responsibility for each task,
make sure it gets done, and
adapt the network as risks becomes
reality. In a nutshell, that’s
software project scheduling
and tracking.
Importance:
In order to build a complex
system, many software engineering
tasks occur in parallel, and
the result of work performed
during one task may have a profound
effect on work to be conducted
in another task. These interdependencies
are difficult to understand
without a schedule. “It’s
also virtually impossible to
asses progress on a moderate
or large software project without
a detailed schedule.”
Basic Principles
Software project scheduling
is an activity that distributes
estimated effort across the
planned project duration by
allocating the effort to specific
software engineering tasks.
It is important to note, however,
that the schedule evolves over
times. During early stages of
project planning, a macroscopic
schedule is developed. This
type of schedule identifies
all major software engineering
activities and the product functions
which they are applied. As the
project gets underway, each
entry on the macroscopic schedule
is refined into a detailed schedule.
Here, specific software tasks(required
to accomplish an activity) are
identified and scheduled.
Scheduling for software engineering
projects can be viewed from
two rather different perspectives.
In the first, 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 of resources and an end-date
is defined after careful analysis
of the software.
Unfortunately, the first situation
is encountered, the first situation
is encountered far more frequently
than the second.
Like all the other areas of
software engineering, a number
of basic principles 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 decomposed.
Interdependency. The interdependency
of each compartmentalized activity
or task must be determined.
Some tasks must occur in sequence
in while others can occur in
parallel. Some activities cannot
commence until the work product
produced by another available.
Other activities can occur independently.
Time allocation. Each task should
be scheduled must be allocated
some number of work units(e.g.,
person-days effort). In addition,
each task must be assigned a
start date and completion date
are a function of the interdependencies
and whether the work will be
conducted on a full-time or
part-time basis.
Effort validation. Every project
has defined number of defined
members. As time allocation
occurs, the project manager
must ensure that no more than
the allocated number of people
has been scheduled at any given
time. For example, consider
a project that has three assigned
staff members (e.g., 3 person-days
available per day of assigned
effort). On a given day, seven
concurrent tasks must be accomplished.
Each task requires 0.50 person
days of effort. More effort
has been allocated then there
are people to do the work.
Defined responsibilities. Every
task that is scheduled should
be assigned to a specific team
member.
Defined outcomes. Every task
is scheduled should have defined
outcome. For software projects,
the outcome is normally a work
product (e.g., the design of
a module) or a part of work
product. Work products are often
combined in deliverables.
Defined milestones. Every task
or group 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.
Each of these principles is
applied as the project schedule
evolves.
SCHEDULING
Process Model
A linear sequential software
development process model named
RAD (Rapid Application Development)
is a variation of the waterfall
model, and is used in our project
so said.
In spite of its weakness, it
has been used throughout our
project because of the following:
The duration of our project
has been estimated to be less
than 90-days, and which is reasonably
RAD model.
The development software we
use is RAD such as Visual Basic,
Visual InterDev and Delphi,
which emphasizes Visual Development.
Our Project is an Information
System Application and which
again is a RAD.
Hence, studies and discussions
over different projects were
done and this model, RAD, has
been used.
Macroscopic
Schedule
In order to get a general overview
of the entire project the first
thing that we did was the macroscopic
schedule:
Detailed Schedule
Scheduling of software project
does not differ greatly from
scheduling of any multitask
engineering effort. Therefore,
generalized project scheduling
tools and techniques can be
applied with little modification
to software projects.
Difference between
a macroscopic schedule and a
detailed schedule:
Software project scheduling
is an activity that distributes
estimated efforts across the
planned project duration by
allocating the effort to specific
software engineering tasks.
It is important to note, however,
that the schedule evolves over
time. During early stages of
project planning, a macroscopic
schedule is developed. This
type of schedule identifies
all major software engineering
activities and the project functions
to which they are applied. As
the project get under way, each
entry on the macroscopic schedule
is refined into detailed schedule.
Here, specific software tasks
are identified and scheduled.
Scheduling for software engineering
projects can be viewed from
rather different perspectives.
In the first, an end-date for
release of a computer-based
system has already 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 organization.
Effort is distributed to make
best use of resources and an
end-date is defined after careful
analysis of the software. Unfortunately,
the first situation is encountered
far more frequently than the
second.
Thus it is not possible to
manage a project if only a macroscopic
schedule is developed
Importance of detailed schedule
:
In order to build a complex
system, many software-engineering
tasks occur in parallel and
the result of work performed
during one tasks may have a
profound effect on work to conducted
in another task. These inter-
dependencies are very difficult
to understand without a schedule.
It’s also virtually impossible
to assess progress on a moderate
or large software project without
a detailed schedule.
So, It is impossible to manage
a project if only a macroscopic
schedule is developed.
Basic principle of software
project scheduling:
The follworing basic principle
in different area of software
engineering
1. Compartmentalization :
The project must be compartmentalization
into a number of manageable
activites and tasks. To accomplish
compartmentalization, both the
product and the process are
decomposed.
2. 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.
3. Time allocation :
Each task to be scheduled must
be allocated some number of
work units. 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.
4. Effort validation :
Every project has a defined
number of staff members. As
time allocation occurs, the
project manager must ensure
that no more that the allocated
number of people have been scheduled
at any given time. For example,
consider a project that has
three assigned staff members.
On a given day , seven concurrent
tasks must be accomplished.
Each task requires 0.50 person
days of effort. More effort
has been allocated that there
are people to do the work.
5. Defined responsibilities
:
Every task that is scheduled
should be assigned to a specific
team member.
6. Defined outcomes :
Every task that is scheduled
should have a defined outcome.
For software projects, the outcome
is normally a work product or
a part of a work product. Work
products are often combined
in deliverables.
7. Defined milestones :
Every task or group of tasks
should be associated with a
project 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.
Example :
Scheduling of a software project
does not differ greatly from
scheduling of any multitask
engineering effort. Therefore
, generalized project scheduling
tools and techniques can be
applied with little modification
to software projects.
Program evalutation and review
technique (PERT) and critical
path scheduling 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 efforts
A decomposition of the product
function
The selection of the appropriate
process model and task set
Decomposition of tasks
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 quantitive
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 estimate for individual
tasks by applying statistical
models.
(3) Calculate “boundary
times” that define a time
“window” for particular
task.
Boundary time calculation can
be very useful in software project
scheduling slippage in the designing
of one function, for example,
can retard further development
or other functions. Riggs describes
important boundary times that
may be discerned from PERT and
CPM network. (1) The earliest
time that a task can begin when
all preceding tasks are completed
in the shortest possible time,
(2) the latest time for task
initialization before the minimum
project completion time is delayed,
(3) the earliest finish-the
sum of the earliest start and
the task duration, (4) the latest
finish surplus time or leeway
allowed in scheduling tasks
so that the network critical
path is maintained on the schedule.
Boundary time calculations lead
to determination of critical
path and provide the manager
with a quantitative method for
evaluating progress as tasks
are completed.
Both PERT and CPM have been
implemented a wide variety of
automated tools that are available
for the personal computer. Such
tools are easy to use and make
the scheduling methods.
Some of the advantages of PERT
are as follows:
It enforces the manager to
plan.
It shows the interrelationships
among the tasks in the project
and, in particular, clearly
identifies the critical path
of the project, thus helping
to focus on it.
It exposes all possible parallelism
in the activities and thus helps
in allocating resources.
It allows scheduling and simulation
of alternative schedules.
It enables the manager to
monitor and control the project.
Despite these advantages, PERT
is just a tool, and it use does
not automatically guarantee
the success of the project.
The manager has much latitude
in hoe PERT is used. For example,
the granularity of the manager.
Many variations of PERT charts
are possible. For example, we
could be interested in the earliest
time in which an event can be
accomplished or the latest time
in which it can be accomplished.
In the model presented, there
is one resources associated
with each activity, that of
time. We can also incorporate
other resources, such has personnel
requirements or computer time,
to help with budgeting for the
project.
PERT is highly developed methodology,
and full descriptions of it
are widely available. Many variations
of PERT exist, some of which
are incorporated into computer
programs and are available as
computerized project management
systems.
Over the years computer business
has had its share of failures
in terms of systems which were
not completed on schedule, cost
substantially more than the
original budget, were less than
successful in meeting the users
requirements or which collapsed.
This is not just what happened
in the past; failures and disasters
still occur. The most likely
to be first-time user and since
many functional management departments
are likely to be first-time
users it is worth considering
how problems can arise and also
the stages which a system must
pass through
from time the initial seed is
sown through to a review of
well the resulting system is
performing.
Various factors can be identified
as contributing to unsuccessful
systems development and among
the most important are:
The failure to establish clearly
what the system should do –
not finding out the true requirements
of the user(s).
The lack of top management
involvement with the system,
leading perhaps to the failure
to take proper policy decisions.
Inaccurate or unreasonable
original estimates of the effort
required and the costs involved
– computer people (in
particular computer sales people)
are notoriously optimistic when
it comes to proposing implementation
timetables.
The lack of proper systems
development methodology and
standards.
The lack of proper communications
between everyone involved in
the system.
The lack of appropriate training
and procedures.
