3.2.

4 SOTWARE PROJECT MANAGEMENT PLAN (SPMP)

After project planning is complete, project managers document the result of planning
phase in a Software Project Management Plan. Any ambiguity in the SPMP may raise
several questions in the mind of team members who join the group later. So, SPMP should
explain everything clearly. The structure of SPMP is as shown below:
1. Introduction
Objectives
Major functions
. Performance issues
Management & technical constraints
2. Project Estimates
Historical data used
Estimation technique used
Effort, resource, cost & project duration estimates
3. Risk Management Plan
Risk analysis
Risk identification
Risk estimation
Risk abatement plan
4. Schedule
Work Breakdown structu°e
" Task Network representation
Gantt Chart repres entation
PERT Chart representation
 SOFTWARE ENGINEERING
36
5. Project Resources
People
Software
" Hardwarc &
" Spccial resources
6. Staff organization
Team structure
" Managenent reporting
Plan
7. Project Tracking & Control
8. Miscellaneous Plan
Process tailoring
Quality assurance
Configuration management
Validation & Verification
System Testing
Delivery, Installation & Maintenance.
3.3 PROJECT ORGANIZATION

Organizing functions deals with devising roles for individuals & assigning responsibility
for accomplishing project goals. Organization is motivated by need for co-operation when the
goals are not achievable by a single human being in a reasonable amount of time. The task
of organizing can be viewed as building a team given
A group of people
C
A common goal
What is best role for each individual ?
How responsibilities should be divided ?
The main issues affecting the project organization are:
The nature of task & how much communication the different team members need
to have among themselves.
Size of the team

Personnel turnover( because adding people to a project late in development cycle

leads to further delay in schedule)
Size of the project
Module coupling( If the modules have high coupling then assigning modules
different people will require too much interaction among them)
SOFTWARE PROJECT MANAGEMENT 3.7

We can categorize software development team organization on the basis of vhere

decision making control lies. So types of organization are:
Centralized Control Team Organization
Decentralized Control Team organization
Mixed Control teamn Organization
3.3.1 CENTRALIZED CONTROL TEAM ORGANIZATION
In this mode, several workers report to a supervisor who directly controls their tasks
& is responsible for the performance. Centralized control is based on a hierarchical
organizational structure in which several supervisors report to a second level manager & so
on up the chain to the president of the enterprise. This organization works well with tasks
that are simple enough that one person responsible for the control of the project that can
grasp problem & its solution.
A software development is controlled by a chief programmer, who is an engineer
responsible for design & all technical details of the project. The chief programmer reports
to project manager who is responsible for administrative aspects of the project. Other team
members are librarian & other programmers who report to the chief programmer. Specialists
may be used as consultants when the need arises.
CHIEF PROGRAMMER

LIBRARIAN
SPECIALISTS

PROGRAMMERS

The figure shows a graphical representation of the patterns of control & communication
supported by this kind of organization. The need for programmers & consultants as well as
what task they perform is determined by the chief programmer who initiates and controls all
decisions. The software library maintained by the librarian is the central repository for all the
software, documentation & decisions made by the team.
This team has a single point failure as all comunication must go through & all
decisions must be made by the chief progranmer. The chief programmer may become
overloaded or saturated. The success of this team organization depends clearly upon the skill
& ability of the chief progran1mer & the size and complexity of the problem.
3.8 SOFTWARE ENGINEERING
3.3.2 DECENTRALIZED CONTROL TEAM ORGANIZATION
In this team structure, decisions are made by consensus and all work is considered
group work. Team members review each others' work and are responsible as a group what
other members produce. Such a team organization leads to higher morale and job satisfaction
and hence to less turnover. The engineers feel ownership of the project and responsibility for
the problem, leading to higher quality in the work. Adecentralized control organization is more
suited to long ten projects because the amount of intragroup comnunication that it encourages
leads to a longer development time. It is suitable for less understood &more complicated
problems because a group can invent better solution than a single individual. It is based on
a tecunique called egoless programming as it encourages programers to review &share
each others' work.

The figure shows a graphical representation of the patterns of control & communication
supported by this kind of organization. The ring like management structure is intended to
show the lack of a hierarchy and that all team members are at the same level.
The negative side of this structure is that it is not appropriate for large teams, where
the communication overhead can overwhelm all the engineers, reducing overall productivity.
It also runs the risk of establishing a group that is forever in futile search of a perfect solution
to please everyone.
3.3.3 MIXED CONTROL TEAM ORGANIZATION
Mixed control team organization attepts to combine the benefits of centralized &
decentralized control, while ninimizing or avoiding their disadvantages. This organization
distinguishes the engineers into senior & junior engineers. Each senior engineer leads a group
of junior engineers. The senior engineer in turn rep orts to project manager. Control is vested
in the project nanager & senior engineers while communication is decentralized among each
st of individuals & their immediate supervisor. This mode tries to limit the comumunication
tu within a smallgroup. It also tries to realize the benefits of group decision making by vesting
authority in a group of senior programmers.
SOFTWARE PROJECT MANAGEMENT 3.9

shown
The patterns of control & communication in the mixed control organization are
in the above diagrams.
3.4 PROJECT CONTROL

The pupose of project control is :

1. To monitor the activities against the plan
2. To ensure that the goals are being approached & being met
3. To detect ,as soon as possible, when deviation from the plan is occurring.
4. To minimize the need for correct1ve action.
3.4.1 WORK BREAKDOWN STRUCTURE
This project technique is based on breaking down the goal of a project into several
intermediate goals. Each intermediate goal is broken down further. This process is repeated
until each goal is small enough to be well understood. We can then plan for cach goal
individually. In this technique, one builds a tree whose root is labelled by the major activity
of the project. Each node of the tree can be broken down into smaller components that are
designated as the children of the node. This work breakdown can be repeated until each leaf
node in the tree is small enough to allow the manager to estimate its size, difficulty and
resource requirements. The goal of this technique is to identify the activities the project
should undertake. It gives the manager a framevork for breaking down large tasks into
manageable pieces. Then the manager can assign these units to different enployees. This
structue can also be used in scheduling because we come to know which task is to be done
first, second and so on. Aschedule tries to order the activitics to ensure their tinely completion.
3.4.2 GANTT CHARTS
Gantt clharts can be used for several purposes which are listed below:
Project Control
Scheduling
Budgeting
Resource planning
3.10
SOFTWARE ENGINEERINQ
representing an activity. The bars are dra.
Gantt clhart is abar chart with cach bar planned e
line. The length of cach bar is proportional to the length of time
against a time
that activity.
July 1,98 Nov 1,98
Jan 1,98 April 1,98

START Design

Coding

Testing

The above figure shows the time required to complete different activities of a software
deveiopment project in the form of Gantt Chart. A Gantt chart helps in scheduling activities
but it does not help in identifying them.
3.4.3 PERT (PROGRAM EVALUATION & REVIEW TECHNIQUE) CHARTS
This chart is a network of bOxes or circles & arrows. Each box represents an activity
& the arrows are used to show the dependencies of activities on one another. The activity
at the head of an arrow cannot start until the activity at the tail of the arrow is finished. The
activities in this chart can be labelled with starting & ending dates of the activity. Some boxes
can be designated as milestones. A milestone is an activity whose completion signals an
important accomplishment in the life of a project. On the other hand, failure to make a
milestone signals trouble to the manager and requires an action to deal with the deviation
from the schedule.
To build a PERT chart for a project, one must first list all activities
required for
completion of the project and estimates how long cach will take. Then one must determine
the dependence of the activities on each other. The PERT chart is a
of this information.
graphical representati0n
Jan 1,98 Jan 3,98 Mar 10,98 Aug 5,98

START DESIGN CODING TESTING

SOFTWARE PROJECT MANAGEMENT 3.11

The above figurc shows the activitics of a softwarc devclopment project , their starting
& cnding datcs, their interdependencics in the form of PERT Chart.
The advantages of using PERT chart
It forces the manager to plan
lt shows the interrelationship among the tasks in the projcct
It shows the critical path of the projcct thus hclping to focus on it.
It exposes all possible parallelism in the activities and helps in allocating resources.
It helps in scheduling
It enables the manager to nonitor &control the project.
The disadvantages of PERT chart are given below:
The use of this techniquc does not automatically guarantee the success of the
project.
It is not suitable for big projects as a PERT chart for such project may contain
hundreds of nodes.
Revision of such charts is necessary. So computer support is essential.