Noida Institute of Engineering and Technology, Greater

Noida

Software Maintenance and Software Project

Management

Unit: V

Software Engineering Kedar Nath Singh

KCS 601
Assistant Professor
Department of CSE
( B Tech 6th Sem)

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 1

 Content

 Course Objective
 Objective of Topics
 Course Outcomes
 CO-PO Mapping
 CO-PSO Mapping
 Syllabus
 Prerequisite
 Software Maintenance
 Software Project Management
 Categories of Maintenance
 Cost of Maintenance

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 2

 Content

 Software Re- Engineering

 Reverse Engineering
 Software Configuration Management
 An Overview of CASE Tools
 Estimation of cost and effort Parameters
 Video Links
 Daily Quiz
 Weekly Assignment
 MCQ
 Old Question Papers
 Expected Questions for University Exam
 Summary
 References

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 3

 Syllabus
Unit TOPIC
Introduction: Introduction to Software Engineering, Software Components,
Software Characteristics, Software Crisis, Software Engineering Processes,
I Similarity and Differences from Conventional Engineering Processes,
Software Quality Attributes. Software Development Life
Cycle (SDLC) Models: Water Fall Model, Prototype Model, Spiral Model,
Evolutionary Development Models, Iterative Enhancement Models.

Software Requirement Specifications (SRS): Requirement Engineering

Process: Elicitation, Analysis, Documentation, Review and Management of
II User Needs, Feasibility Study, Information Modelling, Data Flow Diagrams,
Entity Relationship Diagrams, Decision Tables, SRS Document, IEEE Standards
for SRS. Software Quality Assurance (SQA): Verification and Validation, SQA
Plans, Software Quality Frameworks, ISO 9000 Models, SEI-CMM Model.

Software Design: Basic Concept of Software Design, Architectural Design,

Low Level Design: Modularization, Design Structure Charts, Pseudo Codes,
Flow Charts, Coupling and Cohesion Measures, Design Strategies: Function
III Oriented Design, Object Oriented Design, Top-Down and Bottom-Up Design.
Software Measurement and Metrics: Various Size Oriented Measures:
Halestead’s Software Science, Function Point (FP) Based Measures,
Cyclomatic Complexity Measures: Control Flow Graphs.
22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit II 4
 Syllabus

Unit TOPIC
Software Testing: Testing Objectives, Unit Testing, Integration Testing,
Acceptance Testing, Regression Testing, Testing for Functionality and Testing
for Performance, TopDown and BottomUp Testing Strategies: Test Drivers and
IV Test Stubs, Structural Testing (White Box Testing), Functional Testing (Black
Box Testing), Test Data Suit Preparation, Alpha and Beta Testing of Products.
Static Testing Strategies: Formal Technical Reviews (Peer Reviews), Walk
Through, Code Inspection, Compliance with Design and Coding Standards.
Software Maintenance and Software Project management: Software as an
Evolutionary Entity, Need for Maintenance, Categories of Maintenance:
Preventive, Corrective and Perfective Maintenance, Cost of Maintenance,
Software Re- Engineering, Reverse Engineering. Software Configuration
V
Management Activities, Change Control Process, Software Version Control,
An Overview of CASE Tools. Estimation of Various Parameters such as Cost,
Efforts, schedule/Duration, Constructive Cost Models (COCOMO), Resource
Allocation Models, Software Risk Analysis and Management.

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit II 5

 Course Objective(Unit-5)

• The ability to engage in life-long maintenance and continuing Software

development.
• The ability to work in one or more significant application domains.

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 6

 Objective of Topics

TOPIC Objective
Software Maintenance To Understand the need of Software
Maintenance
Software Project Management Study of Software Project Management
Cost of Maintenance To measure the Cost of Maintenance
Software Re- Engineering To understand the Re- Engineering
Reverse Engineering Reverse Engineering

Software Configuration Management To study the Configuration Management

Estimation of cost and effort

Parameters To Find the cost and effort of the software

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 7

 Course Outcome

At the end of the Course, the student will be able

Bloom’s
Course Outcomes (CO) Knowledg
e Level
(KL)

NCS601.1 Explain various software characteristics and analyze different software Development K1, K2
Models.

Demonstrate the contents of a SRS and apply basic software quality assurance
NCS601.2 practices to ensure that design, development meet or exceed applicable standards. K1, K2

NCS601.3 Compare and contrast various methods for software design K2, K3
Formulate testing strategy for software systems, employ techniques such as unit
NCS601.4 K3
testing, Test driven development and functional testing.
Manage software development process independently as well as in teams and make
NCS601.5 use of Various software management tools for development, maintenance and K3
analysis.

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 8

 CO-PO Mapping

CO-PO Correlation Matrices

Correlation levels are taken 1, 2 and 3 as defined below:
1: Slight (Low) 2: Moderate (Medium) 3: Substantial (High)
Software Engineering (Code: KCS-601) Year of Study: 2020-21

CO PO1 PO2 PO3 PO4 PO5 PO6 PO7 PO8 PO9 PO10 PO11 PO12

2 3 3 3  2  - -  -   - -  3 3
C601.1
3 3 3 3 3  - -   - -   - 2 3
C601.2
C601.3 3 2  3 2 2 -  -  -  -  -  3 3

C601.4 2 2 2 2 3 3 -  3 3 -  3 3

C601.5 2 2 3 2 3 3 -  3  - 3 3 3

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 9

 CO-PO and PSO Mapping

Program Specific Outcomes and Course Outcomes Mapping

CO PSO1 PSO2 PSO3 PSO4

CO1 3 3 - 3
CO2 3 3 2 3
CO3 3 3 - 3
CO4 3 3 - 3
CO5 3 3 - 3

*3= High *2= Medium *1=Low

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 10

 Topic mapping with CO

TOPIC CO
Software Maintenance CO5

Software Project Management CO5

Cost of Maintenance CO5

Software Re- Engineering CO5

Reverse Engineering

Software Configuration Management CO5

Estimation of cost and effort Parameters CO5

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 11

 Prerequisite and Recap

• Basic Programming Skills

• Innovative Thinking.
• Enthusiasm to learn Management concepts.

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 12

 Software As An Evolutionary Entity (CO5)

•  Software Maintenance includes error correction, enhancements of

capabilities, deletion of obsolete capabilities & optimization. As
changes cannot be avoided, we should develop mechanism for
evaluating, controlling & making modifications. Hence any work
done to change the s/w after its operation is considered to be a
maintenance work. The term “evolution” has been used with
reference to s/w since 1960’s to signify the growth dynamics of s/w.

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 13

 Software as an Evolutionary Entity

• Software Maintenance is a very broad activity that includes error

corrections, enhancements of capabilities, deletion of obsolete
capabilities, and optimization. As per IEEE, it is a modification of s/w
product after delivery to correct faults, to improve performance or
other attributes or to adapt the product to a modified environment.
As per ISO, it is a set of activities performed when s/w undergoes
modifications to code & associated documentation due to a
problem or the need for improvement or adaptation.

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 14

 Need For Software Maintenance (CO5)

Maintenance is needed for:-

• Correct errors.
• Change in user requirement with time.
• Changing hardware/software environment.
• To improve system efficiency
• To optimize the code to run faster
• To modify the components
• To eliminate any unwanted side effects.
• Thus, the maintenance is needed to ensure that the system
continues to satisfy user requirements.

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 15

 Objective of Software Maintenance

AIM of Software Maintenance

To correct errors
• To enhance the s/w by changing its functions.
• To update the s/w.
• To adapt the s/w to cope with changes in the environment.

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 16

 Categories Of Software Maintenance(co5)

•
There are four types of software maintenance:
 Corrective maintenance: This refer to modifications initiated by
defects in the software.
 Adaptive maintenance: It includes modifying the software to match
changes in the ever changing environment.
 Perfective maintenance: It means improving processing efficiency or
performance, or restructuring the software to improve
changeability. This may include enhancement of existing system
functionality, improvement in computational efficiency etc.

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 17

 Categories Of Software Maintenance

 Preventive maintenance: It is the process by which we prevent our

system from being obsolete. It involves the concept of
reengineering & reverse engineering in which an old system with an
old technology is re-engineered using new technology. This
maintenance prevents the system from dying out.

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 18

 Categories Of Software Maintenance

Problems During Maintenance

• The most important problem during maintenance is that before
correcting or modifying a program, the programmer must first
understand it. Then, the programmer must understand the impact
of the intended change.
• Often the program is written by another person or group of persons
working over the years in isolation from each other.
• Often the program is changed by person who did not understand it
clearly, resulting in a deterioration of the program’s original
organization. Program listing, even those that are well organized,
are not structured to support reading or comprehension.

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 19

 Other types of Maintenance

There are long term effects of corrective, adaptive and

perfective changes. This leads to increase in the complexity of
the software, which reflect deteriorating structure. The work is
required to be done to maintain it or to reduce it, if possible.
This work may be named as preventive maintenance.
% Effort

Perfective(50%)
Adaptive(25%)
Corrective(20%)
Preventive(5%)

Fig: Distribution of maintenance effort

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 20
 Maintenance Process

Program Understanding
–The first phase consists of analyzing the program in order to
understand.

Generating Particular Maintenance Proposal

– The second phase consists of generating a particular maintenance
proposal to accomplish the implementation of the maintenance
objective.

Ripple Effect
– The third phase consists of accounting for all of the ripple effect as a
consequence of program modifications.

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 21

 Maintenance Process

Modified Program Testing

– The fourth phase consists of testing the modified program to
ensure that the modified program has at least the same
reliability level as before.

Maintainability
– Each of these four phases and their associated software quality
attributes are critical to the maintenance process. All of these
factors must be combined to form maintainability.

Kedar Nath Singh KCS 601 Software Engineering Unit V

22/05/2023 22
 Cost of maintenance (CO5)

Estimation of maintenance costs

Phase Ratio

Analysis 1

Design 10

Implementation 100

Defect repair ratio

Kedar Nath Singh KCS 601 Software Engineering Unit V

22/05/2023 23
 Cost of maintenance

Belady and Lehman Model

M = P + Ke (c-d)
where
• M : Total effort expended
• P : Productive effort that involves analysis, design, coding, testing
and evaluation.
• K : An empirically determined constant.
• c : Complexity measure due to lack of good design and
documentation.
• d : Degree to which maintenance team is familiar with the software.

Kedar Nath Singh KCS 601 Software Engineering Unit V

22/05/2023 24
 Cost of maintenance

Boehm Model
Boehm used a quantity called Annual Change Traffic (ACT).
“The fraction of a software product’s source instructions which
undergo change during a year either through addition, deletion or
modification”.

AME = ACT x SDE

Where, SDE : Software development effort in person months
ACT : Annual change Traffic
EAF : Effort Adjustment Factor
AME = ACT * SDE * EAF

Kedar Nath Singh KCS 601 Software Engineering Unit V

22/05/2023 25
 Example

Kedar Nath Singh KCS 601 Software

22/05/2023 26
Engineering Unit V
 Example

Kedar Nath Singh KCS 601 Software

22/05/2023 27
Engineering Unit V
 Example

Kedar Nath Singh KCS 601 Software

22/05/2023 28
Engineering Unit V
 Example

Kedar Nath Singh KCS 601 Software

22/05/2023 29
Engineering Unit V
 Reverse Engineering (CO5)

Reverse engineering is the process followed in order to find difficult,

unknown and hidden information about a software system.

 Mapping between concrete and abstract levels

 Rediscovering high level structures
 Finding missing links between program syntax and semantics
 To extract reusable component

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 30

 Reverse Engineering

Scope and Tasks

The areas there reverse engineering is applicable include (but not
limited to):

1. Program comprehension
2. Re-documentation and/ or document generation
3. Recovery of design approach and design details at any level of
abstraction
4. Identifying reusable components
5. Identifying components that need restructuring
6. Recovering business rules, and
7. Understanding high level system description

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 31

 Reverse Engineering

Reverse Engineering encompasses a wide array of tasks related to

understanding and modifying software system. This array of tasks can
be broken into a number of classes.
• Mapping between application and program domains

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 32

 Reverse Engineering

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 33

 Reverse Engineering

• In it, the old code is analyzed (abstracted) to extract the module

specifications.
• The module specifications are then analyzed to produce the
design.
• The design is analyzed (abstracted) to produce the original
requirements specification.
• The change requests are then applied to this requirements
specification to arrive at the new requirements specification.
• At the design, module specification, and coding a substantial
reuse is made from the reverse engineered products.
•Advantage
• it produces a more structured design compared to what the
original product had,
• It produces good documentation, and very often results in
increased efficiency.

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 34

 RE-Engineering

• Software re-engineering is concerned with taking existing legacy

systems and re-implementing them to make them more
maintainable.
• The critical distinction between re-engineering and new software
development is the starting point for the development as shown in
Fig. in next slide

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 35

 RE-Engineering

It is the combination of
two consecutive
process
1. Forward
Engineering
2. Reverse Engineering

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 36

 Objective of -Engineering

• Prepare functional enhancement.

• Improve maintainability.
• Enhance skills of software developers to incorporate newer technologies.
• Improve reliability.
• Apply integration.

Steps in Re- Engineering

1. Goal setting.
2. Critical analysis of existing scenario such as process, task, design, methods
etc.
3. Identifying the problems and solving them by new innovative thinking.

Kedar Nath Singh KCS 601 Software

22/05/2023 37
Engineering Unit V
 Re-Engineering

Kedar Nath Singh KCS 601 Software

22/05/2023 38
Engineering Unit V
 Re-Engineering

The following suggestions may be useful for the modification of the legacy
code:
 Study code well before attempting changes
 Concentrate on overall control flow and not coding
 Heavily comment internal code
 Create Cross References
 Build Symbol tables
 Use own variables, constants and declarations to localize the effect
 Keep detailed maintenance document
 Use modern design techniques

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 39

 Software Configuration Management (CO5)

Configuration Management
• SCM is used to controlled the process of software development and
software maintenance.

• The configuration management is different in development and

maintenance phases of life cycle due to different environments.

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 40

 Software Configuration Management Activities

The activities are divided into four broad categories.

 The identification of the components and changes

 The control of the way by which the changes are made
 Auditing the changes
 Status accounting recording and documenting all the activities that
have take place

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 41

 Software Configuration Management Activities

The following documents are required for these activities

 Project plan
 Software requirements specification document
 Software design description document
 Source code listing
 Test plans / procedures / test cases
 User manuals

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 42

 Software Configuration Management Activities

Principal Activities of SCM:

1. Configuration identification: which part s of a system should keep
track of.
• Configuration control: ensure change to a system happen smoothly.

• Necessity of SCM
• Inconsistency problem when object is replicated.
• Problems associated with concurrent accesses.
• Providing a stable development environment.
• System accounting and maintaining status.

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 43

 Version Control (CO5)

A version control tool is the first stage towards being able to manage
multiple versions. Once it is in place, a detailed record of every version
of the software must be kept. This comprises the

 Name of each source code component, including the variations and

revisions
 The versions of the various compilers and linkers used
 The name of the software staff who constructed the component
 The date and the time at which it was constructed

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 44

 Change Control Process (CO5)

Change control process comes into effect when the software and
associated documentation are delivered to configuration management
change request form, which should record the recommendations
regarding the change.

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 45

 Change control

• Change control process

– Access control and synchronization control
• Change control
– Before an SCI becomes a baseline
– Once an SCI becomes a baseline
• Role of Change Control Authority (CCA) – Take a global view (big picture)
– How will the change impact h/w?
– How will the change impact performance?
– How will the change modify the customer’s perception of the product?
– How will the change affect the product quality and reliability?

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 46

 Change control

STOP

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering 47

Unit V
 Change Control Process—I

need for change is recognized

change request from user

developer evaluates

change report is generated

change control authority (CCA) decides

request is queued for action, change request is denied,

Engg. Change Order (ECO) user is informed
is generated

change control process—II

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 48
 Change Control Process—II

assign people to SCIs

check-out SCIs

make the change

review/audit the change

establish a “baseline” for testing

change control process—III

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 49

 Change Control Process—III

perform SQA and testing activities

check-in the changed SCIs

promote SCI for inclusion in next release

rebuild appropriate version

review/audit the change

include all changes in release

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 50

 Configuration audit

• How can we ensure that the change has been properly

implemented?
– Formal technical reviews
• Focuses on the technical correctness of the configuration
object that has been modified
– Software configuration audit
• Complements FTR by assessing a configuration object for
characteristics that are generally not considered during
review

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 51

 Configuration audit

Auditing

Change
Requests SQA
Plan
SCIs

SCM Audit

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 52

 Configuration audit

• The audit asks and answers the following questions

– Has the change specified in the ECO been made? Have any
additional modifications been incorporated?
– Has the change been ‘highlighted’ in the SCI? Have the change
date and change author been specified? Do the attributes of the
configuration object reflect the change?
– Have SCM procedures for noting the change, recording it and
reporting it been followed?
– Have all related SCIs been properly updated?

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 53

 Configuration Status Reporting (CSR)

• SCM task that answers these questions

– What happened?
– Who did it?
– When did it happen?
– What else will be affected?
• When many people are involved, it is likely that ‘the left hand not
knowing what the right hand is doing’ syndrome will occur
• CSR helps to eliminate this problem by improving communication
among all the people involved

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 54

 Status Accounting

Change
Change
Reports ECOs
Requests
SCIs

Status Accounting

Reporting
22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 55
 CASE Tool (CO5)

CASE (Computer Aided Software Engineering)tool

a CASE tool used to automate some activity associated with software
development.

CASE tools assist

• Phase activities such as specification, structured analysis, design,
coding, testing, etc.;
• Non-phase activities such as project management and
configuration management.
Reasons for using CASE tools
The primary reasons for using a CASE tool are:
• To increase productivity
• To help produce better quality software at lower cost

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 56

 List of CASE Tool

Application. CASE tool Purpose of tool

Planning Excel spreadsheet, ms project, Functional app.: planning,

pert network, estimation tools scheduling, control

Editing Dig. Editor, text editor, word Speed and efficiency

processor

Testing Test data generator, file Speed and efficiency

comparator

Prototyping High level modeling language, Confirmation and

UI generator certification of SRS and
SDD

22/05/2023 57
Kedar Nath Singh KCS 601 Software Engineering Unit V
 List of CASE Tool

Application. CASE tool Purpose of tool

Documentation Report generator, PPT Faster structural

presentation documentation

Programming and language Program generator, code High quality with error
processing integration generator, compiler, interpreter free programming

Re engineering tool Cross reference system, Reverse engineering to

program re engineering system fined structure, design and
design information

Program analysis tool Cross reference system, static Analyzes risks, functions,
and dynamic analyzers features.

22/05/2023 58
Kedar Nath Singh KCS 601 Software Engineering Unit V
 Benefits of CASE Tool

• Improved productivity.
• Better documentation.
• Reduced lifetime maintenance.
• Improved accuracy
• Opportunity to non- programmers

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 59

 Cost Estimation (CO5)

Models

Static, Single Variable Models Static Multivariable Models

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 60

 Static, Single Variable Models

Effort (E in Person-months), documentation (DOC, in number of pages)

and duration (D, in months) are calculated from the number of lines of
code (L, in thousands of lines) used as a predictor. Methods using this
model use an equation to estimate the desired values such as cost,
time, effort, etc. They all depend on the same variable used as
predictor (say, size)

C is the cost, L is the size and a,b are constants

Effort(

Duration(

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 61

 Static, Multivariable Models

These models are often based on equation (i), they actually depend
on several variables representing various aspects of the software
development environment, for example method used, user
participation, customer oriented changes, memory constraints, etc.

E= 5.2 L0.91
D= 4.1 L0.36

The productivity index uses 29 variables which are found to

be highly correlated to productivity as follows:
29
𝐼=∑ 𝑊 𝑖 𝑋 𝑖
𝑖=1
22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 62
 COCOMO (CO5)

Constructive Cost model

COCOMO

Basic Intermediate Detailed

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 63

 COCOMO (CO5)

Constructive Cost model

COCOMO applied to

Organic mode Semidetached mode Embedded mode

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 64

 Comparison of three COCOMO modes

Mode Project size Nature of Project Innovation Deadline of Development

the project Environment

Organic Typically Small size project, experienced Little Not tight Familiar & In
developers in the familiar house
2-50 KLOC environment. For example, pay
roll, inventory projects etc.

Semi Typically Medium size project, Medium Medium Medium Medium

detached size team, Average previous
50-300 KLOC experience on similar project. For
example: Utility systems like
compilers, database systems,
editors etc.

Embedded Typically over Large project, Real time systems, Significant Tight Complex
Complex interfaces, Very little Hardware/
300 KLOC customer
previous experience. For
example: ATMs, Air Traffic Control Interfaces
etc. required

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 65

 Basic Model

Basic COCOMO model takes the form

Ea
(KLOC)b b

D b c (E)
where E is effort applied in Person-Months, and D is the development
time in months. The coefficients ab, bb, cb and db are given in table.

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 66

 Basic COCOMO coefficients

Software ab bb cb db
Project

Organic 2.4 1.05 2.5 0.38

Semidetached 3.0 1.12 2.5 0.35

Embedded 3.6 1.20 2.5 0.32

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 67

 Basic COCOMO coefficients

When effort and development time are known, the average staff size to
complete the project may be calculated as:
E
Average staff size (SS ) 
Persons
D

When project size is known, the productivity level may be

calculated as:

KLOC
Productivity (P)  E KLOC / PM

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 68

 Basic COCOMO coefficients

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 69

 Intermediate Model

Cost drivers

Product Attributes
➢ Required s/w reliability
➢ Size of application database

➢Complexity of the product

Hardware Attributes
➢ Run time performance constraints
➢ Memory constraints
➢ Virtual machine volatility
➢ Turnaround time

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 70

 Intermediate Model

Personal Attributes
➢ Analyst capability
➢ Programmer capability
➢ Application experience
➢ Virtual m/c experience
➢ Programming language experience
Project Attributes
➢ Modern programming practices
➢ Use of software tools
➢ Required development Schedule

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 71

 Multipliers of different cost drivers

Cost Drivers RATINGS

Very Low Nominal High Very Extra high
low high

Product Attributes
RELY 0.75 0.88 1.00 1.15 1.40 --
DATA -- 0.94 1.00 1.08 1.16 --
CPLX 0.70 0.85 1.00 1.15 1.30 1.65
Computer Attributes
TIME -- -- 1.00 1.11 1.30 1.66
STOR -- -- 1.00 1.06 1.21 1.56
VIRT -- 0.87 1.00 1.15 1.30 --
TURN -- 0.87 1.00 1.07 1.15 --

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 72

 Multipliers of different cost drivers

Cost Drivers RATINGS

Very low Low Nominal High Very Extra
high
high

Personnel Attributes
ACAP 1.00 0.86 0.71 --
1.46 1.19
AEXP --
1.29 1.13 1.00 0.91 0.82
PCAP 0.86 0.70 --
1.42 1.17 1.00
VEXP --
1.21 1.10 1.00 0.90 --
LEXP --
1.14 1.07 1.00 0.95 --
Project Attributes
MODP --
1.24 1.10 1.00 0.91 0.82
TOOL 1.24 1.10 1.00 0.91 0.83 --
SCED
1.23 1.08 1.00 1.04 1.10 --

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 73

 Intermediate COCOMO equations

E  a (KLOC)b * EAF i

i
D  c (E) d i

Project ai bi ci di

Organic 3.2 1.05 2.5 0.38

Semidetached 3.0 1.12 2.5 0.35

Embedded 2.8 1.20 2.5 0.32

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 74

 Detailed COCOMO Model

Detailed COCOMO

Phase-Sensitive Three level product

effort multipliers hierarchy
Modules subsystem
Cost
drivers design
& test

Manpower allocation for each System level

phase

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 75

 Detailed COCOMO Model

Development Phase

Plan / Requirements

EFFORT DEVELOPMENT TIME : 6% to 8%

% depend on mode & size : 10% to 40%

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 76

 Detailed COCOMO Model

Design
Effort : 16% to 18%
Time : 19% to 38%

Programming
Effort : 48% to 68%
Time : 24% to 64%

Integration & Test

Effort : 16% to 34%
Time : 18% to 34%

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 77

 Detailed COCOMO Model

Principle of the effort estimate

Size equivalent
As the software might be partly developed from software already
existing (that is, re-usable code), a full development is not always
required. In such cases, the parts of design document (DD%), code (C%)
and integration (I%) to be modified are estimated. Then, an adjustment
factor, A, is calculated by means of the following equation.
A = 0.4 DD + 0.3 C + 0.3 I
The size equivalent is obtained by
S (equivalent) = (S x A) / 100
Ep   p E
Dp   p D

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 78

 Resource Allocation Model (CO5)

Norden of IBM
Rayleigh curve

Model for a range of hardware development projects.

Overall Curve
Design and
Coding

Persons

Time
The Rayleigh manpower loading curve
22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 79
 Resource Allocation Model

The Norden / Rayleigh Curve

The curve is modeled by differential equation

dy
m(t)  dt  2kate  at 2

dt = manpower utilization rate per unit time

a = parameter that affects the shape of the curve

K = area under curve in the interval [0, ∞ ]
t = elapsed time

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 80

 Resource Allocation Model

a=2

a=0.5
a=0.222
m (t)
Person
a=0.125

Time (years)

Fig: Influence of parameter ‘a’ on the manpower distribution

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 81

 Risk analysis and management (CO5)

What is risk ?

Tomorrow’s problems are today’s risks.

“Risk is a problem that may cause some loss or threaten the

success of the project, but which has not happened yet”.

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 82

 Risk analysis and management

Risk management is the process of identifying addressing

and eliminating these problems before they can damage the
project.

Current problems &

Potential Problems

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 83

 Risk analysis and management

Typical Software Risk

Capers Jones has identified the top five risk

factors that threaten projects in different applications
1. Dependencies on outside agencies or factors.
• Availability of trained, experienced persons
• Inter group dependencies
• Customer-Furnished items or information
• Internal & external subcontractor relationships

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 84

 Risk analysis and management

2. Requirement issues

Uncertain requirements

Wrong product
or
Right product badly

Either situation results in unpleasant

surprises and unhappy customers.

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 85

 Risk analysis and management

2. Requirement issues

Uncertain requirements

Wrong product
or
Right product badly

Either situation results in unpleasant

surprises and unhappy customers.

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 86

 Risk analysis and management

3. Management Issues

Project managers usually write the risk management

plans, and most people do not wish to air their
weaknesses in public.
• Inadequate planning
• Inadequate visibility into actual project status
• Unclear project ownership and decision making
• Staff personality conflicts
• Unrealistic expectation
• Poor communication

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 87

 Risk analysis and management

4. Lack of knowledge
• Inadequate training
• Poorunderstanding of methods,
tools, and techniques
• Inadequate application domain experience

• New Technologies

• Ineffective, poorly documented or neglected processes

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 88

 Risk analysis and management

5. Other risk categories

• Unavailability of adequate testing facilities

• Turnover of essential personnel

• Unachievable performance requirements

• Technical approaches that may not work

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 89

 Risk analysis and management

Risk Identification

Risk Analysis
Risk
Assessment Risk Prioritization

Risk
Management Risk Management
Planning
Risk Control
Risk Monitoring

Risk Resolution

Fig. Risk Management Activities

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 90
 Faculty Video Links, Youtube & NPTEL Video Links and
Online Courses Details

• https://nptel.ac.in/courses/106/105/106105182/
• https://
www.youtube.com/watch?v=RQNZWCl6eXI&list=PLBd76GK9sWTwVX
m9FlVHOTXXbGY2vZR8z&index=1
• https://www.youtube.com/watch?v=PXYqu-OcBoY
• https://
www.youtube.com/watch?v=KqDlDubS-OU&list=PL8751DA481F0F0D1
7&index=21

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 91

 Daily Quiz

1) A COCOMO model is
(a) Common Cost estimation model (b) Constructive cost Estimation model
(c) Complete cost estimation model (d) Comprehensive Cost estimation model
2) Estimation of software development effort for organic software is COCOMO is
(a) E=2.4(KLOC)1.05PM (b) E=3.4(KLOC)1.06PM
(c) E=2.0(KLOC)1.05PM (d) E-2.4(KLOC)1.07PM
 
3) Estimation of size for a project is dependent on
(a) Cost (b) Schedule(c) Time (d) None of the above
4)CASE Tool is
(a) Computer Aided Software Engineering (b) Component Aided Software Engineering
(c) Constructive Aided Software Engineering (d)Computer Analysis Software Engineering
 
5)The process by which existing processes and methods are replaced by new techniques is:
(a) Reverse engineering (b) Business process re-engineering
(c) Software configuration management (d) Technical feasibility

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 92

 Daily Quiz

6)Adaptive maintenance is related to

(a) Modification in software due to failure
(b) Modification in software due to demand of new functionalities
(c) Modification in software due to increase in complexity
(d) Modification in software to match changes in the ever-changing environment.
7)Perfective maintenance refers to enhancements
(a) Making the product better
(b) Making the product faster and smaller
(c) Making the product with new functionalities
(d) All of the above
8) As per distribution of maintenance effort, which type of maintenance has consumed
maximum share?
(a) Adaptive (b) Corrective (c) Perfective (d) Preventive

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 93

 Daily Quiz

9)Legacy systems are

(a) old systems (b) new systems
(c) undeveloped systems (d) None of the above
10)The process of transforming a model into source code is
(a) Reverse Engineering (b) Forward engineering
(c) Re-engineering (d) Restructuring

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 94

 Weekly Assignment

1. What is software maintenance? Describe various categories of maintenance.

Which category consumes maximum effort and why?
2. What are the implication of maintenance for a one person software
production organization?
3. Some people feel that “maintenance is manageable”. What is your opinion
about this issue?

4. Discuss various problems during maintenance. Describe some solutions to these problems.
5. Why do you think that the mistake is frequently made of considering software maintenance
inferior to software development?
6. Explain the importance of maintenance. Which category consumes maximum effort and why?
7. Explain the steps of software maintenance with help of a diagram.

8. What is self descriptiveness of a program? Explain theeffect of this parameter

on maintenance activities.

9. Discuss the concept of re-engineering and its importance.

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 95

 MCQ

1 COCOMO was developed initially by

(a) B.W.Bohem (b) Gregg Rothermal
(c) B.Beizer (d) Rajiv Gupta
2 A COCOMO model is
(a) Common Cost estimation model
(b) Constructive cost Estimation model
(c) Complete cost estimation model
(d) Comprehensive Cost estimation model
3 Estimation of software development effort for organic software is COCOMO is
(a) E=2.4(KLOC)1.05PM (b) E=3.4(KLOC)1.06PM
(c) E=2.0(KLOC)1.05PM (d) E-2.4(KLOC)1.07PM
4 Estimation of size for a project is dependent on
(a) Cost (b) Schedule
(c) Time (d) None of the above
5 In function point analysis, number of Complexity adjustment factor are
(a) 10 (b) 20
(c) 14 (d) 12
22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 96
 MCQ

6 Process of generating analysis and design documents is called

(a) Inverse Engineering (b) Software Engineering
(c) Reverse Engineering (d) Re-engineering
7. Regression testing is primarily related to
(a) Functional testing (b) Data flow testing
(c) Development testing (d) Maintenance testing
8 Which one is not a category of
(a) Corrective
maintenance ? maintenance (b) Effective maintenance
(c) Adaptive maintenance (d) Perfective maintenance
9 The maintenance initiated by defects in the software is called
(a) Corrective maintenance (b) Adaptive maintenance
(c) Perfective maintenance (d) Preventive maintenance
10 Patch is known as
(a) Emergency fixes (b) Routine fixes
(c) Critical fixes (d) None of the above

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 97

 Old Question Papers

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 98

 Old Question Papers

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 99

 Old Question Papers

Kedar Nath Singh KCS 601 Software

22/05/2023 100
Engineering Unit V
 Expected Questions for University Exam

1. Discuss various problems during maintenance. Describe some

solutions.
2. What is ripple effect? Discuss the various aspects of ripple effect
and how does it affect the stability of a program?
3. What is reverse engineering? Discuss levels of reverse engineering
4. compare reverse engineering and re-engineering.
5. What are configuration management activities? Draw the
Performa of change request form

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 101
 Summary

Software as an Evolutionary Entity, Need for maintenance,

Categories of Maintenance: Preventive, Corrective and Perfective Maintenance,

Cost of Maintenance, Software ReEngineering, Reverse Engineering.

Software Configuration Management Activities, Change Control Process,

Software Version Control, An Overview of CASE Tools.

Estimation of Various Parameters such as Cost, Efforts, Schedule/Duration

Constructive Cost Models (COCOMO), Resource allocation Models,

Software Risk Analysis and Management.

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 102
 References

1. R. S. Pressman, Software Engineering: A Practitioners Approach,

McGraw Hill.
2. Rajib Mall, Fundamentals of Software Engineering, PHI
Publication.
3. K. K. Aggarwal and Yogesh Singh, Software Engineering, New Age
International Publishers.
4. Pankaj Jalote, Software Engineering, Wiley
5. Deepak Jain,” Software Engineering: Principles and Practices”,
Oxford University Press.
6. Munesh C. Trivedi, Software Engineering, Khanna Publishing
House
7. N.S. Gill, Software Engineering, Khanna Publishing House

22/05/2023 Kedar Nath Singh KCS 601 Software Engineering Unit V 103