Hard work matters for everyone in everytbing

Software Engineering
UNIT-V
B.Tech (CSE)-IV SEM
Dept of CSE 1

UNIT-V:
Software Project Estimation: Decomposition techniques, Empirical Estimation Models,
Maintenance: Maintenance Process, Reengineering, Configuration Management.
Metrics for Products: Software Measurement, Metrics for software quality,
Quality Management: Quality concepts, Software Reviews, Formal technical reviews,
SEI-CMM Model, Six Sigma and ISO 9000 quality standards.
SRI VASAVI ENGINEERING COLLEGE
PEDATADEPALLI, TADEPALLIGUDEM-534 101
Department of Computer Science & Engineering
Syllabus
Course Title: Software Engineering
Course Code: V20CST07
Semester:IV
Academic Year:2022-23

1. METRICS FOR
PRODUCTS
Dept of CSE 3

Software Measurement:
 To assess the quality of the engineered product or system and
to better understand the models that are created, some
measures are used.
 These measures are collected throughout the software
development life cycle with an intention to improve the
software process on a continuous basis.
 Measurement helps in estimation, quality control, productivity
assessment and project control throughout a software project.
 Also, measurement is used by software engineers to gain
insight into the design and development of the work products.
In addition, measurement assists in strategic decision-making
as a project proceeds.
Dept of CSE 4

Classification of Software Measurement:
There are 2 types of software measurement:
 Direct Measurement: In direct measurement, the product,
process, or thing is measured directly using a standard scale.
ex: In physical world- length of a bolt
In software- lines of code (LOC) produced,
execution speed, memory size, and
defects reported
 Indirect Measurement: In indirect measurement, the
quantity or quality to be measured is measured using related
parameters
ex: In physical world- quality of bolt
In software- functionality, quality, complexity, efficiency,
reliability, maintainability, and many other
Dept of CSE 5

Software Metrics
 A software metric is a measure of software characteristics.
 software metric are measurable or countable.
Ex: Physical world- for length-mm, cm, m, feet
software-for size-LOC, Function Points.
Classification of Software Metrics:
There are 3 types of software metrics
 Product Metrics: These are the measures of various
characteristics of the software product.
The two important software characteristics are:
 Size and complexity of software.
 Quality and reliability of software.
Dept of CSE 6

 Process Metrics: These are the measures of various
characteristics of the software development process. They
are used to measure the characteristics of methods,
techniques, and tools that are used for developing
software.
For example, the efficiency of fault detection.
 Project metrics: Project metrics are the metrics used by
the project manager to check the project's progress.
Ex: Number of software developers, Cost and
schedule , Productivity.
Based on project metrics the manager can take necessary
actions to reduce cost and time and to improve quality.
Dept of CSE 7

1) Size Oriented Metrics:
Size-oriented metrics are a direct measure of software and
the development process. Effort (time), money spent, KLOC
(thousands of lines of code), pages of documentation
written, errors, and individuals on the project are examples
of these measures.
If a software company keeps simple records, we can make a
table of Size Oriented metrics like the one below.
Dept of CSE 8

 Referring to the table entry for project alpha: 12,100 lines of code
were developed with 24 person-months of effort at a cost of
$168,000 it also indicates that 365 pages of documentation were
developed, 134 errors were recorded before the software was
released, and 29 defects were encountered after release to the
customer within the first year of operation. Three people worked
on the development of software for project alpha.
Dept of CSE 9

 To compare similar metrics from other projects, you can
choose lines of code as a normalization value.
 set of simple size-oriented metrics can be developed for
each project:
 Errors per KLOC (thousand lines of code)
 Defects per KLOC
 $ per KLOC
 Pages of documentation per KLOC
 In addition, other interesting metrics can be computed:
 Errors per person-month
 KLOC per person-month
 $ per page of documentation
 Size-oriented metrics are not universally accepted as the
best way to measure the software process.
Dept of CSE 10

2) Function-Oriented Metrics:
 Function-oriented software metrics use a measure of the
functionality delivered by the application as a
normalization value.
 The most widely used function-oriented metric is the
function point (FP).
 Computation of the function point is based on
characteristics of the software’s information domain and
complexity.
The function point, like the LOC measure, is
controversial.
 Proponents claim that FP is programming language
independent, making it ideal for application using
conventional and nonprocedural languages, and that it is
based on data that are more likely to be known early in the
evolution of a project, making FP more attractive as an
estimation approach.
Dept of CSE
11

 Opponents claim that the method requires some “sleight of
hand ” in that computation is based subjective rather than
objective data, that counts of the information domain can be
difficult to collect after the fact, and that FP has no direct
physical meaning- it’s just a number.
Typical Function-Oriented Metrics:
➢ errors per FP (thousand lines of code)
➢ defects per FP
➢ $ per FP
➢ pages of documentation per FP
➢ FP per person-month
 Calculating Function points will be discussed in the coming
topics
Dept of CSE 12

3) Object Oriented Metrics:
 Conventional software project metrics (LOC or FP) can be
used to estimate object oriented software projects.
 However, these metrics do not provide enough granularity
for the schedule and effort adjustments that are required
as you iterate through an evolutionary or incremental
process.
 Lorenz and Kidd suggest the following set of metrics for
OO projects:
 Number of scenario scripts: A scenario script is a
detailed sequence of steps that describes the interaction
between the user and the application.
Each script is organized into triplets of the form
{initiator, action, participant}
Dept of CSE 13

 where initiator is the object that requests some service
(that initiates a message), action is the result of the
request, and participant is the server object that satisfies
the request.
 The number of scenario scripts is directly correlated to the
size of the application and to the number of test cases that
must be developed to exercise the system once it is
constructed.
 Number of key classes. Key classes are the “highly
independent components” that are defined early in object-
oriented analysis . Because key classes are central to the
problem domain, the number of such classes is an
indication of the amount of effort required to develop the
software and also an indication of the potential amount of
reuse to be applied during system development.
Dept of CSE 14

 Number of support classes. Support classes are required
to implement the system but are not immediately related
to the problem domain. Examples might be user interface
(GUI) classes, database access and manipulation classes,
and computation classes.
 Average number of support classes per key class. In
general, key classes are known early in the project.
Support classes are defined throughout. If the average
number of support classes per key class were known for a
given problem domain, estimating (based on total number
of classes) would be greatly simplified.
 Number of subsystems. A subsystem is an aggregation
of classes that support a function that is visible to the end
user of a system. Once subsystems are identified, it is
easier to lay out a reasonable schedule in which work on
subsystems is partitioned among project staff.
Dept of CSE 15

4) Use-Case–Oriented Metrics:
 Use-cases describe (indirectly) user-visible functions and
features in language independent manner.
 It would seem reasonable to use the use case as a
normalization measure similar to LOC or FP.
 the number of use cases is directly proportional to the size
of the application in LOC and to the number of test cases
that will have to be designed to fully exercise the
application.
 However use cases do not come in standard sizes and use
as a normalization measure is suspect .
 Use case points have been suggested as a mechanism for
estimating effort.
Dept of CSE 16

5) WebApp Project Metrics:
The objective of all web engineering projects is to build a
Web application that delivers a combination of content
and functionality to the end-user.
measures that can be used in WebApp Project Metrics are:
 Number of static Web pages. Web pages with static
content (i.e., the end user has no control over the content
displayed on the page) are the most common of all
WebApp features. These pages represent low relative
complexity and generally require less effort to construct
than dynamic pages. This measure provides an indication
of the overall size of the application and the effort
required to develop it.
Dept of CSE 17

 Number of dynamic Web pages. Web pages with
dynamic content (i.e., end-user actions or other external
factors result in customized content displayed on the
page) are essential in all e-commerce applications, search
engines, financial applications, and many other. These
pages represent higher relative complexity and require
more effort to construct than static pages. This measure
provides an indication of the overall size of the application
and the effort required to develop it.
 Number of internal page links. Internal page links are
pointers that provide a hyperlink to some other Web page
within the WebApp. This measure provides an indication
of the degree of architectural coupling within the
WebApp. As the number of page links increases, the effort
expended on navigational design and construction also
increases. Dept of CSE 18

 Number of persistent data objects. One or more
persistent data objects (e.g., a database or data file) may be
accessed by a WebApp. As the number of persistent data
objects grows, the complexity of the WebApp also grows
and the effort to implement it increases proportionally.
 Number of external systems interfaced. WebApps
must often interface with “backroom” business
applications. As the requirement for interfacing grows,
system complexity and development effort also increase.
 Number of static content objects. Static content objects
encompass static text-based, graphical, video, animation,
and audio information that are incorporated within the
WebApp. Multiple content objects may appear on a single
Web page.
Dept of CSE 19

 Number of dynamic content objects. Dynamic content
objects are generated based on end-user actions and
encompass internally generated textbased, graphical,
video, animation, and audio information that are
incorporated within the WebApp. Multiple content objects
may appear on a single Web page.
 Number of executable functions. An executable
function (e.g., a script or applet) provides some
computational service to the end user. As the number of
executable functions increases, modeling and
construction effort also increase.
Dept of CSE 20

Metrics For Software Quality:
 The main goal of software engineering is to produce a
high-quality system, application, or product within a time
frame that satisfies a market need.
 To achieve this goal, you must apply effective methods
coupled with modern tools to the software process.
 A project manager must evaluate quality of the software
as the project progresses.
 There is a number of metrics available based on which
software quality is measured. But among them, there are a
few most useful metrics which are essential in software
quality measurement. They are –
Dept of CSE 21

1) Code Quality – Code quality metrics measure the quality
of code used for software project development.
Maintaining the software code quality by writing Bug-free
and semantically correct code is very important for good
software project development. In code quality, both
Quantitative metrics like the number of lines, complexity,
functions, rate of bugs generation, etc, and Qualitative
metrics like readability, code clarity, efficiency, and
maintainability, etc are measured.
2) Reliability – Reliability metrics express the reliability of
software in different conditions. The software is able to
provide exact service at the right time or not checked.
Reliability can be checked using Mean Time Between
Failure (MTBF) and Mean Time To Repair (MTTR).
Dept of CSE 22

3) Performance – Performance metrics are used to measure
the performance of the software. Each software has been
developed for some specific purposes. Performance
metrics measure the performance of the software by
determining whether the software is fulfilling the user
requirements or not, by analyzing how much time and
resource it is utilizing for providing the service.
4) Usability – Usability metrics check whether the program
is user-friendly or not. Each software is used by the end-
user. So it is important to measure that the end-user is
happy or not by using this software.
5) Correctness – Correctness is one of the important
software quality metrics as this checks whether the system
or software is working correctly without any error by
satisfying the user. Correctness gives the degree of service
each function provides as per developed.
Dept of CSE 23

6)Maintainability – Each software product requires
maintenance and up-gradation. Maintenance is an expensive
and time-consuming process. So if the software product
provides easy maintainability then we can say software quality
is up to mark. Maintainability metrics include the time
required to adapt to new features/functionality, Mean Time to
Change (MTTC), performance in changing environments, etc.
7) Integrity – Software integrity is important in terms of how
much it is easy to integrate with other required software which
increases software functionality and what is the control on
integration from unauthorized software’s which increases the
chances of cyber attacks.
8) Security – Security metrics measure how secure the software
is. In the age of cyber terrorism, security is the most essential
part of every software. Security assures that there are no
unauthorized changes, no fear of cyber attacks, etc when the
software product is in use by the end-user.
Dept of CSE 24

2. Quality Management
Dept of CSE 25

Quality Concepts:
1. What Is Quality?
According to David Garvin Quality is a “quality is a complex
and multifaceted concept” that can be described from five
different points of view.
 The transcendental view that quality is something that you
immediately recognize, but cannot explicitly define.
 The user view sees quality in terms of an end user’s specific
goals. If a product meets those goals, it exhibits quality.
 The manufacturer’s view defines quality in terms of the
original specification of the product. If the product conforms to
the spec, it exhibits quality.
 The product view suggests that quality can be tied to inherent
characteristics (e.g., functions and features) of a product.
 Finally, the value-based view measures quality based on how
much a customer is willing to pay for a product.
 In reality, quality encompasses all of these views and more.
Dept of CSE 26

2. Software Quality:
Software quality can be defined as:
“An effective software process applied in a manner
that creates a useful product that provides
measurable value for those who produce it and those
who use it.”
 The way we define quality is subjective. There's no single
right definition for quality; each person has their own
definition based on personal experiences.
 So, how good is our definition of quality? If someone asks
about "quality," what should they look out for? We must
know different people views regarding the definition of
quality.
Dept of CSE 27

2.1 Garvin’s Quality Dimensions:
Garvin proposes eight critical dimensions or categories of
quality that can serve as a framework for strategic analysis:
Performance, features, reliability, conformance, durability,
serviceability, aesthetics, and perceived quality.
 Performance quality. Does the software deliver all content,
functions, and features that are specified as part of the
requirements model in a way that provides value to the end
user?
For a car, performance would include characteristics like
millage per gallon, acceleration, handling, cruising speed etc.
 Feature quality. Does the software provide features that
surprise and delight first-time end users?
For a car, features would include the built-in GPS, seat
warmer, smartphone integration etc.
Dept of CSE 28

 Reliability. Does the software deliver all features and
capability without failure? Is it available when it is
needed? Does it deliver functionality that is error-free?
 Conformance. Does the software conform to local and
external software standards that are relevant to the
application? Does it conform to de facto design and coding
conventions? For example, does the user interface conform
to accepted design rules for menu selection or data input?.
 Durability. Can the software be maintained (changed) or
corrected (debugged) without the inadvertent generation
of unintended side effects? Will changes cause the error
rate or reliability to degrade with time?
Dept of CSE 29

 Serviceability. Can the software be maintained (changed)
or corrected (debugged) in an acceptably short time
period? Can support staff acquire all information they
need to make changes or correct defects?
Serviceability is the ease at which a user can repair a faulty
product or get it fixed.
 Aesthetics Aesthetics refers to the appearance of a
product or service. It includes all aspects related to the
physical appearance of a product, for example, the weight,
colour, size, texture, packaging design etc.
 Perceived Quality is the overall opinion of the customers
towards the product. It's the combined effects of factors
such as brand name, price, salesperson, marketing
strategy etc.
 Example: When was the last time you had a positive
experience with a bank?
Dept of CSE 30

2.2 McCall’s Quality Factors
 McCall, Richards, and Walters propose a useful
categorization of factors that affect software quality.
 These software quality factors, shown in Figure ,
 focus on three important aspects of a software product: its
operational characteristics, its ability to undergo change,
and its adaptability to new environments.
Dept of CSE 31

McCall and his colleagues provide the following descriptions:
 Correctness. The extent to which a program satisfies its
specification and fulfills the customer’s mission objectives.
 Reliability. The extent to which a program can be expected
to perform its intended function with required precision.
 Efficiency. The amount of computing resources and code
required by a program to perform its function.
 Integrity. Extent to which access to software or data by
unauthorized persons can be controlled.
 Usability. Effort required to learn, operate, prepare input
for, and interpret output of a program.
 Maintainability. Effort required to locate and fix an error in
a program.
 Flexibility. Effort required to modify an operational
program. Dept of CSE 32

 Testability. Effort required to test a program to ensure that it
performs its intended function.
 Portability. Effort required to transfer the program from one
hardware and/or software system environment to another.
 Reusability. Extent to which a program [or parts of a
program] can be reused in other applications—related to the
packaging and scope of the functions that the program
performs.
 Interoperability. Effort required to couple one system to
another.
 It is difficult, and in some cases impossible, to develop direct
measures of these quality factors. In fact, many of the
metrics defined by McCall et al. can be measured only
indirectly. However, assessing the quality of an application
using these factors will provide you with a solid indication of
software quality.Dept of CSE 33

2.3 ISO 9126 Quality Factors:
 The ISO 9126 standard was developed in an attempt to
identify the key quality attributes for computer software.
The standard identifies six key quality attributes:
 Functionality. The degree to which the software satisfies
stated needs as indicated by the following subattributes:
suitability, accuracy, interoperability,compliance, and
security.
 Reliability. The amount of time that the software is
available for use as indicated by the following
subattributes: maturity, fault tolerance, recoverability.
 Usability. The degree to which the software is easy to use
as indicated by the following subattributes:
understandability, learnability, operability.
Dept of CSE 34

 Efficiency. The degree to which the software makes
optimal use of system resources as indicated by the
following subattributes: time behavior, resource behavior.
 Maintainability. The ease with which repair may be
made to the software as indicated by the following
subattributes: analyzability, changeability, stability,
testability.
 Portability. The ease with which the software can be
transposed from one environment to another as indicated
by the following subattributes: adaptability, installability,
conformance, replaceability.
Dept of CSE 35

2.3 Achieving Software Quality:
 Software quality doesn’t just appear. It is the result of good
project management and solid software engineering
practice.
 Management and practice are applied within the context
of four broad activities that help a software team achieve
high software quality:
 software engineering methods,
 project management techniques,
 Quality control actions, and
 software quality assurance.
Dept of CSE 36

 Software Engineering Methods:
We are having a wide array of concepts and methods
that can lead to a reasonably complete understanding of the
problem and a comprehensive design that establishes a solid
foundation for the construction activity. If you apply those
concepts and adopt appropriate analysis and design
methods, the likelihood of creating high-quality software
will increase substantially.
 Project Management Techniques:
If the project manager follows the project management
techniques The implications are clear: if (1) the project
manager uses estimates to ensure delivery dates are met, (2)
schedule dependencies are understood and the team resists
the temptation to take shortcuts, (3) risk planning occurs so
that problems arise. does not cause chaos, the quality of the
software is positively affected.
Dept of CSE 37

 Quality Control:
 Quality control encompasses a set of software engineering
actions that help to ensure that each work product meets its
quality goals.
 Models are reviewed to ensure that they are complete and
consistent. Code may be inspected in order to uncover and
correct errors before testing commences.
 A series of testing steps is applied to uncover errors in
processing logic, data manipulation, and interface
communication.
 A combination of measurement and feedback allows a
software team to tune the process when any of these work
products fail to meet quality goals
Dept of CSE 38

 Quality Assurance:
 Quality assurance establishes the infrastructure that
supports solid software engineering methods, rational
project management, and quality control actions—all
pivotal if you intend to build high-quality software.
 In addition, quality assurance consists of a set of auditing
and reporting functions that assess the effectiveness and
completeness of quality control actions.
 The goal of quality assurance is to provide management and
technical staff with the data necessary to be informed about
product quality, thereby gaining insight and confidence that
actions to achieve product quality are working. Of course, if
the data provided through quality assurance identifies
problems, it is management’s responsibility to address the
problems and apply the necessary resources to resolve
quality issues.
Dept of CSE 39

3.1 Informal Reviews:
 Informal reviews include a simple desk check of a software
engineering work product with a colleague, a casual
meeting (involving more than two people) for the purpose
of reviewing a work product.
 A simple desk check or a casual meeting conducted with a
colleague is a review. However, because there is no advance
planning or preparation, no agenda or meeting structure,
and no follow-up on the errors that are uncovered, the
effectiveness of such reviews is considerably lower than
more formal approaches. But a simple desk check can and
does uncover errors that might otherwise propagate
further into the software process.
41

 One way to improve the efficacy of a desk check review is to
develop a set of simple review checklists for each major work
product produced by the software team. The questions posed
within the checklist are generic, but they will serve to guide
the reviewers as they check the work product.
 For example, let’s reexamine a desk check of the interface
prototype for SafeHomeAssured.com. Rather than simply
playing with the prototype at the designer’s workstation, the
designer and a colleague examine the prototype using a
checklist for interfaces:
 Is the layout designed using standard conventions? Left to
right? Top to bottom?
 Does the presentation need to be scrolled?
 Are color and placement, typeface, and size used effectively?
 Are all navigation options or functions represented at the same
level of abstraction?
 Are all navigation choices clearly labeled?
42

 Any errors or issues noted by the reviewers are recorded by
the designer for resolution at a later time.
 Desk checks may be scheduled in an ad hoc manner, or
they may be mandated as part of good software
engineering practice.
 In general, the amount of material to be reviewed is
relatively small and the overall time spent on a desk check
spans little more than one or two hours.
43

3.2 Formal Technical Reviews:
 A formal technical review (FTR) is a software quality
control activity performed by software engineers (and
others).
 The objectives of an FTR are:
 (1) to uncover errors in function, logic, or implementation for
any representation of the software;
 (2) to verify that the software under review meets its
requirements;
 (3) to ensure that the software has been represented
according to predefined standards;
 (4) to achieve software that is developed in a uniform
manner; and
 (5) to make projects more manageable.
44

 In addition, the purpose of FTR is to enable junior
engineers to observe the analysis, design, coding and
testing approach more closely.
 FTR also works to promote back up and continuity become
familiar with parts of software they might not have seen
otherwise.
 Actually, FTR is a class of reviews that include
walkthroughs, inspections, round robin reviews and other
small group technical assessments of software.
 Each FTR is conducted as meeting and is considered
successful only if it is properly planned, controlled and
attended.
45

Steps required to conduct a successful FTR:
1) The review meeting: Each review meeting should be held
considering the following constraints- Involvement of
people:
 Between 3, 4 and 5 people should be involve in the review.
 Advance preparation should occur but it should be very short
that is at the most 2 hours of work for every person.
 The short duration of the review meeting should be less than
two hour. Gives these constraints, it should be clear that an
FTR focuses on specific (and small) part of the overall
software.
 At the end of the review, all attendees of FTR must decide
what to do.
 Accept the product without any modification.
 Reject the project due to serious error (Once corrected,
another app need to be reviewed), or 46

 Accept the product provisional (minor errors are
encountered and should be corrected, but no additional
review will be required).
 The decision was made, with all FTR attendees completing
a sign-of indicating their participation in the review and
their agreement with the findings of the review team.
2) Review reporting and record keeping :-
 During the FTR, the reviewer actively records all issues that
have been raised.
 At the end of the meeting all these issues raised are
consolidated and a review list is prepared.
 Finally, a formal technical review summary report is
prepared.
 It answers three questions :-
 What was reviewed ?
 Who reviewed it ?
 What were the findings and conclusions ?
47

3) Review guidelines :- Guidelines for the conducting of
formal technical reviews should be established in advance.
These guidelines must be distributed to all reviewers,
agreed upon, and then followed. A review that is
unregistered can often be worse than a review that does
not minimum set of guidelines for FTR.
1. Review the product, not the manufacture (producer).
2. Take written notes (record purpose)
3. Limit the number of participants and insists upon advance
preparation.
4. Develop a checklist for each product that is likely to be
reviewed.
5. Allocate resources and time schedule for FTRs in order to
maintain time schedule.
48

6. Conduct meaningful training for all reviewers in order to
make reviews effective.
7. Reviews earlier reviews which serve as the base for the
current review being conducted.
8. Set an agenda and maintain it.
9. Separate the problem areas, but do not attempt to solve
every problem notes.
10. Limit debate and rebuttal.
49

4.1 Software Engineering Institute- Capability Maturity
Model (SEI-CMM)
 SEICMM is expanded as ‘Software Engineering Institute
Capability Maturity Model’, and it was produced in 1987 at
the Carnegie Mellon University by the SEI (Software
Engineering Institute) themselves.
 It is not a software process model. It is a framework that is
used to analyze the approach and techniques followed by
any organization to develop software products.
 It also provides guidelines to further enhance the maturity
of the process used to develop those software products.
 The Capability Maturity Model (CMM) is a procedure used
to develop and refine an organization's software
development process.
51

 The Software Engineering Institute (SEI) Capability
Maturity Model (CMM) specifies an increasing series of
levels to a software development organization.
 The higher the level, the better the software development
process, hence reaching each level is an expensive and time-
consuming process.
Levels of CMM:
 SEI CMM categorized software development industries into
the following five maturity levels.
 The various levels of SEI CMM have been designed so that it
is easy for an organization to build its quality system
starting from scratch slowly.
Dept of CSE 52

 Level I: Initial – CMM1
 The organizations in the Initial stage, typically, will not have
any KPA’s(Key Process Area’ or the KPA’s are nothing but the
minimum requirement set for any software development
organization) set, will have lesser quality employees, the
management procedure will not be defined clearly, weakly
designed control over the development process, the quality
of the product will not be as good both in terms of the
customer’s convenience and in terms of the technical
advancements. Hence these organizations fall under the
least level of CMM1 in the SEI CMM.
Dept of CSE 54

 Level II: Repeatable – CMM2
 This level of Software Development Organization has a basic
and consistent project management processes to track cost,
schedule, and functionality. The process is in place to repeat
the earlier successes on projects with similar applications.
Program management is a key characteristic of a level two
organization.
 level III: Well-Defined – CMM3
 The commonly observed characteristics of this type of
organizations are that they use definite flow for the
development process, creating documentation in each step of
the development flow, everyone in the company is well aware of
their own roles and responsibilities, organization will be able to
deliver a better quality of software product, the employees are
made to work as a team and there is a notably structured
management process is observed. At the defined level, an
organization develops its own standard software development
process. These defined processes enable greater attention to
Dept of CSE 55

 Level IV: Well Managed – CMM4
 When management is clearly defined and executed, the
organization can move to a better level in terms of delivering
the quality product, as well as in the financial expansion. The
organizations in level IV are the ones that have qualified
management and focuses only on the quality of the
deliverables. This type of organizations will have various
measures for self assessments, both for the product points
and the process points.
 At the managed level, an organization monitors and controls
its own processes through data collection and analysis.
Dept of CSE 56

 Level V: Optimized – CMM5
 The Key characteristic of this level is focusing on continually
improving process performance through both incremental
and innovative technological improvements. At this level,
changes to the process are to improve the process
performance and at the same time maintaining statistical
probability to achieve the established quantitative process-
improvement objectives.
Dept of CSE 57

4.2 six sigma:
 The term "Six Sigma" refers to a statistical measure of how
far a process deviates from perfection.
 A process that operates at six sigma has a failure rate of
only 0.00034%, which means it produces virtually no
defects.
 Six Sigma was developed by Motorola in the 1980s, and it
has since been adopted by many other companies around
the world, including General Electric, Toyota, and
Amazon.
 It is used in industries such as manufacturing, healthcare,
finance, and service industries to improve customer
satisfaction, reduce costs, and increase profits.
Dept of CSE 59

What is Six Sigma?
 Six Sigma is a set of methodologies and tools used to
improve business processes by reducing defects and
errors, minimizing variation, and increasing quality and
efficiency.
 Six Sigma is a highly disciplined process that helps us
focus on developing and delivering near-perfect products
and services.
 Six Sigma is the process of improving the quality of the
output by identifying and eliminating the cause of defects
and reduce variability in manufacturing and business
processes.
 A six sigma method is one in which 99.99966% of all the
products to be produced have the some features and are of
free from defects.
Dept of CSE 60

Six Sigma Methodologies
 Six Sigma projects follow two project methodologies:
1. DMAIC
2. DMADV
1. DMAIC
 It specifies a data-driven quality strategy for improving
processes. This methodology is used to enhance an existing
business process.
 The DMAIC project methodology has five phases:
 Define
 Measure
 Analyze
 Improve
 Control
Dept of CSE 61

 The letters stand for:
 Define the problem and the project goals
 Measure in detail the various aspects of the current
process
 Analyze data to, among other things, find the root defects
in a process
 Improve the process
 Control how the process is done in the future
Dept of CSE 63

2. DMADV
The DMADV method is typically used to create new processes
and new products or services.
 The DMADV project methodology has five phases:
 Define
 Measure
 Analyze
 Design
 Verify
Dept of CSE 64

 The letters stand for:
 Define the project goals
 Measure critical components of the process and the
product capabilities
 Analyze the data and develop various designs for the
process, eventually picking the best one
 Design and test details of the process
 Verify the design by running simulations and a pilot
program, and then handing over the process to the client
Dept of CSE 66

4.3 ISO 9000 quality standards.
 ISO 9000 is a series of standards, developed and published
by the International Organization for Standardization
(ISO).
 It defines, establishes and maintains an effective quality
assurance (QA) system for manufacturing and service
industries.
 ISO 9000 is defined as a set of international standards on
quality management and quality assurance developed to
help companies effectively document the quality system
elements needed to maintain an efficient quality system.
They are not specific to any one industry and can be applied
to organizations of any size.
Dept of CSE 67

 ISO (International Standards Organization) is a group or
consortium of 63 countries established to plan and fosters
standardization.
 ISO declared its 9000 series of standards in 1987. It serves
as a reference for the contract between independent
parties.
 The ISO 9000 standard determines the guidelines for
maintaining a quality system.
 The ISO standard mainly addresses operational methods
and organizational methods such as responsibilities,
reporting, etc.
 ISO 9000 defines a set of guidelines for the production
process and is not directly concerned about the product
itself.
Dept of CSE 68

ISO 9000 quality management guidelines
There are seven quality management principles included in
ISO 9000:
Dept of CSE 69

1. Customer focus
 Understand the needs of existing and future customers
 Align organizational objectives with customer needs and
expectations
 Meet customer requirements
 Measure customer satisfaction
 Manage customer relationships
 Aim to exceed customer expectations
 Learn more about the customer experience and customer
satisfaction
Dept of CSE 70

2.Leadership
 Establish a vision and direction for the organization
 Set challenging goals
 Model organizational values
 Establish trust
 Equip and empower employees
 Recognize employee contributions
 Learn more about leadership
Dept of CSE 71

3.Engagement of people
 Ensure that people’s abilities are used and valued
 Make people accountable
 Enable participation in continual improvement
 Evaluate individual performance
 Enable learning and knowledge sharing
 Enable open discussion of problems and constraints
 Learn more about employee involvement
4.Process approach
 Manage activities as processes
 Measure the capability of activities
 Identify linkages between activities
 Prioritize improvement opportunities
 Deploy resources effectively
 Learn more about a process view of work and see process
analysis tools
Dept of CSE 72

5.Improvement
 Improve organizational performance and capabilities
 Align improvement activities
 Empower people to make improvements
 Measure improvement consistently
 Celebrate improvements
 Learn more about approaches to continual improvement
6.Evidence-based decision making
 Ensure the accessibility of accurate and reliable data
 Use appropriate methods to analyze data
 Make decisions based on analysis
 Balance data analysis with practical experience
 See tools for decision making
Dept of CSE 73

7. Relationship management
 Identify and select suppliers to manage costs, optimize
resources, and create value
 Establish relationships considering both the short and long
term
 Share expertise, resources, information, and plans with
partners
 Collaborate on improvement and development activities
 Recognize supplier successes
 Learn more about supplier quality and see resources related
to managing the supply chain
Dept of CSE 74

How to get ISO 9000 Certification?
 An organization determines to obtain ISO 9000
certification applies to ISO registrar office for registration.
The process consists of the following stages:
Dept of CSE 75

1. Application: Once an organization decided to go for ISO
certification, it applies to the registrar for registration.
2. Pre-Assessment: During this stage, the registrar makes a
rough assessment of the organization.
3. Document review and Adequacy of Audit: During this
stage, the registrar reviews the document submitted by
the organization and suggest an improvement.
4.Compliance Audit: During this stage, the registrar
checks whether the organization has compiled the
suggestion made by it during the review or not.
5. Registration: The Registrar awards the ISO certification
after the successful completion of all the phases.
6.Continued Inspection: The registrar continued to
monitor the organization time by time.
Dept of CSE 76

5. Software Project
Estimation
Dept of CSE 77

5.1 Introduction:
 software project estimation is a crucial process that revolves
around predicting the project’s time and effort, cost, and scope;
all this information is necessary for the planning stage and to
ensure the project’s success.
 Too many variables—human, technical, environmental,
political—can affect the ultimate cost of software and effort
applied to develop it.
 To achieve reliable cost and effort estimates, a number of options
arise:
 1. Delay estimation until late in the project (obviously, we can
achieve 100 percent accurate estimates after the project is
complete!).
 2. Base estimates on similar projects that have already been
completed.
 3. Use relatively simple decomposition techniques to generate
project cost and effort estimates.
 4. Use one or more empirical models for software cost and effort
estimation. Dept of CSE 78

 Unfortunately, the first option, however attractive, is not
practical. Cost estimates must be provided up-front. However,
you should recognize that the longer you wait, the more you
know, the less likely you are to make serious errors in your
estimates.
 The second option can work reasonably well, if the current
project is quite similar to past efforts and other project
influences (e.g., the customer, business conditions, the
software engineering environment, deadlines) are roughly
equivalent. Unfortunately, past experience has not always
been a good indicator of future results.
 The remaining options are viable approaches to software project
estimation.
 Decomposition techniques take a divide-and-conquer
approach to software project estimation. By decomposing a
project into major functions and related software engineering
activities, cost and effort estimation can be performed in a
stepwise fashion. Dept of CSE 79

 Empirical estimation models can be used to complement
decomposition techniques and offer a potentially valuable
estimation approach in their own right.
A model is based on experience (historical data) and takes the
form
d = f (vi)
where d is one of a number of estimated values (e.g., effort, cost,
project duration) and vi are selected independent parameters
Dept of CSE 80

5.2 Decomposition Techniques :
 Software project estimation is a form of problem solving,
and in most cases, the problem to be solved (i.e.,
developing a cost and effort estimate for a software
project) is too complex to be considered in one piece. For
this reason, you should decompose the problem,
recharacterizing it as a set of smaller problems.
 Decomposition approach was discussed from two different
points of view: decomposition of the problem and
decomposition of the process. Estimation uses one or both
forms of partitioning. But before an estimate can be made,
you must understand the scope of the software to be built
and generate an estimate of its “size.”
Dept of CSE 81

5.2.1 Software sizing:
 Software sizing or software size estimation is an activity in
software engineering that is used to determine or estimate
the size of a software application or component in order to
be able to implement other software project management
activities (such as estimating or tracking).
 In the context of project planning, size refers to a
quantifiable outcome of the software project. If a direct
approach is taken, size can be measured in lines of code
(LOC). If an indirect approach is chosen, size is
represented as function points (FP).
Dept of CSE 82

 A software project estimate's accuracy depends on a
variety of factors, including:
 (1) The degree to which you accurately estimated the size of
the product to be built;
 (2) The ability to convert the size estimate into human effort,
calendar time, and dollars;
 (3) The extent to which the project plan accurately reflects
the skills of the software team; and
 (4) The stability of the product requirements and the
environment that supports the software engineering effort.
Dept of CSE 83

5.2.2 Problem based Estimation:
 Problem-based estimation in software engineering is an
estimation technique that focuses on understanding and
estimating the effort and resources required to solve a
specific problem.
 It involves breaking down the project into smaller, more
manageable problem domains or modules and estimating
the effort required to solve each of these individual
problems.
 lines of code and function points were used to measure a
software from which productivity metrics (Development
cost ,effort ) can be computed.
 LOC and FP estimation are distinct estimation techniques.
Yet both have a number of characteristics in common.
Dept of CSE 84

The steps involved in problem-based estimation typically
include:
 Begins with a statement of scope.
 The software is decomposed into problem functions.
 Estimating FP or LOC.
 Combine those estimates and produce an overall estimate.
 Baseline productivity metrics (e.g., LOC/pm or FP/pm) are
then applied to the appropriate estimation variable, and
cost or effort for the function is derived.
 Function estimates are combined to produce an overall
estimate for the entire project.
 Let us discuss with examples
Dept of CSE 85

 An Example of LOC-Based Estimation:
 As an example of LOC based estimation techniques, I consider
a software package to be developed for a computer-aided
design application for mechanical components. The software
is to execute on an engineering workstation and must interface
with various computer graphics peripherals including a
mouse, digitizer, high-resolution color display, and laser
printer.
 A preliminary statement of software scope can be developed:
“The mechanical CAD software will accept two- and three-dimensional
geometric data from an engineer. The engineer will interact and control
the CAD system through a user interface that will exhibit
characteristics of good human/machine interface design. All geometric
data and other supporting information will be maintained in a CAD
database. Design analysis modules will be developed to produce the
required output, which will be displayed on a variety of graphics
devices. The software will be designed to control and interact with
peripheral devices that include a mouse, digitizer, laser printer, and
plotter.” Dept of CSE 86

 For our purposes, assume that further refinement has
occurred and that the major software functions listed in
Figure are identified. Following the decomposition
technique for LOC, an estimation table is developed.
Dept of CSE 87

 By summing vertically in the estimated LOC column, an
estimate of 33,200 lines of code is established for the CAD
system.
 A review of historical data indicates that the
organizational average productivity for systems of this
type is 620 LOC/pm.
 Based on a burdened labor rate of $8000 per month, the
cost per line of code is approximately $13.
 Based on the LOC estimate and the historical productivity
data, the total estimated project cost is $431,000 and the
estimated effort is 54 person-months
Dept of CSE 88

An Example of FP-Based Estimation:
 Decomposition for FP-based estimation focuses on
information domain values rather than software functions.
Referring to the table presented in below Figure, you
would estimate inputs, outputs, inquiries, files, and
external interfaces for the CAD software.
 Below Figure presents the results of this estimate.
Dept of CSE 89

 Est Count=(Sopt + 4Sm + Spess)/6
 FPCount=Est Count*weight
 Each of the complexity weighting factors is estimated, and
the value adjustment factor is computed.
Dept of CSE 90

 Finally, the estimated number of FP is derived:
 The organizational average productivity for systems of this
type is 6.5 FP/pm.
 Based on a burdened labor rate of $8000 per month, the
cost per FP is approximately $1230.
 Based on the FP estimate and the historical productivity
data,
 the total estimated project cost is $461,000 and the
estimated effort is 58 person-months.
Dept of CSE 91

5.2.3 Process-Based Estimation:
 The most common technique for estimating a project is to
base the estimate on the process that will be used.
 That is, the process is decomposed into a relatively small
set of tasks and the effort required to accomplish each task
is estimated.
 Like the problem-based techniques, process-based
estimation also follows some steps.
 The functions of the software are identified.
 A series of framework activities must be performed for each
function.
 Estimate effort to complete each software function.
 Apply average labor rates, compute the total cost and
compare the estimates.
Dept of CSE 92

An Example of Process-Based Estimation
 To illustrate the use of process-based estimation, consider
the CAD software introduced in the above Section.
 The system configuration and all software functions
remain unchanged and are indicated by project scope.
 Referring to the completed process-based table shown in
the below Figure , estimates of effort (in person-months)
for each software engineering activity are provided for
each CAD software function.
Dept of CSE 93

 The engineering and construction release activities are
subdivided into the major software engineering tasks
shown.
 Gross estimates of effort are provided for customer
communication, planning, and risk analysis. These are
noted in the total row at the bottom of the table.
 Horizontal and vertical totals provide an indication of
estimated effort required for analysis, design, code, and test.
It should be noted that 53 percent of all effort is expended
on front-end engineering tasks (requirements analysis and
design), indicating the relative importance of this work.
 Based on an average burdened labor rate of $8000 per
month, the total estimated project cost is $368,000 and the
estimated effort is 46 person-months. If desired, labor rates
could be associated with each framework activity or
software engineering task and computed separately.
Dept of CSE 95

5.2.4Estimation with Use Cases:
 Use cases provide a software team with insight into
software scope and requirements.
 However, developing an estimation approach with use
cases is problematic for the following reasons:
 Use cases are described using many different formats and
styles—there is no standard form.
 Use cases represent an external view (the user’s view) of the
software and can therefore be written at many different
levels of abstraction.
 Use cases do not address the complexity of the functions and
features that are described.
 Use cases can describe complex behavior (e.g., interactions)
that involve many functions and features.
Dept of CSE 96

 Unlike an LOC or a function point, one person’s “use case”
may require months of effort while another person’s use case
may be implemented in a day or two.
 Although a number of investigators have considered use
cases as an estimation input, no proven estimation method
has emerged to date.
 Before use cases can be used for estimation, the level within
the structural hierarchy is established, the average length
(in pages) of each use case is determined, the type of
software (e.g., real-time, business, engineering/scientific,
WebApp, embedded) is defined, and a rough architecture
for the system is considered.
 Once these characteristics are established, empirical data
may be used to establish the estimated number of LOC or
FP per use case.
Dept of CSE 97

 To illustrate how this computation might be made, consider
the following relationship:
Dept of CSE 98
Expression (26.2) could be used to develop a rough estimate of the
number of LOC based on the actual number of use cases adjusted by
the number of scenarios and the page length of the use cases. The
adjustment represents up to n percent of the historical average LOC
per use case.

An Example of Use-Case–Based Estimation:
The CAD software introduced in the above Section is
composed of three subsystem groups:
 user interface subsystem (includes UICF)- 6 use cases describe
the user interface subsystem. Each use case is described by no
more than 10 scenarios and has an average length of 6 pages.
 engineering subsystem group (includes the 2DGA, 3DGA, and
DAM subsystems)- The engineering subsystem group is
described by 10 use cases. Each of these use cases has no more
than 20 scenarios associated with it and has an average length
of 8 pages.
 infrastructure subsystem group (includes CGDF and PCF
subsystems)- the infrastructure subsystem group is described
by 5 use cases with an average of only 6 scenarios and an
average length of 5 pages.
Dept of CSE 99

 Using the relationship noted in Expression with n=30
percent, the table shown below is developed. Considering
the first row of the table, historical data indicate that UI
software requires an average of 800 LOC per use case when
the use case has no more than 12 scenarios and is described
in less than 5 pages.
 These data conform reasonably well for the CAD system.
Hence the LOC estimate for the user interface subsystem is
computed using expression (26.2). Using the same
approach, estimates are made for both the engineering and
infrastructure subsystem groups.
Dept of CSE 100

 The above table summarizes the estimates and indicates
that the overall size of the CAD is estimated at 42,500
LOC.
 Using 620 LOC/pm as the average productivity for systems
of this type and a burdened labor rate of $8000 per month,
the cost per line of code is approximately $13. Based on the
use-case estimate and the historical productivity data, the
total estimated project cost is $552,000 and the estimated
effort is 68 personmonths.
Dept of CSE 101

5.3 Empirical Estimation Models:
 An estimation model for computer software uses
empirically derived formulas to predict effort as a
function of LOC or FP.
 Values for LOC or FP are estimated using the approach
described in the above section 5.2.
5.3.1 The Structure of Estimation Models
 A typical estimation model is derived using regression
analysis on data collected from past software projects. The
overall structure of such models takes the form.
 where A, B, and C are empirically derived constants, E is
effort in person-months, and ev is the estimation variable
(either LOC or FP).
Dept of CSE 102

 Among the many LOC-oriented estimation models
proposed in the literature are
 FP-oriented models have also been proposed. These
include
Dept of CSE 103

6. Maintenance,
Reengineering,
Configuration
Management
Dept of CSE 104

6.1 Software Maintenance:
 Software maintenance is the process of changing,
modifying, and updating software to keep up with customer
needs.
 Software maintenance is done after the product has been
delivered to the customer.
 Software maintenance is a part of the Software
Development Life Cycle.
 Software maintenance include fixing bugs, adding new
features, improving performance, or updating the software
to work with new hardware or software systems.
 The goal of software maintenance is to keep the software
system working correctly, efficiently, and securely, and to
ensure that it continues to meet the needs of the users.
Dept of CSE 105

Need for Maintenance:Software Maintenance is needed
for:-
 Correct errors
 Change in user requirement with time
 Changing hardware/software requirements
 To improve system efficiency
 To optimize the code to run faster
 To modify the components
 To reduce any unwanted side effects.
 Improve the design.
 Implement enhancements.
 Interface with other systems.
Dept of CSE 106

Types of Software Maintenance:
 In a software lifetime, type of maintenance may vary based
on its nature. It may be just a routine maintenance tasks as
some bug discovered by some user or it may be a large
event.
 Types of Software Maintenance are
1. Corrective maintenance
2. Adaptive maintenance
3. Perfective maintenance
4. Preventive maintenance
Dept of CSE 107

 Corrective maintenance: Corrective maintenance of a
software product is to rectify bugs or errors observed by the
customer while the system is in use, or to enhance the
performance of the system.
 Adaptive maintenance: This includes modifications and
updations when the customers need the product to run on
new platforms, on new operating systems, or when they need
the product to interface with new hardware and software.
 Perfective maintenance: A software product needs
maintenance to support the new features that the users want
or to change different types of functionalities of the system
according to the customer demands.
 Preventive maintenance: This type of maintenance
includes modifications and updations to prevent future
problems of the software. It goals to attend problems, which
are not significant at this moment but may cause serious
issues in future. Dept of CSE 108

Software Maintenance Process:
The software maintenance process involves various software
maintenance techniques that can change according to the type
of maintenance.Most software maintenance process models
include the following steps:
Dept of CSE 109

1. Identification & Tracing – The process of determining
what part of the software needs to be modified (or
maintained). This can be user-generated or identified by the
software developer itself depending on the situation and
specific fault.
2. Analysis – The process of analyzing the suggested
modification including understanding the potential effects
of such a change. This step typically includes cost analysis to
understand if the change is financially worthwhile.
3. Design – Designing the new changes using requirement
specifications
4. Implementation – The process of implementing the
new modules by programmers.
5. System Testing – Before being launched, the software
and system must be tested. This includes the module itself,
the system and the module, and the whole system at once.
Dept of CSE 110

6. Acceptance Testing- Users test the modification for
acceptance. This is an important step as users can identify
ongoing issues and generate recommendations for more
effective implementation and changes.
7. Delivery - After acceptance test, the system is deployed all
over the organization either by small update package or
fresh installation of the system. The final testing takes place
at client end after the software is delivered. Training facility
is provided if required, in addition to the hard copy of user
manual.
8. Maintenance management - Configuration management
is an essential part of system maintenance. It is aided with
version control tools to control versions, semi-version or
patch management.
Dept of CSE 111

Cost of Maintenance:
 The cost of software maintenance can be high.
 In certain cases, software maintenance can cost up to two-
thirds of the entire software process cycle or more than 50%
of the SDLC processes.
Dept of CSE 112

The costs involved in software maintenance are due to
multiple factors and vary depending on the specific situation.
 The older the software, the more maintenance will cost, as
technologies (and coding languages) change over time.
Revamping an old piece of software to meet today’s
technology can be an exceptionally expensive process in
certain situations.
 Older softwares, which were meant to work on slow
machines with less memory and storage capacity cannot keep
themselves challenging against newly coming enhanced
softwares on modern hardware.
 In addition, engineers may not always be able to target the
exact issues when looking to upgrade or maintain a specific
piece of software. This causes them to use a trial and error
method, which can result in many hours of work.
Dept of CSE 113

 Often, changes made can easily hurt the original structure
of the software, making it hard for any subsequent
changes.
 Changes are often left undocumented which may cause
more conflicts in future.
 There are certain ways to try and bring down software
maintenance costs. These include optimizing the top of
programming used in the software, strong typing, and
functional programming.
 When creating new software as well as taking on
maintenance projects for older models, software
companies must take software maintenance costs into
consideration. Without maintenance, any software will be
obsolete and essentially useless over time.
Dept of CSE 114

6.2 Reengineering:
To Understand Reengineering let us discuss a small scenario:
Scenario: An application has served the business needs of a
company for 10 or 15 years. During that time it has been
corrected, adapted, and enhanced many times. People
approached this work with the best intentions, but good
software engineering practices were always shunted to the
side (due to the press of other matters). Now the application
is unstable. It still works, but every time a change is
attempted, unexpected and serious side effects occur. Yet
the application must continue to evolve. What to do?
Sol:We need to Reengineer the software to make it use.
 To make legacy software systems easier to maintain, you can
reengineer these systems to improve their structure and
understandability.
Dept of CSE 115

Def: Software 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.
 software re-engineering, is the process of analyzing,
designing, and modifying existing software systems to
improve their quality, performance, and maintainability. This
can include updating the software to work with new
hardware or software platforms, adding new features, or
improving the software’s overall design and architecture.
 Reengineering may involve redocumenting the system,
refactoring the system architecture, translating programs to a
modern programming language, and modifying and
updating the structure and values of the system’s data. The
functionality of the software is not changed and, normally,
you should try to avoid making major changes to the system
architecture. Dept of CSE 116

Software re-engineering can be initiated for various
reasons, such as:
 Improving software quality: Re-engineering can help
improve the quality of software by eliminating defects,
improving performance, and enhancing reliability and
maintainability.
 Updating technology: Re-engineering can help modernize
the software system by updating the technology used to
develop, test, and deploy the system.
 Enhancing functionality: Re-engineering can help
enhance the functionality of the software system by adding
new features or improving existing ones.
 Resolving issues: Re-engineering can help resolve issues
related to scalability, security, or compatibility with other
systems.
Dept of CSE 117

A Software Reengineering Process Model:
 Reengineering takes time, it costs significant amounts of
money, and it absorbs resources that might be otherwise
occupied on immediate concerns.
 For all of these reasons, reengineering is not accomplished
in a few months or even a few years.
 Reengineering of information systems is an activity that will
absorb information technology resources for many years.
 That’s why every organization needs a pragmatic strategy for
software reengineering.
 Reengineering is a rebuilding activity. To better understand
it, consider an analogous activity: the rebuilding of a house.
 Consider the following situation. You’ve purchased a house
in another state. You’ve never actually seen the property, but
you acquired it at an amazingly low price, with the warning
that it might have to be completely rebuilt. How would you
proceed? Dept of CSE 118

 Before you can start rebuilding, it would seem reasonable
to inspect the house. To determine whether it is in need of
rebuilding, you (or a professional inspector) would create
a list of criteria so that your inspection would be
systematic.
 Before you tear down and rebuild the entire house, be sure
that the structure is weak. If the house is structurally
sound, it may be possible to “remodel” without rebuilding
(at much lower cost and in much less time).
 Before you start rebuilding be sure you understand how
the original was built. Take a peek behind the walls.
Understand the wiring, the plumbing, and the structural
internals. Even if you trash them all, the insight you’ll gain
will serve you well when you start construction.
Dept of CSE 119

 If you begin to rebuild, use only the most modern, long-
lasting materials. This may cost a bit more now, but it will
help you to avoid expensive and time-consuming
maintenance later.
 If you decide to rebuild, be disciplined about it. Use
practices that will result in high quality—today and in the
future.
Dept of CSE 120

 software reengineering process model defines six
activities shown in Figure
Dept of CSE 121

1. Inventory Analysis:
 Every software organization should have an inventory of
all the applications
 Inventory can be nothing more than a spreadsheet
model containing information that provides a detailed
description (e.g., size, age, business criticality) of every
active application.
 By sorting this information according to business
criticality, longevity, current maintainability, and other
local important criteria, candidates for re-engineering
appear.
 The resource can then be allocated to a candidate
application for re-engineering work.
Dept of CSE 122

2. Document reconstructing:
Documentation of a system either explains how it operates or
how to use it.
 Documentation must be update,Full re-documentation of an
application may not be necessary. Rather, those portions of
the system that are currently undergoing change are fully
document.
 Over time, a collection of useful and relevant documentation
will evolve.
Dept of CSE 123

2. Reverse Engineering:
Reverse Engineering is also known as backward engineering, is
the process of forward engineering in reverse. In this, the
information are collected from the given or exist application. It
takes less time than forward engineering to develop an
application. In reverse engineering the application are broken
to extract knowledge or its architecture.
Reverse engineering is mostly use to deconstruct or test a product
to see how it works. It is mostly done by companies to evaluate
their competitor’s latest invention and create something new
out of it. it’s more like uncovering secrets of the product to
change it according to your needs. It involves prior knowledge
regarding the device followed by identifying the system
components and investigating relationship between them.
Dept of CSE 124

 Reverse engineering for software is quite similar. In most
cases, however, the program to be reverse engineered is
not a competitor’s. Rather, it is the company’s own work
(often done many years earlier).
 The “secrets” to be understood are obscure because no
specification was ever developed.
 Therefore, reverse engineering for software is the process
of analyzing a program in an effort to create a
representation of the program at a higher level of
abstraction than source code.
 Reverse engineering is a process of design recovery.
Reverse engineering tools extract data, architectural, and
procedural design information from an existing program.
Dept of CSE 125

4. Code Restructuring: The most common type of
reengineering is code restructuring.
 Some legacy systems have a relatively solid program
architecture, but individual modules were coded in a way
that makes them difficult to understand, test, and maintain.
In such cases, the code within the suspect modules can be
restructured.
 To accomplish this activity, the source code is analyzed
using a restructuring tool.
 Violations of structured programming constructs are noted
and code is then Restructured or even rewritten in a more
modern programming language.
 The resultant restructured code is reviewed and tested to
ensure that no anomalies have been introduced. Internal
code documentation is updated.
Dept of CSE 126

5. Data Restructuring: A program with weak data
architecture will be difficult to adapt and enhance. In fact,
for many applications, information architecture has more
to do with the long-term viability of a program than the
source code itself.
 Unlike code restructuring, which occurs at a relatively low
level of abstraction,data restructuring is a full-scale
reengineering activity. In most cases, data restructuring
 begins with a reverse engineering activity.
 Current data architecture is dissected, and necessary data
models are defined.
 Data objects and attributes are identified, and existing
data structures are reviewed for quality.
Dept of CSE 127

6. Forward Engineering: In an ideal world, applications
would be rebuilt using an automated “reengineering
engine.” The old program would be fed into the engine,
analyzed, restructured, and then regenerated in a form that
exhibited the best aspects of software quality.
 In the short term, it is unlikely that such an “engine” will
appear, but vendors have introduced tools that provide a
limited subset of these capabilities that addresses specific
application domains.
 The forward engineering process applies software
engineering principles, concepts, and methods to re-create
an existing application. In most cases, forward engineering
does not simply create a modern equivalent of an older
program. Rather, new user and technology requirements are
integrated into the reengineering effort. The redeveloped
program extends the capabilities of the older application.
Dept of CSE 128

6.3 Configuration Management:
 Whenever a software is build, there is always scope for
improvement and those improvements brings changes in
picture.
 Changes may be required to modify or update any existing
solution or to create a new solution for a problem.
 Requirements keeps on changing on daily basis and so we
need to keep on upgrading our systems based on the current
requirements and needs to meet desired outputs.
 Changes should be analyzed before they are made to the
existing system, recorded before they are implemented,
reported to have details of before and after, and controlled in
a manner that will improve quality and reduce error.
 This is where the need of software Configuration
Management comes.
Dept of CSE 129

 SCM is the discipline which
 Identify change
 Monitor and control change
 Ensure the proper implementation of change made to the
item.
 Auditing and reporting on the change made.
 Configuration Management (CM) is a technic of identifying,
organizing, and controlling modification to software being
built by a programming team. The objective is to
maximize productivity by minimizing mistakes
(errors).
Dept of CSE 130

SCM Process:
 Configuration management provides a disciplined
environment for smooth control of work products. It
involves the following activities:
Dept of CSE 131

 Identification and Establishment – Identifying the
configuration items from products that compose baselines
at given points in time. Establishing relationship among
items, creating a mechanism to manage multiple level of
control and procedure for change management system.
 Version control:
 Version Control involves a set of procedures and tools used to
manage and maintain various versions of configuration
objects generated during the software development process.
 In the context of Software Configuration Management
(SCM), version control is defined by Clemm as a means to
enable users to select and specify different configurations of
the software system through appropriate versions.
 This is achieved by associating specific attributes with each
software version and allowing users to construct a desired
configuration by selecting the desired attributes.
Dept of CSE 132

 Change Control : James Bach highlights the importance of
change control in the context of Software Configuration
Management (SCM), but acknowledges that it can also be a
challenging and frustrating process.
 Changes in software are closely monitored because even a
small error in code can result in significant product failure,
but it can also bring about improvements and new
capabilities.
 While there is a risk that a single developer could negatively
impact a project, creative ideas often come from these
individuals, and a burdensome change control process may
discourage such innovation.
 Change requests undergo technical evaluations to assess
their impact on other configuration objects, system
functions, and the projected cost of the change, with the
results presented in a change report.
Dept of CSE 133

 The final decision on the status and priority of the change is
made by a change control authority (CCA).
 The “check-in” and “check-out” process facilitates two
important elements of change control: access control, which
governs the software engineers who have permission to
modify a specific configuration object, and synchronization
control, which helps prevent conflicts between parallel
changes made by different individuals.
Dept of CSE 134

 Configuration Audit: In Software Configuration
Management (SCM), audits are conducted to ensure that
the software product meets the specified baseline
requirements and that there is consistency between what is
built and what is delivered.
 SCM audits also ensure that traceability is maintained
between all Configuration Items (CIs) and that all work
requests are associated with one or more CI modifications.
 SCM audits serve as “watchdogs” to ensure the preservation
of the project’s scope and integrity.
Dept of CSE 135

 Status Reporting: Configuration Status Reporting, also
known as status accounting, is the process of providing up-
to-date configuration data and accurate status information
to various stakeholders, including developers, testers, end-
users, customers, and other interested parties.
 This information can be shared through a variety of
resources, such as administrative guides, user guides,
frequently asked questions (FAQs), release notes,
installation guides, configuration guides, and other relevant
documentation.
Dept of CSE 136

Benefits of Software Configuration Management Process
 Multi-User Updates: SCM allows tracking of all code and
configurations deployed into production and provides traceability by
identifying the contributor for each update, enabling effective
collaboration among multiple developers.
Change Accommodation: SCM makes it easier to accommodate
changes in schedule, policy, and users, making the software development
process more flexible.
Platform and OS Testing: SCM ensures that the software runs
effectively across multiple platforms and operating systems, enhancing
its compatibility.
Productivity: SCM minimizes errors and ensures that test and
production environments match, enhancing productivity and software
quality.
Communication and Collaboration: SCM enables easy
communication and collaboration among team members and
stakeholders, improving the quality of the product.
 Cost Control: SCM helps to track team members and project workflow,
which results in increased efficiency, better cost control, and reduced
expenses. Dept of CSE 137

 Advantages of SCM
 Increased Productive Efficiency: SCM helps to control and
track the software development process, resulting in increased
productive efficiency.
 Change Management: SCM allows for effective change
management, reducing the risk of the product.
 Monitoring and Auditing: SCM enables proper monitoring
and auditing of the software development product, ensuring its
quality.
 Enhanced Software Development Life Cycle Process: SCM
enhances the software development life cycle process, improving
the overall quality of the product.
 Reliable, Organized, Cost-effective, and Low-risk: SCM
provides a reliable, organized, cost-effective, and low-risk
software development application.
 High-quality Software Product: SCM ensures the delivery of
high-quality software products.
Dept of CSE 138

Disadvantages of Software Configuration Management
 Implementing software configuration management
requires significant resources, including a team with
expertise in SCM tools and processes.
 Small industries may find it challenging to allocate the
necessary resources to implement SCM effectively.
 Development stages may require high-performance
hardware to support SCM tools and processes.
Dept of CSE 139

Hard work matters for everyone in everytbing

More Related Content

Similar to Hard work matters for everyone in everytbing (20)

Recently uploaded (20)

Hard work matters for everyone in everytbing