Project
2001
Figure 1: An example of timeline
chart (detailed Scheduling)
Justification through
an Example:
Using Bar charts (or) Gantt
charts:
A bar chart, is perhaps the
simplest form of formal management.
The bar chart is used almost
exclusively for scheduling purposes
and therefore controls only
the time dimension of projects.
Gantt chart (developed by Henry
L. Gantt) are a project control
technique that can be used for
several purposes, including
scheduling, budgeting and resources
planning. A Gantt chart is a
bar chart, with each bar representing
an activity. The bars are drawn
against time line. The length
of each bar is proportional
to the length of the time planned
for the activity.
Let us draw a Gantt chart for
the tasks identified in the
WBS figure 1. We estimate the
number of days required for
each of the six tasks as follows:
initial design, 45; scanner,
20; parser, 60; code generator,
180; integrating and testing,
90; and writing the manual,
90.Using this estimates, we
can draw Gantt chart of figure
for the compiler project.
A Gantt chart helps in scheduling
the activities of a project,
but it does not help in identifying
them. One can begin with the
activities identified in the
work breakdown structure, as
we did for the compiler example.
During the scheduling activity,
and also during implementation
of the project, new activities
may be identified that were
not envisioned during the initial
planning. The manager must then
go back and revise the breakdown
structure and the schedules
to deal with these activities.
The Gantt chart in the figure
is actually an enhanced version
of standard Gantt charts. The
white part of the bar shows
the length of the time each
task is estimated to take. The
gray part shows the slack time,
that is, the latest time by
which a task must be finished.
One way to view the slack time
is that, if necessary, we can
slide the while area over the
gray area without forcing the
start of the next activity to
be delayed. For example, we
have freedom to delay the start
of building the scanner to as
late as October 17, 1994 and
still have it finished in time
to avoid delaying the integration
and testing activity.
This example shows that the
Gantt chart can be used for
resources allocation and staff
planning. For example, from
the figure, we can conclude
that the same engineer can be
assigned to do the scanner and
the parser while another engineer
is working on the code generator.
Even so, the first engineer
will have some slack time that
we may plan to use to help the
second engineer or to get a
head start on the integration
and testing activity.
Gantt charts can take different
forms depending on their intended
use. They are best for resource
scheduling. For example, if
we are trying to schedule the
activities of six engineers,
we might use Gantt chart in
which each bar represents one
of the engineers. In such a
chart, the engineers are out
resources and the chart shows
the resources loading during
the project. It can help, for
example, in scheduling action
time, or in ensuring that the
right number of engineers will
be available during each desired
period. The following Figure
shows an example. We could label
appropriate sections of the
bars to show how much time we
expect each engineer to spend
on each activity (e.g., design
and building the scanner). Gantt
charts are useful for resource
planning and scheduling. While
they show the tasks and their
duration’s clearly, however,
they do not show intertask plainly.
When a bar chart is used as
a project control method, milestones
or checkpoints usually are placed
at the completion of each task
(they may also be placed within
tasks). They indicate the completion
of a particular task and the
basis for determining whether
the task and the project are
on schedule; when a checkpoint
is reached, the task just completed
and the entire project are reviewed
and evaluated. Reviewers ask
whether resources allocated
have been properly utilized
and whether the task has been
satisfactorily completed. However,
because the bar chart incorporates
only the scheduling dimension
of a project, it gives little
indication of which tasks must
be completed before others are
begun, and project costs must
be accumulated and evaluated
using the other methods.
The same compiler project
example can be explained via
PERT as follows:
The chart shows that the path
through the project that consists
of the design, build code generator
and integrating and testing
activities is the critical path
for the project. Any delay in
any activity in this path will
cause delay in the entire project.
The manager will clearly want
to monitor the activities on
the critical path much more
closely than the other activities.
Risk Analysis
Risks mitigation, monitoring
and management
We came up with the following
list of risks related to the
software engineering project
and a list of proactive prevention
to that risk. It should be noted
that risk can only be approximated
but cannot be measured like
other values
Risks before software is developed
Team members’ health
and motivation is very important
for the development of good
software. It also accounts for
that the team members are technically
skilled to carry on with project.
The members should be excited
to learn and contribute as much
as possible. We are going through
lots of learning and regularly
discussing the materials we
have learned. Members have good
understanding between the group.
Each one appreciates other work
and eager to help each other
any time.
Priority of the work –
In projects everybody should
prioritize the work. If member
are not going according to the
schedule and not working according
to priority then there will
be lot of hindrance to the project.
The seriousness and dedication
of work is very important. Since
we are graded for that we are
very serious about it.
Lack of interest by customer
team – During the development
of the project it could happen
that the customer might not
cooperate with our development.
To avoid that we are constantly
discussing with the customer
team to avoid confusion and
to build better and user friendly
product
thus it is justified that it
is not possible to manage a
project if only a macroscopic
schedule is developed.
