2.1.

THE MANAGEMENT SPECTRUM

Software project management is an umbrella activity within software engineering. It begins

before any technical activity is initiated and continues throughout the definition, development,
and support of computer software.

Effective software project management focuses on the four P’s: people, product, process, and
project. The manager who forgets that software engineering work is an intensely human
endeavor will never have success in project management. A manager who fails to encourage
comprehensive customer communication early in the evolution of a project risks building an
elegant solution for the wrong problem. The manager who pays little attention to the process runs
the risk of inserting competent technical methods and tools into a vacuum. The manager who
embarks without a solid project plan jeopardizes the success of the product.

A. The People: - The people management maturity model defines the following key practice
areas for software people: recruiting, selection, performance management, training,
compensation, career development, organization and work design, and team/culture
development. Organizations that achieve high levels of maturity in the people management area
have a higher likelihood of implementing effective software engineering practices.
The software process (and every software project) is populated by stakeholders who can be
categorized into one of five constituencies:
1. Senior managers who define the business issues that often have a significant influence
on the project.
2. Project (technical) managers who must plan, motivate, organize, and control the
practitioners who do software work.
3. Practitioners who deliver the technical skills that are necessary to engineer a product or
application.
4. Customers who specify the requirements for the software to be engineered and other
stakeholders who have a peripheral interest in the outcome.
5. End users who interact with the software once it is released for production use

B. The Product: - Before a project can be planned, product objectives and scope should be
established, alternative solutions should be considered, and technical and management
constraints should be identified. Without this information, it is impossible to define reasonable
(and accurate) estimates of the cost, an effective assessment of risk, a realistic breakdown of
project tasks, or a manageable project schedule that provides a meaningful indication of
progress
The first software project management activity is the determination of software scope. Scope is
defined by answering the following questions:

Software Scope
 Context. How does the software to be built fit into a larger system, product, or business
context, and what constraints are imposed as a result of the context?
Information objectives. What customer-visible data objects are produced as output from
the software? What data objects are required for input?
Function and performance. What function does the software perform to transform input
data into output? Are any special performance characteristics to be addressed?
Software project scope must be unambiguous and understandable at the management and
technical levels

Problem Decomposition

Problem decomposition, sometimes called partitioning or problem elaboration, is an activity

that sits at the core of software requirements analysis. During the scoping activity no attempt is
made to fully decompose the problem. Rather, decomposition is applied in two major areas: (1)
the functionality and content (information) that must be delivered and (2) the process that will
be used to deliver it.
Human beings tend to apply a divide-and-conquer strategy when they are confronted with a
complex problem. Stated simply, a complex problem is partitioned into smaller problems that
are more manageable. This is the strategy that applies as project planning begins. Software
functions, described in the statement of scope, are evaluated and refined to provide more detail
prior to the beginning of estimation. Because both cost and schedule estimates are functionally
oriented, some degree of decomposition is often useful.
C. The Process: - A software process provides the framework from which a comprehensive
plan for software development can be established. A small number of framework activities are
applicable to all software projects, regardless of their size or complexity. A number of different
task sets—tasks, milestones, work products, and quality assurance points—enable the
framework activities to be adapted to the characteristics of the software project and the
requirements of the project team. Finally, umbrella activities—such as software quality
assurance, software configuration management, and measurement—overlay the process model.
Umbrella activities are independent of any one framework activity and occur throughout the
process.
D. The Project: - In order to manage a successful software project, we must understand what
can go wrong (so that problems can be avoided) and how to do it right.

2.2. Project Planning:

Software project management begins with a set of activities that are collectively called project
planning. Before the project can begin, the software team should estimate the work to be done,
the resources that will be required, and the time that will elapse from start to finish. Once these
activities are accomplished, the software team should establish a project schedule that defines
software engineering tasks and milestones, identifies who is responsible for conducting each
task, and specifies the inter-task dependencies that may have a strong bearing on progress.
Task Set for Project Planning

1. Establish project scope.

2. Determine feasibility.

3. Analyze risks (Chapter 35).

4. Define required resources.

a. Determine required human resources.

b. Define reusable software resources.

c. Identify environmental resources.

5. Estimate cost and effort.

a. Decompose the problem

SOFTWARE SCOPE AND FEASIBILITY

Software scope describes the functions and features that are to be delivered to end users; the data
that are input and output; the “content” that is presented to users as a consequence of using the
software; and the performance, constraints, interfaces, and reliability that bound the system.

Functions described in the statement of scope (or within the use cases) are evaluated and in some
cases refined to provide more detail prior to the beginning of estimation. Because both cost and
schedule estimates are functionally oriented, some degree of decomposition is often useful.
Performance considerations encompass processing and response time requirements. Constraints
identify limits placed on the software by external hardware, available memory, or other existing
systems.

Once scope has been identified (with the concurrence of the customer), it is reasonable to ask:
“Can we build software to meet this scope? Is the project feasible?” All too often, software
engineers rush past these questions (or are pushed past them by impatient managers or other
stakeholders), only to become mired in a project that is doomed from the onset

RESOURCES

The second planning task is estimation of the resources required to accomplish the software
development effort. Figure below depicts the three major categories of software engineering
resources—people, reusable software components, and the development environment (hardware
and software tools). Each resource is specified with four characteristics: description of the
resource, a statement of availability, time when the resource will be required, and duration of
time that the resource will be applied. The last two characteristics can be viewed as a time
window. Availability of the resource for a specified window must be established at the earliest
practical time.

A. Human Resources

The planner begins by evaluating software scope and selecting the skills required to complete
development. Both organizational position (e.g., manager, senior software engineer) and
specialty (e.g., telecommunications, database, client-server) are specified. For relatively small
projects (a few person-months), a single individual may perform all software engineering tasks,
consulting with specialists as required. For larger projects, the software team may be
geographically dispersed across a number of different locations. Hence, the location of each
human resource is specified.

The number of people required for a software project can be determined only after an estimate of
development effort (e.g., person-months) is made.

B. Reusable Software Resources

Component-based software engineering (CBSE) emphasizes reusability that is, the creation and
reuse of software building blocks. Such building blocks, often called components, must be
cataloged for easy reference, standardized for easy application, and validated for easy
integration.
 C. Environmental Resources

The environment that supports a software project, often called the software engineering
environment (SEE), incorporates hardware and software. Hardware provides a platform that
supports the tools (software) required to produce the work products that are an outcome of good
software engineering practice.5 Because most software organizations have multiple
constituencies that require access to the SEE, you must prescribe the time window required for
hardware and software and verify that these resources will be available.

2.3. Project Scheduling

You’ve selected an appropriate process model, you’ve identified the software engineering tasks
that have to be performed, you estimated the amount of work and the number of people, you
know the deadline, you’ve even considered the risks. Now it’s time to connect the dots. That is,
you have to create a network of software engineering tasks that will enable you 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 become reality. In a nutshell, that’s software
project scheduling and tracking.

Although there are many reasons why software is delivered late, most can be traced to one or
more of the following root causes:

 An unrealistic deadline established by someone outside the software team and forced on
managers and practitioners on the group.
 Changing customer requirements that are not reflected in schedule changes.
 An honest underestimate of the amount of effort and/or the number of resources that will be
required to do the job.
 Predictable and/or unpredictable risks that were not considered when the project commenced.
 Technical difficulties that could not have been foreseen in advance.
 Human difficulties that could not have been foreseen in advance.
 Miscommunication among project staff that results in delays.
 A failure by project management to recognize that the project is falling behind schedule and
a lack of action to correct the problem
Basic Principles

Like all 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, while others can occur in parallel. Some
activities cannot commence until the work product produced by another is available. Other
activities can occur independently.
Time allocation. Each task to be scheduled must be allocated some number of work units (e.g.,
person-days of effort). 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.
Effort validation. Every project has a defined number of people on the software team. As time
allocation occurs, you must ensure that no more than the allocated number of people has been
scheduled at any given time.
Defined responsibilities. Every task that is scheduled should be assigned to a specific team
member.
Defined outcomes. Every task that is scheduled should have a defined outcome. For software
projects, the outcome is normally a work product (e.g., the design of a component) or a part of a
work product. Work products are often combined in deliverables.
Defined milestones. Every task or group of tasks 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.

Project Scheduling

The objective of project scheduling tools is to enable a project manager to define work tasks;
establish their dependencies; assign human resources to tasks; and develop a variety of graphs,
charts, and tables that aid in tracking and control of the software project.

In general, project scheduling tools require the specification of a work breakdown structure of
tasks or the generation of a task network. Once the task breakdown (an outline) or network is
defined, start and end dates, human resources, hard deadlines, and other data are attached to
each. The tool then generates a variety of time-line charts and other tables that enable a manager
to assess the task flow of a project. These data can be updated continually as the project is under
way.

Time-Line Charts

When creating a software project schedule, you begin with a set of tasks (the work breakdown
structure). If automated tools are used, the work breakdown is input as a task network or task
outline. Effort, duration, and start date are then input for each task. In addition, tasks may be
assigned to specific individuals.
As a consequence of this input, a time-line chart, also called a Gantt chart, is generated. A time-
line chart can be developed for the entire project. Alternatively, separate charts can be developed
for each project function or for each individual working on the project.

The following Figure illustrates the format of a time-line chart. It depicts a part of a software
project schedule that emphasizes the concept scoping task for a word-processing (WP) software
product. All project tasks (for concept scoping) are listed in the left-hand column. The horizontal
bars indicate the duration of each task. When multiple bars occur at the same time on the
calendar, task concurrency is implied. The diamonds indicate milestones.

Figure An example time-line chart

Figure An example project table

Risk Management

Risk analysis and management are a series of steps that help a software team understand and
manage uncertainty. Many problems can plague a software project. A risk is a potential problem
it might happen, it might not. But, regardless of the outcome, it’s a really good idea to identify it,
assess its probability of occurrence, estimate its impact, and establish a contingency plan should
the problem actually occur.

What are the steps? Recognizing what can go wrong is the first step, called “risk identification.”
Next, each risk is analyzed to determine the likelihood that it will occur and the damage that it
will do if it does occur. Once this information is established, risks are ranked, by probability and
impact. Finally, a plan is developed to manage those risks that have high probability and high
impact.

What Is Software Risk And

Software Risk Management?
Risk is an expectation of loss, a potential problem that may or may not occur in the future. It
is generally caused due to lack of information, control or time.A possibility of suffering from
loss in software development process is called a software risk. Loss can be anything,
increase in production cost, development of poor quality software, not being able to
complete the project on time. Software risk exists because the future is uncertain and there
are many known and unknown things that cannot be incorporated in the project plan. A
software risk can be of two types (a) internal risks that are within the control of the project
manager and (2) external risks that are beyond the control of project manager. Risk
management is carried out to:

1. Identify the risk

2. Reduce the impact of risk
3. Reduce the probability or likelihood of risk
4. Risk monitoring

A project manager has to deal with risks arising from three possible cases:

1. Known knowns are software risks that are actually facts known to the team as well
as to the entire project. For example not having enough number of developers can
delay the project delivery. Such risks are described and included in the Project
Management Plan.
2. Known unknowns are risks that the project team is aware of but it is unknown that
such risk exists in the project or not. For example if the communication with the client
is not of good level then it is not possible to capture the requirement properly. This is
a fact known to the project team however whether the client has communicated all
the information properly or not is unknown to the project.
3. Unknown Unknowns are those kind of risks about which the organization has no
idea. Such risks are generally related to technology such as working with
technologies or tools that you have no idea about because your client wants you to
work that way suddenly exposes you to absolutely unknown unknown risks.

Software risk management is all about risk quantification of risk. This includes:

1. Giving a precise description of risk event that can occur in the project
2. Defining risk probability that would explain what are the chances for that risk to occur
3. Defining How much loss a particular risk can cause
4. Defining the liability potential of risk

Risk Management comprises of following processes:

1. Software Risk Identification

2. Software Risk Analysis
3. Software Risk Planning
4. Software Risk Monitoring

These Processes are defined below.

Software Risk Identification

In order to identify the risks that your project may be subjected to, it is important to first
study the problems faced by previous projects. Study the project plan properly and check
for all the possible areas that are vulnerable to some or the other type of risks. The best
ways of analyzing a project plan is by converting it to a flowchart and examine all
essentialareas. It is important to conduct few brainstorming sessions to identify the known
unknowns that can affect the project. Any decision taken related to technical, operational,
political, legal, social, internal or external factors should be evaluated properly.
 Software Risk Identification

In this phase of Risk management you have to define processes that are important for risk
identification. All the details of the risk such as unique Id, date on which it was identified,
description and so on should be clearly mentioned.
Software Risk Analysis
Software Risk analysisis a very important aspect of risk management. In this phase the risk
is identified and then categorized. After the categorization of risk, the level, likelihood
(percentage) and impact of the risk is analyzed. Likelihood is defined in percentage after
examining what are the chances of risk to occur due to various technical conditions. These
technical conditions can be:

1. Complexity of the technology

2. Technical knowledge possessed by the testing team
3. Conflicts within the team
4. Teams being distributed over a large geographical area
5. Usage of poor quality testing tools

With impact we mean the consequence of a risk in case it happens. It is important to know
about the impact because it is necessary to know how a business can get affected:

1. What will be the loss to the customer

2. How would the business suffer
3. Loss of reputation or harm to society
4. Monetary losses
5. Legal actions against the company
6. Cancellation of business license
Level of risk is identified with the help of:
Qualitative Risk Analysis: Here you define risk as:

 High
 Low
 Medium

Quantitative Risk Analysis: can be used for software risk analysis but is considered
inappropriate because risk level is defined in % which does not give a very clear picture.

Software Risk Planning

Software risk planning is all about:

1. Defining preventive measure that would lower down the likelihood or probability of
various risks.
2. Define measures that would reduce the impact in case a risk happens.
3. Constant monitoring of processes to identify risks as early as possible.

Software Risk Planning

Software Risk Monitoring

Software risk monitoring is integrated into project activities and regular checks are
conducted on top risks. Software risk monitoring comprises of:

 Tracking of risk plans for any major changes in actual plan, attribute, etc.
 Preparation of status reports for project management.
 Review risks and risks whose impact or likelihood has reached the lowest possible
level should be closed.
 Regularly search for new risks