Software Engineering

Unit – V

Software Project Management

Dr. S. Manikandan
HOD-IT

1
 1. Software Configuration Management

• When we develop software, the product (software)

undergoes many changes in their maintenance phase; we
need to handle these changes effectively.
• The elements that comprise all information produced as a
part of the software process are collectively called a
software configuration.
• SCM is a art of identifying, organizing, and controlling
modifications to software being built by a programming team
• The goal is to maximize productivity by minimizing mistakes

2
• Software configuration management (SCM) is the
discipline for systematically controlling the changes
that take place during development.
• Software configuration management is a process
independent of the development process largely
because most development models cannot
accommodate change at any time during development.
• SCM can be considered as having three major
components:
– Software configuration identification
– Configuration control
– Status accounting and auditing

3
Software configuration identification

• The first requirement for any change management is to

have clearly agreed-on basis for change.
• That is, when a change is done, it should be clear to
what changes has been applied.
• This requires baselines to be established.
• A baseline change is the changing of the established
baseline, which is controlled by SCM.

4
Configuration Control

• Most of the decisions regarding the change are

generally taken by the configuration control board
(CCB), which is a group of people responsible for
configuration management, headed by the
configuration manager.
• For smaller projects, the CCB might consist of just
one person.
• A change is initiated by a change request.

5
Status accounting and auditing

• Configuration status accounting is the keeping

process of each release .
• The procedure involves tracking what all is in each
version of software and the changes that lead to this
version
• It keeps a record of all the changes made to the
previous baseline to reach of the new baseline.

6
Why do we need Configuration management?

The primary reasons for Implementing Technical

Software Configuration Management System are:
• There are multiple people working on software which is
continually updating
• It may be a case where multiple version, branches,
authors are involved in a software config project, and
the team is geographically distributed and works
concurrently
• Changes in user requirement, policy, budget, schedule
need to be accommodated.
• Software should able to run on various machines and
Operating Systems
• Helps to develop coordination among stakeholders
7
 SCM Process

• It uses the tools which keep that the necessary

change has been implemented adequately to the
appropriate component. The SCM process defines a
number of tasks:
• Identification of objects in the software configuration
• Version Control
• Change Control
• Configuration Audit
• Status Reporting

8
i) Identification
• Basic Object: Unit of Text created by a software
engineer during analysis, design, code, or test.
• Aggregate Object: A collection of essential objects
and other aggregate objects. Design Specification is
an aggregate object.
• Each object has a set of distinct characteristics that
identify it uniquely: a name, a description, a list of
resources, and a "realization."

9
ii) Version Control
• Version Control combines procedures and tools to
handle different version of configuration objects that
are generated during the software process.
• Clemm defines version control in the context of
SCM: Configuration management allows a user to
specify the alternative configuration of the software
system through the selection of appropriate versions.
This is supported by associating attributes with each
software version, and then allowing a configuration to
be specified [and constructed] by describing the set of
desired attributes.

10
iii) Change Control
• Change control implies the authority to approve
and rank the changes. It combines the automated
tool with human to provide a mechanism for control
of change.
• Any changes or alteration done to a single document
often implies changes to other documents as well.
• Change request is evaluated to assess the technical
aspect of configuration items and the budget.

11
12
iv) Configuration Audit
• SCM audits to verify that the software product
satisfies the baselines requirements and ensures that
what is built and what is delivered.
• SCM audits also ensure that traceability is
maintained between all CIs and that all work
requests are associated with one or more CI
modification.
• SCM audits are the "watchdogs" that ensures that
the integrity of the project's scope is preserved.

13
v) Status Reporting
• Configuration Status reporting (sometimes also
called status accounting) providing accurate status
and current configuration data to developers, testers,
end users, customers and stakeholders through
admin guides, user guides, FAQs, Release Notes,
Installation Guide, Configuration Guide, etc.

14
 Configuration Management for Web apps

i) Domain Issues
Four issues should be considered when developing
tactics for Web App configuration management
1. Content
A typical web app contains a vast array of content –
text, graphics, scripts, audio/video files, tables,
streaming data and many others
The challenge is to organize this set of content into
a rational set of configuration objects and then
establish appropriate configuration control
mechanism for these objects.

15
2. People
Any person involved in the WebApp can create content
Many content creators have no software engineering
background and are completely unaware of the need
for configuration management.
3. Scalability
The techniques and controls applied to a small Web
App do not scale upward well.

16
4. Politics
Who “owns” a Web App?
Who assumes responsibility for the accuracy of the
information on the website?
Who assumes the cost of change?
Who is responsible for making changes?

17
ii) Configuration Objects
Web App encompass a broad range of configuration
objects – content objects

18
 Software Cost Estimation
For any new software project, it is necessary to know how much it
will cost to develop and how much development time will it take.
These estimates are needed before development is initiated, but
how is this done? Several estimation procedures have been
developed and are having the following attributes in common.
• Project scope must be established in advanced.
• Software metrics are used as a support from which evaluation is
made.
• The project is broken into small PCs which are estimated
individually.
• To achieve true cost & schedule estimate, several option arise.
• Delay estimation
• Used symbol decomposition techniques to generate project cost
and schedule estimates.
• Acquire one or more automated estimation tools.
19
Uses of Cost Estimation

• During the planning stage, one needs to choose how

many engineers are required for the project and to
develop a schedule.
• In monitoring the project's progress, one needs to
access whether the project is progressing according
to the procedure and takes corrective action, if
necessary.

20
 Cost Estimation Models

There is multiple SCE method/model in terms of size or

type of project or in static nature with dependent factors
(single parameter or multi parameters). Such as:

•COCOMO or Algorithmic Model

•Wideband Delphi or expert Judgment Model
•Static Single Variable Model
•Static Multi-Variable Model
•Estimation by Past Project Model

21
1.COCOMO or Algorithmic Model
• It is called the Constructive Cost Model, which
is mainly used for software cost estimation
• i.e. it estimates/predicts the effort required for
the project, total project cost and scheduled
time for the project.
• This model depends on the number of lines of
code for software product development. It also
estimates the required number of Man-Months
(MM) for the full development of software
products.
22
2. Wideband Delphi or Expert Judgment
Model
• It is one type of software cost estimation
model prepared by the highly
qualified/experienced manager/estimator
based on the previous project estimation
report.
• So the model name shows as Expert
Judgement Model.
23
3. Static Single Variable Model
• This model is used to estimate the effort, cost and
development time for a software project which depends
on a single variable. The relationship is given by:
• Cost (C) = a*(LOC)b
• Effort (E) = a*(LOC)b MM
• Development Time (DT) = a*(LOC)b Months
• Where LOC = Number of Lines of Code.

PARAMETERS a b
Effort 1.4 0.93
Dev. Duration 4.2 0.26 24
4. Static Multi-Variable Model
• This model is used to estimate the effort, cost and
development time for a software project with depends
on multiple internal or external variables I .e.Effort
Adjustment Factor (cost driver factors). The
relationship is given by:
• Cost (C) = a*(LOC)b
• Effort (E) = a*(LOC)b MM
• Development Time (DT) = a*(LOC)b Months
• Where LOC = Number of Lines of Code.
PARAMETERS a b

Effort 5.2 0.91

Dev. Duration 4.1 0.36

25
5. Estimation by Past Project Model
• The software cost estimation is done for
the new project by comparing the
previous completed project estimation.
Here the estimation cost should be
reconsidered. Sometimes we manipulate
estimation to win the Contract of project.

26
 Risk Management

"Tomorrow problems are today's risk." Hence, a clear

definition of a "risk" is a problem that could cause
some loss or threaten the progress of the project, but
which has not happened yet.
Risk Management is the system of identifying
addressing and eliminating these problems before they
can damage the project.
There are three main classifications of risks which can
affect a software project:
• Project risks
• Technical risks
• Business risks
27
28
 Risk Assessment

• The objective of risk assessment is to division the risks

in the condition of their loss, causing potential. For risk
assessment, first, every risk should be rated in two
methods:
• The possibility of a risk coming true (denoted as r).
• The consequence of the issues relates to that risk
(denoted as s).
• Based on these two methods, the priority of each risk
can be estimated:
• p=r*s

29
 Risk Identification

• Risk Identification: The project organizer needs to anticipate the

risk in the project as early as possible so that the impact of risk
can be reduced by making effective risk management planning.
There are different types of risks which can affect a software project:
• Technology risks: Risks that assume from the software or
hardware technologies that are used to develop the system.
• People risks: Risks that are connected with the person in the
development team.
• Organizational risks: Risks that assume from the organizational
environment where the software is being developed.
• Tools risks: Risks that assume from the software tools and other
support software used to create the system.
• Requirement risks: Risks that assume from the changes to the
customer requirement and the process of managing the
requirements change.
• Estimation risks: Risks that assume from the management
estimates of the resources required to build the system 30
 Risk Analysis

• Risk Analysis: During the risk analysis process, you have to

consider every identified risk and make a perception of the
probability and seriousness of that risk.
• There is no simple way to do this. You have to rely on your
perception and experience of previous projects and the
problems that arise in them.
• It is not possible to make an exact, the numerical estimate of
the probability and seriousness of each risk. Instead, you
should authorize the risk to one of several bands:
• The probability of the risk might be determined as very low
(0-10%), low (10-25%), moderate (25-50%), high (50-75%)
or very high (+75%).

31
 Risk Control

There are three main methods to plan for risk

management:
• Avoid the risk: This may take several ways such as
discussing with the client to change the requirements
to decrease the scope of the work, giving incentives to
the engineers to avoid the risk of human resources
turnover, etc.
• Transfer the risk: This method involves getting the
risky element developed by a third party, buying
insurance cover, etc.
• Risk reduction: This means planning method to
include the loss due to risk. For instance, if there is a
risk that some key personnel might leave, new
recruitment can be planned.
32
 Risk Control

1. Risk planning: The risk planning method considers

each of the key risks that have been identified and
develop ways to maintain these risks.
For each of the risks, you have to think of the behavior
that you may take to minimize the disruption to the plan
if the issue identified in the risk occurs.

2. Risk Monitoring: Risk monitoring is the method king

that your assumption about the product, process, and
business risks has not changed.

33
34
35
36
37
38
 Software Maintenance

• Software maintenance is widely accepted part

of SDLC now a days. It stands for all the
modifications and updations done after the
delivery of software product.

39
 Types of Maintenance

• Corrective Maintenance - This includes modifications

and updations done in order to correct or fix problems,
which are either discovered by user or concluded by
user error reports.
• Adaptive Maintenance - This includes modifications
and updations applied to keep the software product up-
to date and tuned to the ever changing world of
technology and business environment.

40
• Perfective Maintenance - This includes modifications
and updates done in order to keep the software usable
over long period of time. It includes new features, new
user requirements for refining the software and improve
its reliability and performance.
• Preventive Maintenance - This includes modifications
and updations to prevent future problems of the
software. It aims to attend problems, which are not
significant at this moment but may cause serious
issues in future.

41
 Software Re-engineering

• Software Re-engineering is a process of software

development which is done to improve the maintainability
of a software system.
• Re-engineering is the examination and alteration of a
system to reconstitute it in a new form.
• This process encompasses a combination of sub-
processes like reverse engineering, forward engineering,
reconstructing etc.

42
Steps involved in Software Re-engineering
Process Model

43
Re-Engineering Process
• Decide what to re-engineer. Is it whole software or a
part of it?
• Perform Reverse Engineering, in order to obtain
specifications of existing software.
• Restructure Program if required. For example,
changing function-oriented programs into object-
oriented programs.
• Re-structure data as required.
• Apply Forward engineering concepts in order to get
re-engineered software.

44
Forward Engineering Reverse Engineering

In forward engineering, the application is developed In reverse engineering or

with the given requirements. backward engineering, the
information are collected from
the given application.

Forward Engineering is a high proficiency skill. Reverse Engineering or

backward engineering is a low
proficiency skill.
Forward Engineering takes more time to develop an While Reverse Engineering or
application. backward engineering takes less
time to develop an application.

In forward engineering, production is started with given In reverse engineering,

requirements. production is started by taking
the existing products.
The example of forward engineering is the construction An example of backward 45
The example of forward engineering is the construction An example of backward
of electronic kit, construction of DC MOTOR , etc. engineering is research on
Instruments etc.

46