Chapter: 8

Managing Software Project

 Software Project Management
A project is a group of tasks that need to complete to reach a
clear result. Projects can vary from simple to difficult and can
be operated by one person or in a group.
A Software Project is the complete procedure of software
development from requirement gathering to testing and
maintenance, carried out according to the execution
methodologies, in a specified period of time to achieve
intended software product.
Software Project Management (SPM) is a proper way of
planning and leading software projects. It is a part of project
management in which software projects are planned,
implemented, monitored and controlled.
It is a procedure of managing, allocating and timing resources
to develop computer software that fulfills requirements.
In software Project Management, the client and the developers
need to know the length, period and cost of the project.
 Software Project Manager
A software project manager is a person who
undertakes the responsibility of planning, executing
and controlling the software project.
A project manager closely monitors the development
process, prepares and executes various plans,
arranges necessary and adequate resources,
maintains communication among all team members
in order to address issues of cost, budget, resources,
time, quality and customer satisfaction.
Project managers are responsible for planning and
scheduling project development. The managerial
person who supervise the development work to
ensure that, it is carried out to the required
standards and monitor progress to check that the
development is on time and within budget.
SPM is Differ from Other PM
The product is intangible
The software product is intangible in nature and it can be
realized only, it cannot be seen or touched. So, it is difficult
for project manager to measure progress and should rely on
documentation produced by others.
There are no standard software processes
With a long history in engineering discipline, the process is
tried and tested. The engineering process for some types of
system, such as building construction is well understood but
in software project there is no universally accepted fixed
standard ,process change from one organization to another
and project to project.
Large software Projects are often One-off Projects
Software technology is changing very rapidly and it makes the
manager’s experience and skill obsolete. Lessons learned
from previous project may not be transferrable to new
projects. So, managers having massive volume of experience
may find it difficult to anticipate problems.
Management Activities
Some common activities of project managers are as
follows:
1. Proposal Writing
Project manager have to write the project proposal to
win a contract from the customer. Proposal writing is
a skill that acquire through practice and experience.
Proposal should include the objective of the project
and how it will be carried out. It also includes cost
and schedule estimates and justification why the
project contract awarded to a particular organization
or team.
2. Project Planning and Scheduling
Project planning is concerned with identifying
activities, milestones and deliverable produced by a
project. A plan is drawn up to guide the development
team towards the project goals.
3. Project Cost
Project cost includes cost estimation activity that is concerned with
estimating the effort, time and resources require accomplishing
the project development. The parameters involved in computing
the total cost of a software development project includes:
hardware and software costs including maintenance, travel and
training costs and Effort costs i.e. the costs of paying software
engineers and others.
 Estimation involves answering the following questions.
 How much effort is required to complete each activity?
 How much calendar time is needed to complete each activity?
 What is the total cost of each activity?
4. Project Monitoring and Reviews
It is the continuing project activity. In this the managers must keep
the track of progress of project and compare actual and planned
progress and costs. Managers clear that what is going on through
informal discussion with project staff and review concerned with
overall progress and technical development of system and
checking whether the project and goals of the organization paying
for the software are still aligned.
5. Personnel Selecting and Evaluation
Project managers usually have to select people to work on
their project. Ideally, skilled staff with appropriate
experience will be available to work on their project but
in most cases, managers have to settle for a less than
ideal project team members because.
 The project budget may not cover the use of highly paid
staff. Less experienced, less well paid staff may have to
be used.
 Staff with appropriate experience may not be available
either within an organization or externally. It may be
impossible to recruit new staff to the project.
 The organization may wish to develop a skill of its
employees. Inexperienced staff may be assigned to a
project to learn and to gain experiences.
6. Report Writing and Presentation
Project managers are usually responsible for reporting on
the project to both the client and contractor
Project Planning
Software project planning is task, which is
performed before the production of software
actually starts.
The project plan sets out the resources available
to the project the work breakdown and a
schedule for carrying out the work.
So, effective management of software project
depends on the thoroughly planning the
progress of project. A plan drawn up at the
starting of a project should be used as driver for
the project.
The planning is an iterative. Process, which is
only complete when the project itself is
complete. As the project information becomes
 Components of Project Plan
1. Introduction : It describes the objectives of the projects and
sets out the constraints like budget, time etc that affect the project
management.
2. Project Organization : It describes the way in which
development team is organized, the people involved and their role in
the team.
3. Risk Analysis: This describes the possible project risk, the
likelihood of these risks arising and the risk reduction strategies that
are proposed.
4. Hardware and Software resource requirement : This
specifies the hardware and software required to carry out the
development. If the hardware has to be bought estimates of prices
and delivery schedule may be included.
5. Work Breakdown: In this phase the project is breakdown into
activities and identifies the milestones and deliverables associated
with each activity.
6. Project Schedule: This phase shows the dependencies
between activities the estimated time required to reach each
milestone and allocation of people to each activity.
7. Monitoring and Reporting Mechanism: This defines the
management report that should be produced.
 Types of Project Plan
2. Quality Plan
This plan describes the quality features that must be accommodated
in the project and approaches that can be applied to achieve
required level of quality.
2. Validation Plan
Validation plan describes the approach, resources and schedule
used for system validation. It is intended to show that the program
does what the user requires.
3. Configuration management Plan
This plan includes the management of system change. When a
system is maintained the role of the CM team is to ensure that
changes are incorporated in a controlled way. This plan includes
configuration management procedures and structures to be used.
4. Maintenance Plan
It predicts the maintenance requirements of the system,
maintenance cost and effort required.
5. Staff Development Plan
It describes how the skill and experience of the project team
member will be developed.
Milestones and Deliverables
Milestones
Project milestones are the predictable outcome of an
activity where some formal report of progress.
Milestones are the recognizable end point of software
process activity, They may be short report of what has
been completed and presented to the management.
Milestones should represent the end of a distinct,
logical stage in the project.
Deliverables
A deliverable is a project report (result) that is
delivered to the customer at the end of some major
project phase. Deliverables are usually milestones but
milestones need to be deliverables. The project
deliverable, which are delivered to customer are the
requirement definition and requirement specification.
Milestones

Fesigibility Requirement Prototype System Requirement

Study Analysis Development Design Specification

Fesigibility Users Evaluation Design and System

Report Requirements Report Architecture Requirement
 Risk Management
Risk means something that if occur threaten the
project development process regularly and influence
the project schedule and product quality. Risks are
the factor that the project manager would prefer not
to have happen. The risk that may affect the project
depends on the project and organizational
environment where the software is being developed.
The risk management is process of identifying risks
that might affect the project schedule or quality of
the project/software being developed and taking
action to avoid these risks.
Risk management involves identifying and assessing
major project risks to establish the probability that
they will occur and the consequences for the project
if that risk arise.
Types of Risk
Product Risk: Product risks are the risks that
influence the quality attributes as well as performance
of software being developed. Example: failure of
purchase component to perform as expected
Project Risk: Project risks are the risks that influences
the schedule of software project and that if occur delay
the development process. Example: staff turnover,
hardware unavailability etc.
Business Risk: Business risk is a risk that affects the
organization business that is developing or procuring the
software. it could be anything that has the potential of
threatening the generation of profits at the predetermined
target levels. Business risks could be quite dangerous for
the long-term sustainability of the business. Example:
Technology change, Product completion etc.
Risk Management Process
Risk Identification
 Risk identification involves brainstorming activities. it is the first stage
of the risk management.
 It concerned with discovering possible risk to the project and may be
carried out as a team process using past experience. It also involves
preparation of risk list. Brainstorming is a group discussion technique
where all the stakeholders meet together. This technique produces new
ideas and promotes creative thinking.
 To help the process, a checklist of different types of risks may be
prepared. Preparation of risk list involves identification of risks that is
occurring continuously in previous software projects. There are mainly
six types of risk that can arise in project.
 Technology Risk: The risk that derive from the software or hardware
technology that are used to develop a system.
 People Risks: The risk that are associated with the people in the
development term are people risks.
 Organizational risks: Risks that derive from the organizational
environment where the software being development.
 Tool Risks: Risks that derive from the CASE tools and other support
software used to develop the system.
 Requirement Risks: Risks that derive from the change to the customer
requirement and the process of managing the requirement change.
Risk Analysis: in this phase all identified risks
are considered and make a judgment about
problems causing risk in the project, identify
probability of occurrence of risk and the impact
of the risk.
The probability of risks may be accessed as
very low (<10%), low(10-25%), moderate(26-
50%), high(51-75%) and very high(>75%).
Risks are tabulated in order according to the
seriousness of the risk.
Risk Planning
 Risk planning is the process of consideration of the key risks that
have been identified and formulation of strategies to manage the
risk. It is not a simple process; it depends on the judgment and
experience of the project manager. the strategies to manage the
risk are as follows:
1. Avoidance Strategies: This strategy tells that the probability
that the risk will arise will be reduced. Example: The strategy for
dealing with defective components.
2. Minimization Strategies: These strategies mean that the
impact of the risk will be reduced.
 Example: Staff illness, Reorganize team so that there is more
overlap of work and people therefore understand each other's job.
3. Contingency Plans: These strategies means that you are
prepared for the worst and have a strategy in place to deal with it.
Risk Monitoring
 Risk monitoring means regularly assessing each of the identified
risk to decide whether or not the risk is becoming more or less
portable and whether the effect of the risk have changed.
 It should be a continuous process, and used at every management
progress review.
Project Scheduling
Project scheduling is concerned with the
techniques that can be employed to manage the
activities that need to be undertaken during the
development of a project.
Project scheduling is the process of spate the
total work involve in project into separate
activities and estimating the time and resources
required to complete activities and organize
them into a coherent sequence.
It is one of the most difficult job for a project
manager, manager estimate the time and
resources required.
scheduling separates the total work involved in
a project into separate activities and organize
Scheduling Principles
Compartmentalization: Define distinct tasks or
project is divided in to distinct activities.
Interdependency: Parallel and sequential tasks are
identified to know the interdependency between
activities.
Time allocation: Assign resources, days, start time
and end time to each activities of project
Effort validation : Be sure all the required resources
to build the project are available
Defined responsibilities: Roles and responsibilities
of each personnel is defined.
Defined outcome : Each task must have an outcome.
Milestones from each activities are clearly defined
Scheduling Process

Identifiy Identify Est. Resource Allocatepeep Create

activities [Link] for to Activities project Chart
Activities

Software Activities
Req. Chartbar Chart
Activity Network and Bar chart
Project schedules are usually represented as a set of
chars and network diagram showing the work
breakdown activities dependencies and staff
allocations and time allocations. Bar charts and
activity network are graphical notations that are
used to illustrate the project schedule.
Bar chart shows the schedule against the calendar.
i.e. it shows who is responsible for each activity and
when the activity is scheduled to being and end.
But "Activity network show the dependencies
between the different activity making up a project
and critical path. Bar charts and activity charts can
be generate automatically from a database of project
information using a project management tool.
 Software Cost Estimation
While developing a software project, the project is split
in to a number of separate activities. So cost estimation
concerned with estimates of effort and time with the
project activities.
It is the process of predicting the effort required to
develop a software system.
Many estimation models have been proposed over the
years.
The cost estimation is usually dependent upon the size
estimate of the project, which may use lines of code or
function points as metrics.
Cost estimation is usually measured in terms of effort.
The most common metric used is person months or years
(or man months or years). The effort is the amount of
time for one person to work for a certain period of time.
Estimation is done to answer the following questions:
 How much effort is required complete an activity?
 How much calendar time is needed to complete each
activity?
 What is the total cost of an activity?
 Since the cost of development is primarily the cost of the
effort.
There are three parameters involves in computing the total
cost of a software development.
 Hardware and software cost including maintenance.
 Travel and training cost
 Effort cost i.e. the cost of paying software engineers.
The effort cost is calculated by calculating following:
 The cost of providing heating and lighting office space.
 Cost of support staffs.
 Cost of networking and communications
 Cost of social security and employee benefits.
Software Pricing Factors
The major factors that affect the software pricing are as
follows:
Development organization quotes a low price if want to
move into a new segment of software market.
Accepting low profit in one project may give the
opportunity of more profit later.
If an organization has no idea about cost estimation
then it may increase its price by some contingency.
It the customer is not clear about their requirement
then there is chance of changing requirement at that
time organization may lower its price. After contract is
awarded then high prices may be charged for changes
to the requirement.
If the financial health of the organization is not good
then they may lower their price to gain contract and
establish themselves in business.
 Cost Estimation Techniques
Algorithmic Cost Modeling: The algorithmic method is
designed to provide some mathematical equations to
perform software estimation. These mathematical
equations are based on research and historical data and
use inputs such as Lines of Code (LOC), number of
functions to perform, and other cost drivers such as
language, design methodology, skill-levels, risk
assessments, etc
Algorithmic cost model can be built by analyzing the cost
and attributes of similar projects by using an empirical
formula
Effort = A x SizeB x M, where
A: depends on organizational practice and type of software
that is developed
B: 1-1.5 reflects disproportionate effort for large projects
M: reflects product, process and people attributes
Size: size may be assessment of code size expressed in
function or object points.
 COCOMO Model
 The Constructive Cost Model (COCOMO) is an algorithmic
software cost estimation model developed by Barry Boehm in
1981.
 This model is an empirical model derived by collecting data from a
large number of software projects, then analyzing that data to
discover formulae.
 The model uses a basic regression formula, with parameters that
are derived from historical project data and current project
characteristics.
 The first model of COCOMO model known as COCOMO 81
assumes that the software would be developed using waterfall
model and from scratch level.
 There have been radical changes in software development
practice. Software can be created by using reusable components
and linking them by scripting language.
 Existing software reengineering to create new software, CASE
tools are used to generate source code automatically from the
design, prototyping and incremental development are heavily in
practice. To take these changes in account COCOMO 2 model is
introduced.
In COCOMO, projects are categorized into three types:
 Organic: A development project can be treated of the organic
type, if the project deals with developing a well-understood
application program, the size of the development team is
reasonably small, and the team members are experienced in
developing similar methods of projects. Examples of this type of
projects are simple business systems, simple inventory
management systems, and data processing systems.
 Moderate: A development project can be treated with moderate
type if the development consists of a mixture of experienced and
inexperienced staff. Team members may have finite experience in
related systems but may be unfamiliar with some aspects of the
order being developed. Example of moderate (Semidetached)
system includes developing a new operating system (OS), a
Database Management System (DBMS), and complex inventory
management system.
 Embedded: A development project is treated to be of an
embedded type, if the software being developed is strongly
coupled to complex hardware, or if the stringent regulations on
the operational method exist. For Example: ATM, Air Traffic
control.
For the three classes of software products, the
formulas for estimating the effort based on the
code size are shown below:
Organic: Effort = 2.4(KLOC) 1.05 PM
Semi-detached: Effort = 3.0(KLOC) 1.12 PM
Embedded: Effort = 3.6(KLOC) 1.20 PM
For the three classes of software products, the
formulas for estimating the development time
based on the effort are given below:
Organic: Tdev = 2.5(Effort) 0.38 Months
Semi-detached: Tdev = 2.5(Effort) 0.35 Months
Embedded: Tdev = 2.5(Effort) 0.32 Months
The Basic COCOMO
It is the one type of static model to estimates software
development effort quickly and roughly. It mainly deals
with the number of lines of code and the level of estimation
accuracy is less as we don’t consider the all parameters
belongs to the project. The estimated effort and scheduled
time for the project are given by the relation:
Effort (E) = a*(KLOC)b PM
Scheduled Time (D) = c*(E)d Months(M)
Where,
E = Total effort required for the project in Man-Months
(MM).
D = Total time required for project development in Months
(M).
KLOC = the size of the code for the project in Kilo lines of
code.
a, b, c, d = The constant parameters for a software
project.
 COCOMO 2
This model incorporates a range of sub-models that produce increasingly
detailed software cost estimates. The sub-models in COCOMO 2 are:
 Application composition model: It is used when software is
composed from existing parts. Supports prototyping projects and
projects where there is extensive reuse based on standard
estimates of developer productivity in application (object)
points/month. It Takes CASE tool use into account. The formula is:
PM = NOP/PROD = (Object Points x (1 - %reuse/100)) / PROD
Where, PM is the effort in person-months
NOP is the new object points
PROD is the productivity.
 Early design model: This model is used when requirements are
available but design has not yet started. In this model, Estimates
can be made after the requirements have been agreed. The
empirical formula used to calculate person month is:
PM=ASizeBM
Where, M= PERSRCPXRUSEPDIFPREXFCILSCED
A= 2.94 in initial calibration
Size in KLOC
B varies from 1.1 to 1.24 depending on novelty of the project, development
flexibility, risk management approaches and the process maturity.
  Reuse oriented Model: This model is used to compute the
effort of integrating reusable components. Major effort is
required to integrate automatically generated code. The
empirical formula is:
PMAuto = (ASLOC x (AT/100)) / ATPROD
Where, ASLOC – No. LOC that have to be adapted
AT - % of adapted code that is automatically generated
ATPROD – engineer productivity in adapting code (2400
LOC/month)
 Post-architecture model. This model is used once the
system architecture has been designed and more
information about the system is available. In this model we
uses same formula as early design estimates: PM = A x
SizeB x M )
Where, Size estimate for the software should be more
accurate at this stage. It takes into consideration the
factors like: New code to be developed, rework required
to support change and extent of possible reuse.
 2. Expert Judgment: Expert judgment techniques involve
consulting with software cost estimation expert or a group of
the experts to use their experience and understanding of the
proposed project to arrive at an estimate of its cost. The
estimating steps using this method are:
Coordinator presents each expert with a specification
and an estimation form.
Coordinator calls a group meeting in which the experts
discuss estimation issues with the coordinator and each
other.
Experts fill out forms anonymously
Coordinator prepares and distributes a summary of the
estimation on an iteration form.
Coordinator calls a group meeting, specially focusing on
having the experts discuss points where their estimates
varied widely.
Experts fill out forms, again anonymously, and steps 4
and 6 are iterated for as many rounds as appropriate.
  Estimation by Analogy: Estimating by analogy means comparing the
proposed project to previously completed similar project where the
project development information is known. Actual data from the
completed projects are extrapolated to estimate the proposed project.
This method can be used either at system-level or at the component-
level. Estimating by analogy is relatively straightforward. Actually in
some respects, it is a systematic form of expert judgment since
experts often search for analogous situations so as to inform their
opinion.
The steps using estimating by analogy are:
 Characterizing the proposed project.
 Selecting the most similar completed projects whose characteristics have
been stored in the historical data base.
 Deriving the estimate for the proposed project from the most similar
completed projects by analogy.
 Parkinson’s Law: Parkinson’s Law states that work
expands to fill the time available. In this method, the cost is
determined by available resources rather than by objective
assessment.
 Pricing to Win: In this method, the software cost is
estimated to be whatever the customer has available to
spend on the project. The estimated effort depends on
customer’s budget not on the software functionality.