UNIT-3

Project Management Concepts

3. 1 Management Activities:
Software Project Management consists of many activities, that includes planning of the
project, deciding the scope of product, estimation of cost in different terms,
scheduling of tasks, etc.
The list of activities are as follows:
1. Project planning and Tracking
2. Project Resource Management

3. Scope Management
4. Estimation Management

5. Project Risk Management

6. Scheduling Management

7. Project Communication Management

8. Configuration Management

Now we will discuss all these activities -

1. Project Planning: It is a set of multiple processes, or we can say that it is a task that
is performed before the construction of the product starts.
2. Scope Management: It describes the scope of the project. Scope management is
important because it clearly defines what would do and what would not. Scope
Management creates the project to contain restricted and quantitative tasks, which
may merely be documented and successively avoids price and time overrun.
3. Estimation management: This is not only about cost estimation because whenever
we start to develop software, we also figure out their size(line of code), efforts, time as
well as cost.
If we talk about the size, then the Line of code depends upon user or software
requirements.
If we talk about effort, we should know about the size of the software, because based
on the size we can quickly estimate how big a team is required to produce the
software.
If we talk about time, when size and efforts are estimated, the time required to
develop the software can easily determine.
And if we talk about cost, it includes all the elements such as:
o Size of software

o Quality

o Hardware

o Communication

o Training

o Additional Software and tools

o Skilled manpower

4. Scheduling Management: Scheduling Management in software refers to all the

activities to complete in the specified order and within the time slot for each activity .
Project managers define multiple tasks and arrange them keeping various factors in
mind.
For scheduling, it is compulsory -
o Find out multiple tasks and correlate them.

o Divide time into units.

o Assign the respective number of work units for every job.

o Calculate the total time from start to finish.

o Break down the project into modules.

5. Project Resource Management: In Software Development, all the elements are

referred to as resources for the project. It can be a human resource, productive tools,
and libraries.
Resource management includes:
o Create a project team and assign responsibilities to every team member

o Developing a resource plan is derived from the project plan.

o Adjustment of resources.
6. Project Risk Management: Risk management consists of all the activities like
identification, analyzing and preparing the plan for predictable and unpredictable risk
in the project.
Several points show the risks in the project:
o The Experienced team leaves the project, and the new team joins it.

o Changes in requirement.

o Change in technologies and the environment.

o Market competition.

7. Project Communication Management: Communication is an essential factor in the

success of the project. It is a bridge between client, organization, team members and
as well as other stakeholders of the project such as hardware suppliers.
From planning to closure, communication plays a vital role. In all the phases,
communication must be clear and understood. Miscommunication can create a big
blunder in the project.
8. Project Configuration Management: Configuration management is about to
control the changes in software like requirements, design, and development of the
product.
The Primary goal is to increase productivity with fewer errors.
Some reasons show the need for configuration management:
o Several people work on software that is continually updated.

o Help to build coordination among suppliers.

o Changes in requirements, budget, and schedule need to accommodate.

o Software should run on multiple systems.

Tasks perform in Configuration management:

o Identification

o Baseline

o Change Control

o Configuration Status Accounting

o Configuration Audits and Reviews

People involved in Configuration Management:

3.2 Software Project Planning
A Software Project is the complete methodology of programming advancement from
requirement gathering to testing and support, completed by the execution
procedures, in a specified period to achieve the intended software product.

Need of Software Project Management

Software development is a sort of all-new stream in world business, and there's next to
no involvement in structure programming items. Most programming items are
customized to accommodate customers’ necessities. The most significant is that the
underlying technology changes and advances so generally and rapidly that experience
of one element may not be connected to the other one. All such business and
environmental requirements bring risk to software development; hence, it is
fundamental to manage software projects efficiently.

Software Project Manager

The software manager is responsible for planning and scheduling project
development. They manage the work to ensure that it is completed to the required
standard. They monitor the progress to check that the event is on time and within
budget. The project planning must incorporate major issues like size & cost estimation
scheduling, project monitoring, personnel selection evaluation & risk management. To
plan a successful software project, we must understand:
o Scope of work to be completed

o Risk analysis

o The resources mandatory

o The project to be accomplished

o Record of being followed

Software Project planning starts before technical work start. The various steps of

planning activities are:

The size is the crucial parameter for the estimation of other activities. Resources
requirement are required based on cost and development time. Project schedule
may prove to be very useful for controlling and monitoring the progress of the project.
This is dependent on resources & development time.

3.3 Project Scheduling

Project-task scheduling is a significant project-planning activity. It comprises deciding
which functions would be taken up and when. To schedule the project plan, a
software project manager wants to do the following:
1. Identify all the functions required to complete the project.
2. Break down large functions into small activities.
 3. Determine the dependency among various activities.
4. Establish the most likely size for the time duration required to complete the activities.

5. Allocate resources to activities.

6. Plan the beginning and ending dates for different activities.

7. Determine the critical path. A critical way is the group of activities that decide the
duration of the project.

The first method in scheduling a software plan involves identifying all the functions
required to complete the project. A good judgment of the details of the project and
the development process helps the supervisor to identify the critical role of the project
effectively. Next, the large functions are broken down into a valid set of small activities
which would be assigned to various engineers. The work breakdown structure
formalism supports the manager to break down the function systematically after the
project manager has broken down the purpose and constructs the work breakdown
structure; he has to find the dependency among the activities. Dependency among the
various activities determines the order in which the various events would be carried
out. If activity A necessary for the results of another activity B, then activity A must be
scheduled after activity B. In general, the function dependencies describe a partial
ordering among functions, i.e., each service may lead a subset of other functions, but
some functions might not have any precedence ordering describe between them
(called concurrent function). The dependency among the activities is defined in the
pattern of an activity network.
Once the activity network representation has been processed out, resources are
allocated to every activity. Resource allocation is usually done using a Gantt chart.
After resource allocation is completed, a PERT chart representation is developed. The
PERT chart representation is useful for program monitoring and control. For task
scheduling, the project plan needs to decompose the project functions into a set of
activities. The time frame when every activity is to be performed is to be determined.
The end of every action is called a milestone. The project manager tracks the function
of a project by audit the timely completion of the milestones. If he examines that the
milestones start getting delayed, then he has to handle the activities carefully so that
the complete deadline can still be met.

3.4 Risk analysis and Risk Management

Different methods are required to address these two kinds of issues.
For example, staff storage, because we have not been able to select people with the
right technical skills is a current problem, but the threat of our technical persons being
hired away by the competition is a risk.

Risk Management
A software project can be concerned with a large variety of risks. In order to be adept
to systematically identifying the significant risks which might affect a software project,
it is essential to classify risks into different classes. The project manager can then check
which risks from each class are relevant to the project.
There are three main classifications of risks which can affect a software project:
1. Project risks
2. Technical risks
3. Business risks
1. Project risks: Project risks concern different forms of budgetary, schedule,
personnel, resource, and customer-related problems. A vital project risk is schedule
slippage. Since the software is intangible, it is very tough to monitor and control a
software project. It is very tough to control something which cannot be identified. For
any manufacturing program, such as the manufacturing of cars, the plan executive can
recognize the product taking shape.
2. Technical risks: Technical risks concern potential methods, implementation,
interfacing, testing, and maintenance issues. It also consists of an ambiguous
specification, incomplete specification, changing specification, technical uncertainty,
and technical uselessness. Most technical risks appear due to the development team's
insufficient knowledge of the project.
3. Business risks: This type of risks contain risks of building an excellent product that
no one need, losing budgetary or personnel commitments, etc.
Other risk categories

1. 1. Known risks: Those risks that can be uncovered after careful assessment of

the project program, the business and technical environment in which the plan
is being developed, and more reliable data sources (e.g., unrealistic delivery
date)
2. 2. Predictable risks: Those risks that are hypothesized from previous project
experience (e.g., past turnover)
3. 3. Unpredictable risks: Those risks that can and do occur, but are extremely
tough to identify in advance.

Principle of Risk Management

1. Global Perspective: In this, we review the bigger system description, design,

and implementation. We look at the chance and the impact the risk is going to
have.
2. Take a forward-looking view: Consider the threat which may appear in the
future and create future plans for directing the next events.
3. Open Communication: This is to allow the free flow of communications
between the client and the team members so that they have certainty about the
risks.
4. Integrated management: In this method risk management is made an integral
part of project management.
5. Continuous process: In this phase, the risks are tracked continuously
throughout the risk management paradigm.

Why Risk Management is Important

 There are absolutely no disadvantages to risk management if you have the correct
strategy.
The benefits of a successful risk management strategy include:
 Prevention of Losses
 Decreased degree of losses.
 Resources are utilized more effectively to combat risk.
 Reduced number of reactive situations.
 Reassures stakeholders, partners, and clients that their data, investments, etc is
safeguarded.
 Identify and promptly grasp (gain a good understanding of) new opportunities.
 Promote continuous improvement.

What is Proactive Strategy?

Proactive risk management is a concept that aims to reduce the chances of any
accident or malicious attack occurring in the future by identifying each business’
situation or process to determine potential threats.

Enabling a proactive approach also involves correctly identifying drivers of risks to

grasp the key issue along with assessing the likelihood and impact in order to
prioritize risks.
The proactive approach is an “Adaptive, closed-loop feedback control strategy based on
measurement, observation of the present safety level and planned explicit target safety
level with a creative intellectuality”

It is creative thought for those looking to protect their organization’s valuables and is
currently the most common method of risk management strategy because of its
effectiveness.
Why choose a Proactive Strategy?

The ‘prevention is better than the cure’ is true with regard to a proactive strategy, and
this can apply to an entire host of occupations that possess a risk management plan.

You’d argue that fire prevention is much preferable to actual firefighting. This also
applies to businesses, where retailers (etc) can safeguard their valuables from threats
online by utilizing a proactive risk management method, rather than managing the
threat.

What is Reactive Strategy?

A Reactive risk strategy is a response-based approach, which is solely dependent on

past incident evaluation and audit-based findings. It begins once an ‘incident’ occurs,
or once problems have been detected following an audit.

The incident is investigated, and measures are implemented to avoid similar events
from attacking the business in the future.

Why choose a Reactive Strategy?

“A response-based risk management approach, which is dependent on accident

evaluation and audit-based findings.”

It saves company time that is poured into the research and analysis of risk mitigation
and forces a company’s hand to adapt in certain situations, which can be risky.
Reactive concepts also save a lot of time and energy that a proactive approach would
take. It is also argued that, a situation that a proactive strategy has not prepared for
may arise, in which case the strategy is rendered surplus to requirements.

Proactive vs. Reactive: Which Strategy is Best?

Regardless of your business model, a proactive risk mitigation approach is customarily

the defence method of choice when it comes to security.

A proactive risk strategy generally consists of focusing efforts on justifying the risk of
pre-emptive threat occurrences.

This involves devising plans to protect critical assets via educating the business about
the who, what, where, why, and how threats can potentially expose their valuable,
sensitive assets.

By summarizing each asset, businesses can also easily prioritize, plan and tackle
incidents accordingly should they threaten to compromise their assets.

A Reactive risk management strategy possesses the inability to efficiently manage or

eliminate threats

3.5 Software Metrics and Measurement

What are Software Metrics in Software Engineering?

Software metrics in software engineering are the standards for estimating the quality,
progress, and health of software development activity. A software metric is a quantifiable
or countable assessment of the qualities of software.

A software metric is a measure of software characteristics that are measurable or

countable.

Software metrics are valuable for many reasons, including measuring software
performance, planning work items, measuring productivity, and many other uses.

Characteristics of Software Metrics:

Software metrics in software engineering should possess the following characteristics:

 Quantitative: Metrics must be quantitative in order to be helpful. It means that

metrics can be stated numerically.
 Understandable: Metric computation should be simple to grasp, and the method
for computing them should be well explained.
 Applicability: Metrics should be applied during the early stages of software
development.
 Repeatable: When measured regularly and consistently in nature, the metric
values should be the same.
 Economical: Metric computation should be cost-effective.
 Language agnostic: Metrics should be language-independent, meaning their
computation should not depend on any programming language.

Classification of Software Metrics: 

There are 3 types of software metrics:  
 1. Product Metrics: Product metrics are used to evaluate the state of
the product, tracing risks and undercover potential problem areas.
The ability of the team to control quality is evaluated.
2. Process Metrics: Process metrics pay particular attention to
enhancing the long-term process of the team or organization.
3. Project Metrics: The project matrix describes the project
characteristic and execution process:
 Number of software developer
 Staffing patterns over the life cycle of software
 Cost and schedule
 Productivity

Advantages of Software Metrics :

1. Reduction in cost or budget.
2. It helps to identify the particular area for improvising.
3. It helps to increase product quality.
4. Managing the workloads and teams.
5. Reduction in overall time to produce the product.
6. It helps to determine the complexity of the code and to test the code
with resources.
7. It helps in providing effective planning, controlling, and managing of
the entire product.

Disadvantages of Software Metrics :

1. It is expensive and difficult to implement the metrics in some cases.
2. Performance of the entire team or an individual from the team can’t
be determined. Only the performance of the product is determined.
3. Sometimes the quality of the product is not met with the expectation.
4. It leads to measure unwanted data which is waste of time.
5. Measuring the incorrect data leads to make wrong decision-making.
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 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, the date on which it

was identified, description and so on should be clearly mentioned.

Risk projection:
Risk projection, also called risk estimation, attempts to rate each risk in two ways—the
likelihood or probability that the risk is real and the consequences of the problems
associated with the risk, should it occur.
The project planner, along with other managers and technical staff, performs four risk
projection activities:
(1) Establish a scale that reflects the perceived likelihood of a risk.
(2) Describe the consequences of the risk.
(3) Estimate the impact of the risk on the project and the product.
(4) Note the overall accuracy of the risk projection so that there will be no
misunderstandings.
Developing a Risk Table:
Risk table provides a project manager with a simple technique for risk projection.
Steps in Setting up Risk Table
(1) Project team begins by listing all risks in the first column of the table.
Accomplished with the help of the risk item checklists.
(2) Each risk is categorized in the second column.
(e.g. PS implies a project size risk, BU implies a business risk).
(3) The probability of occurrence of each risk is entered in the next (third) column of the
table.
The probability value for each risk can be estimated by team members individually.
(4) Individual team members are polled in round-robin fashion until their assessment of risk
probability begins to converge.
Assessing Risk Impact:
Nature of the risk - the problems that are likely if it occurs.
e.g. a poorly defined external interface to customer hardware (a technical risk) will preclude
early design and testing and will likely lead to system integration problems late in a project.
Scope of a risk - combines the severity with its overall distribution (how much of the
project will be affected or how many customers are harmed?).
Timing of a risk - when and how long the impact will be felt.
Overall risk exposure, RE, determined using:

RE = P x C

P is the probability of occurrence for a risk.

C is the the cost to the project should the risk occur.

Risk refinement: During the early stages of project planning, a risk may be
stated quite generally. As time passes and more is learned about the project and the risk, it may be
possible to refine the risk into a set of more detailed risks.
One way to do this is to represent the risk in condition-transition-consequence (CTC) format . That
is, the risk is stated in the following form:
Given that <condition> then there is concern that (possibly) <consequence>.
=============
Given that all reusable software components must conform to specific design standards and that
some do not conform, then there is concern that (possibly) only 70 percent of the planned reusable
modules may actually be integrated into the as-built system, resulting in the need to custom
engineer the remaining 30 percent of components.

This general condition can be refined in the following manner:

Subcondition 1. Certain reusable components were developed by a third party with no knowledge
of internal design standards.

Subcondition 2. The design standard for component interfaces has not been tough and may not
conform to certain existing reusable components.

Subcondition 3. Certain reusable components have been implemented in a language that is not
supported on the target environment.

The consequences associated with these refined subconditions remains the same ( i.e., 30 percent of
software components must be customer engineered), but the refinement helps to isolate the
underlying risks and might lead to easier analysis and response.
Risk mitigation:
Risk mitigation simply means to reduce adverse effects and impact of risks
that are harmful to project and Business continuity. It includes introducing
measures and step taken into a project plan to mitigate, reduce, eliminate, or
control risk. Risk mitigation means preventing risks to occur (risk avoidance). 
Following are measures and steps to be taken for mitigating risks: 
 
 Communicate with concerned staff to find probable risks.
 Identify and eliminate all those causes and issues that can create
risk before the beginning of project work.
 Develop policy in an organization that will help to continue the project
even though some staff leaves the organization.
 Everybody in the project team should be acquainted i.e. should be
aware of and familiar with current development activity.
 Maintain corresponding documents in a timely manner. This
documentation should be strictly followed as per standards set by the
organization.
 Conduct timely reviews in order to speed up work.
 For conducting every critical activity during software development,
provide additional staff is required.

Risk monitoring:
As the project proceeds, risk monitoring activities commence. The project
manager monitors factors that may provide an indication of whether the risk is
becoming more or less likely.
In the case of high staff turnover, the following factors can be monitored:
 General attitude of team members based on project pressures.
 Interpersonal relationships among team members.
 Potential problems with compensation and benefits.
 The availability of jobs within the company and outside it.