CHAPTER-2

Software Project
Management

1
Introduction
• Software project is complete procedure of software development from
requirement gathering to testing and maintenance
• Software project management is the discipline of planning and leading
software projects
• To achieve targets by optimizing the use of resources (time, money, people,
materials, energy, space, etc.) over the course of a project (a set of
activities of finite duration)

2
2.1. Project Management Activities
• Software project management comprise a number of
activities like
• Planning of project
• Deciding scope of software product
• Estimation of cost
• Scheduling
• Resource management
• Reporting progress
• Analyzing the results based on the facts achieved

3
Cont….
• Software project management is an umbrella activity within software
engineering.
• It begins before any technical activity is initiated and
• It continues throughout the definition, development, and support of
computer software.

4
Four P’s:
• Effective software project management focuses on the four P’s:
• People, Product, Process, and Project.
• The manager who forgets that software engineering work will never
have success in project management.
• The manager who get on without a solid project plan endangers the
success of the product.

5
A. The People
• The people management maturity model defines the following
key practice areas for software people:
• Recruiting
• Selection
• Performance management,
• Training
• Career development,
• Team work culture development.

6
Cont..
• Organizations that achieve high levels of maturity in the people
management area have a higher likelihood of implementing effective
software engineering practices.
• Software project is populated by stakeholders who can be categorized
into one of five constituencies
1. Senior managers
Define the business issues that often have a significant influence on the
project.
2. Project (technical) managers
Must plan, motivate, organize, and control the practitioners who do
software work. 7
Cont..
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

8
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 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
9
Software Scope
• Scope is defined by answering the following questions:
I. 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?
II. Information objectives.
• What data objects are required for input?
• What data objects are produced as output from the software?

10
Cont..
III. Function and performance.
• What function does the software perform to transform input data into
output?
• Are any special performance characteristics to be addressed?
• N.B. Software project scope must be unambiguous and
understandable at the management and technical levels

11
Problem Decomposition
• Problem decomposition, sometimes called partitioning or problem
elaboration,
• During the scoping activity no attempt is made to fully decompose the
problem.
• Decomposition is applied in two major areas:
• The functionality and content (information) that must be delivered and
• The process that will be used to deliver it.

12
Cont..
• 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.

13
C. The Process
• A software process provides the framework from which a
comprehensive plan for software development can be established.
• The problem is to select the process model that is appropriate for the
software to be engineered by your project team.
• Your team must decide which process model is most appropriate for
• The customers who have requested the product and the people who will do the
work.
• The characteristics of the product itself
• The project environment in which the software team works.
• When a process model has been selected, the team then defines a
preliminary project plan based on the set of process framework
activities. 14
Cont.…
• A relatively small project that is similar to past efforts might be best
accomplished using the linear sequential approach.
• If the deadline is so tight that full functionality cannot reasonably be
delivered, an incremental strategy might be best.
• Similarly, projects with other characteristics (e.g., uncertain
requirements, breakthrough technology, difficult customers,) will lead
to the selection of other process models

15
D. The Project
• In order to manage a successful software project, we must
understand what can go wrong and how to do it right.
• To avoid project failure, a software project manager and the software
engineers who build the product must
• Avoid a set of common warning signs,
• Understand the critical success factors that lead to good project management
• Develop a common sense approach for planning, monitoring, and controlling
the project

16
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

17
Tasks for Project Planning
Tasks in project planning are
• Establish project scope.
• Determine feasibility.
• Analyze risks
• Define required resources.
• Estimate cost and effort.
• Decompose the problem

18
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 performance, constraints, interfaces, and reliability that bound the
system.
• Functions described in the statement of scope 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

19
Cont. ….
• Performance considerations include 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, it is reasonable to ask: “Can we build
software to meet this scope? or Is the project feasible?”

20
Cont…
• A feasibility study is an assessment of the practicality of a proposed
project or system.
• It aims to objectively and rationally uncover the strengths and
weaknesses of an existing business or proposed venture,
opportunities and threats present in the natural environment, the
resources required to carry through, and ultimately the prospects for
success.
• Mainly the two criteria to judge feasibility are cost required and value
to be attained.

21
RESOURCES
• The next planning task is estimation of the resources required to
accomplish the software development effort.
• The three major categories of software engineering resources are
• People (Human)
• Reusable software components,
• The development environment (hardware and software tools).

22
Cont.….
• Each resource is specified with four characteristics:
• Description of the resource,
• 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.

23
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.
• The number of people required for a software project can be
determined only after an estimate of development effort (e.g., 3
person-months, 2person-days) is made.

24
Cont…..
• For relatively small projects (a few person-days), 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.

25
Reusable Software Resources
• 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.
• Four software resource categories
• Off-the-shelf components (COTS (commercial off-the-shelf))
• Usually provided by a commercial vendor or open source software (OSS).
• COTS products are designed to be easily installed and to interoperate with
existing system components
• Such a component usually has been used in many other systems, and
should have fewer defects, or have had more bugs shaken out of it
26
Cont…
• Full-experience components
• Existing specifications, designs, code, or test data developed for past
projects that are similar to the software to be built for the current project
• Partial-experience components
• Existing specifications, designs, code, or test data developed for past
projects that are related to the software to be built for the current project
but will require substantial modification
• new components
• Components built by the software team specifically for the needs of the
current project

27
Environmental Resources
• The environment that supports a software project, often called the
software engineering environment (SEE),
• It incorporates hardware and software.
• Hardware provides a platform that supports the tools
• Software required to produce the work products
• You must prescribe the time window required for hardware and
software and verify that these resources will be available.

28
Fig. Categories of software engineering resources 29
2.3. Project Scheduling
• After
• Selecting an appropriate process model,
• Identifying the software engineering tasks that have to be
performed,
• Estimating the amount of work and the number of people,
• Knowing the deadline, even considering the risks.
• Now it’s time to connect the dots.
• That is to create a network of software engineering tasks that
will enable you to get the job done on time.
30
Cont.. .
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.
Underestimate of the amount of effort and/or the number of
resources that will be required to do the job.

31
Cont…
Predictable and/or unpredictable risks that were not considered
when the project began.
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

32
Basic Principles in project scheduling
Some of basic principles guide software project scheduling are
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 activity or task must be determined.
• Some tasks must occur in sequence, while others can occur in parallel.
• Some activities cannot begin until the work product produced by another is available.
• Other activities can occur independently.

33
Cont….
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
• 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.
• Ensure that no more than the allocated number of people has been
scheduled at any given time.
34
Cont….
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.
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.
35
Project Scheduling Tools
• The objective of project scheduling tools is to enable a project
manager to define work tasks;
• Establish their dependencies;
• Assign human resources to tasks;
• Develop a variety of graphs, charts, and tables that aid in tracking and
control of the software project.

36
Cont….
• 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 or network is defined,
• Start and end dates,
• Human resources,
• Hard deadlines, and
• Other data may attached to each.
• Example of scheduling tools are Microsoft Project, Basecamp, Freedcamp etc.
• 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.
37
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.
38
39
Cont. ….
• The above 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.

40
Project table

41
2.4. 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 that can
• 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
42
Cont. ….
• Risk analysis and management are a series of steps that help a
software team understand and manage uncertainty.
• 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 manage it.

43
Steps for risk management
• First Recognizing what can go wrong 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.

44
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 essential areas.
• It is important to conduct few brainstorming sessions to identify the
existence of project risk.
• Any decision taken related to technical, operational, political, legal,
social, internal or external factors should be evaluated properly.
45
Software Risk Analysis
• After the categorization/identification 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:
• Complexity of the technology
• Technical knowledge possessed by the testing team
• Conflicts within the team
• Teams being distributed over a large geographical area

46
Consequences of a risk
• It is important to know about the impact because it is
necessary to know how a business can get affected:
• What will be the loss to the customer?
• How would the business suffer?
• Loss of reputation or harm to society
• Monetary losses
• Legal actions against the company
• Cancellation of business license

47
Software Risk Planning
Software risk planning is all about:
• Defining preventive measure that would lower down the likelihood or
probability of various risks.
• Define measures that would reduce the impact in case a risk happens.
• Constant monitoring of processes to identify risks as early as possible.

48
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

49