Software project management (spm)

Software project management is an essential part of the

software engineering
The main goal of software project management is to develop a
quality software with in given budget (‫ )بودجه‬and schedule
constraints.
Good management cannot guarantee project success. However
bad management usually results in project failure. The software
maybe delivered late. cost than originally estimated or fail to
meet the expectations of customers.
Project Goals
The success criteria for project management obviously vary
from project to project but, important goals for all engineering
projects are as follows:
1) To deliver the software to the customer at the agreed time
2) To keep overall costs within budget
3) To deliver software that meets the customer’s expectations
4) To maintain a clear and well-functioning development team
These goals are not unique to software engineering but are the
goals of all engineering projects. However, software
engineering is different from other types of engineering in a
number of ways that make software management particularly
challenging.  Some of these differences are as follows:
1) The product is intangible
2) Large software projects are often “one-off” projects
3) Software processes are variable and organization-specific
The Product is Intangible
A manager of a civil engineering project can see the product
being developed. Software is intangible. It means the software
cannot be seen or touched.
Software project managers cannot see progress by looking at
the artifact that is being constructed.
Large Software Projects are Often “One-off” Projects
Every large software development project is unique because
every environment where software is developed is, in some
ways, different from all others.
Even managers who have a large body of previous experience
may find it difficult to anticipate problems.

Software Process are Variable and Organization Specific

The engineering process for some types of systems, such as
bridges and buildings, is well understood. However, different
companies use quite different software development
processes. We cannot reliably predict when a particular
software process is likely to lead to development problems.
 Project Factors
Some of the most important factors that affect how software
projects are managed are as follows:
1) Company size
2) Software customers
3) Software development processes
4) Organizational culture
5) Software type
6) Software size
Company Size
Small companies can operate with informal management and
team communications and do not need formal policies and
management structures. They have less management overhead
than larger organizations.
In larger organizations, management hierarchies, formal
reporting and budgeting, and approval processes must be
followed.
Software Customers
If the customer is an internal customer, then customer
communications can be informal and there is no need to fit in
with the customer’s ways of working.
 If custom software is being developed for an external
customer, agreement has to be reached on more formal
communication channels.
If the customer is a government agency, the software company
must operate according to the agency’s policies and
procedures.
Software Size
Small systems can be developed by a small team, which can get
together in the same room to discuss progress and other
management issues.
Large systems usually need multiple development teams that
may be geographically distributed and in different companies.
In large projects, the project manager has to coordinate the
activities of these teams and make arrangements for them to
communicate with each other.
Software Type
If the software being developed is a customer product, formal
records of project management decisions are unnecessary.
On the other hand, if a safety-critical system is being
developed, all project management decisions should be
recorded and justified as these may affect the safety of the
system.
Organizational Culture
Some organizations have a culture that is based on supporting
and encouraging individuals, while others are group focused.
Small organization are not usually official and formal whereas
large organizations are often official. Some organizations have a
culture of taking risks, whereas others are risk averse.
Software Development Processes
A difficult decision that takes time for the project manager is to
choose the right method for the project because there are
many methodologies for different software development.
If the project requirements are well understood and are not
changing, they will use traditional waterfall methodology.
Otherwise, they will use agile software development
methodology.
Project Management Activities
Project factors mean that project managers in different
organizations may work in quite different ways. It is impossible
to write a standard job description for a software project
manager. The job varies tremendously depending on the
organization and the software being developed.
However, a number of fundamental project management
activities are common to all organizations:
1) Project planning
2) Risk management
3) People management
4) Reporting
5) Proposal writing
Project Planning
Project managers are responsible for planning, estimating, and
scheduling project development as well as assigning people to
tasks.
They supervise the work to ensure that it is carried out to the
required standards, and they monitor progress to check that
the development is on time and within budget.

Risk Management
Project managers have to assess the risks that may affect a
project, monitor these risks, and take action when problems
arise.
You have to anticipate risks, understand their impact on the
project, the product, and the business, and take steps to avoid
these risks.
People Management
People management is also one of the important activities of
project management. Project managers are responsible for
managing a team of people.
They have to choose people for their team and establish ways
of working that lead to effective team performance.
Reporting
Project managers are usually responsible for reporting on the
progress of a project to customers and to the managers of the
company developing the software.
They have to be able to communicate at a range of levels, from
detailed technical information to management summaries.
Proposal Writing
The first stage in a software project may involve writing a
proposal to win a contract to carry out an item of work. The
proposal describes the objectives of the project and how it will
be carried out.
It usually includes cost and schedule estimates and justifies
why the project contract should be awarded to a particular
organization or team.
Chapter@2
Risk Management
Risk management is one of the most important jobs for a project manager. You
can think of a risk as something that you would prefer not to have happen.
Risks may threaten the project, the software that is being developed, or the
organization.
Risk management involves anticipating risks that might affect the project
schedule or the quality of the software being developed, and then taking action to
avoid these risks.
For large projects, you should record the results of the risk analysis in a risk
register along with a consequence analysis. This sets out the consequences of the
risk for the project, product, and business.
For small projects, formal risk recording may not be required, but the project
manager should be aware of them.
Effective risk management makes it easier to cope with problems and to ensure
that these do not lead to unacceptable budget or schedule problems.
Risks Classification
In software project management, risks are classified into three categories based
on their effects which are as follows:
1) Project risks
2) Product risks
3) Business risks

Project Risks
Project risks affect the project schedule or resources.
An example of a project risk is the loss of an experienced system architect.
Finding a replacement architect with appropriate skills and experience may take a
long time; consequently, it will take longer to develop the software design than
originally planned. Finally, losing a team member can also be a business risk
because an experienced engineer’s reputation may be a critical factor in winning
new contracts.
Product Risks
Product risks affect the quality or performance of the software being developed.
An example of a product risk is the failure of a purchased component to perform
as expected. This may affect the overall performance of the system so that it is
slower than expected.
Business Risks
Business risks affect the organization developing or buying the software. For example, a
competitor introducing a new product is a business risk.
The introduction of a competitive product may mean that the assumptions made about sales of
existing software products may be improperly optimistic.
Examples of Risks
Processes of Risk Management
The process of risk management involves four stages such as Risk Identification,
Risk Analysis, Risk Planning, and Risk Monitoring.
Risk identification You should identify possible project, product, and business
risks.
Risk analysis You should assess the probability and consequences of these risks.
Risk planning You should make plans to address the risk, either by avoiding it or
by minimizing its effects on the project.
Risk monitoring You should regularly assess the risk and your plans for risk
moderation and study these plans when you learn more about the risk.

Risk Identification
Risk identification is the first stage of the risk management process. It is
concerned with identifying the risks that could have a major threat to the
software engineering process, the software being developed, or the development
organization.
Risk identification may be a team process in which a team gets together to
brainstorm possible risks. Alternatively, project managers may identify risks based
on their experience of what went wrong on previous projects.
As a starting point for risk identification, a checklist of different types of risk may
be used.
There are six types of risk in a risk checklist which are as follows:
1) Estimation risks
2) Organizational risks
3) People risks
4) Requirements risks
5) Technology risks
6) Tools risks
Estimation risks arise from the management estimates of the resources required
to build the system. Organizational risks arise from the organizational
environment where the software is being developed. People risks are associated
with the people in the development team.
Requirements risks come from changes to the customer requirements and the
process of managing the requirements change
Technology risks come from the software or hardware technologies that are used
to develop the system.
Tools risks come from the software tools and other support software used to
develop the system.

Examples of Different Types of Risks

Risk type Possible risks
1. The time required to develop the software is underestimated.
Estimation 2. The rate of defect repair is underestimated.
3. The size of the software is underestimated

Organizational 1.The organization is restructured so that different management are

 responsible for the project.
2. Organizational financial problems force reductions in the project
budget. People

People 1. It is impossible to recruit staff with the skills required.

2. Key staff are ill and unavailable at critical times.
3. Required training for staff is not available. Requirements

Requirements 1. Changes to requirements that require major design rework are

proposed.
2. Customers fail to understand the impact of requirements changes.
Technology

Technology 1. The database used in the system cannot process as many transactions
per second as expected.
2. Faults in reusable software components have to be repaired before
these components are reused. Tools

Tools 1. The code generated by software code generation tools is inefficient.

2. Software tools cannot work together in an integrated way.

Risk Analysis
During the risk analysis process, you have to consider each identified risk and
make a judgment about the probability and seriousness of that risk.
There is no easy way to do so. You have to rely on your judgment and experience
of previous projects and the problems that arose in them.
It is not possible to make precise, numeric assessment of the probability and
seriousness of each risk. Every risk will have the probability and effects which are
discussed as following:
1) The probability of the risk might be assessed as insignificant, low, moderate,
high, or very high.
2) The effects of the risk might be assessed as catastrophic (threaten the survival
of the project), serious (would cause major delays), tolerable (delays are within
allowed contingency), or insignificant.
You may then tabulate the results of risk analysis process using a table ordered
according to the seriousness of the risk.
Of course, both the probability and the assessment of the effects of a risk may
change as more information about the risk becomes available and as risk
management plans are implemented.
You should therefore update this table during each iteration of the risk
management process.
Risk Types and Examples
Risk Probabilities Effects
Organizational financial Low Catastrophic
problems force
reductions in the project
d
budget It is impossible High Catastrophic
to recruit staff with the
skills require
Key staff are ill at critical Moderate Serious
times in the project
Moderate Serious
Faults in reusable Moderate Serious
software components
have to be repaired
before these
components are reused
Changes to requirements Moderate Serious
that require major
design rework are
proposed
The organization is High Serious
restructured so that
different managements
are responsible for the
project
The database used in the Moderate Serious
system cannot process as
many transactions per
second as expected
The time required to High Serious
develop the software is
underestimated
Software tools cannot be High Tolerable
integrated
Customers fail to Moderate Tolerable
understand the impact of
requirements changes
Required training for Moderate Tolerable
staff is not available
The rate of defect repair Moderate Tolerable
is underestimated
The size of the software High Tolerable
is underestimated
Code generated by code Moderate Insignificant
generation tools is
inefficient
 Risk planning
The risk planning process develops strategies to manage the key risks that
threaten the project.
For each risk, you have to think of actions that you might take to minimize the
interruption to the project if the problem identified in the risk occurs.
In risk planning, you have to ask “what-if” questions that consider both individual
risks, combinations of risks, and external factors that affect these risks
“What-if” Questions
What if several engineers are ill at the same time?  What if the customer fails to
deliver the revised requirements as predicted?
What if the company that supplies and maintains software components goes out
of business?
What if an economic downturn leads to budget cuts of 20% for the project?
What if the performance of open-source software is inadequate and the only
expert on that open-source software leaves?
Avoidance strategies

Based on the answers to these “what-if” questions, you may devise strategies for
managing the risks.
These strategies fall into the following three categories:
1) Avoidance strategies
2) Minimization strategies
3) Contingency plans
Avoidance strategies: Following these strategies means that the probability that
the risk will arise is reduced.
Minimization strategies: Following these strategies means that the impact of the
risk is reduced.  Contingency plans: Following these strategies means that you
are prepared for the worst and have a strategy in place to deal with it.
Risk Monitoring
Risk monitoring is the process of checking that your expectations about the
product, process, and business risks have not changed.
You should regularly assess each of the identified risks to decide whether or not
that risk is becoming more or less probable.
You should also think about whether or not the effects of the risk have changed.