UNIT- V

Software quality, reliability, and other issues Software project

management: Software reliability, Statistical testing, Software quality and
management, ISO 9000, SEI capability maturity model (CMM), Personal software
process (PSP), Six sigma, Software quality metrics.
CASE and its scope, CASE environment, CASE support in software life cycle,
Characteristics of software maintenance, Software reverse engineering, Software
maintenance processes model, Estimation maintenance cost. Basic issues in any
Reuse program, Reuse approach ,Reuse at organization level.

SOFTWARERELIABILITY
The reliability of a software product essentially denotes its trustworthiness or dependability.
Alternatively, the reliability of a software product can also be defined as the probability of the
product working “correctly” over a given period of time.
Softwarereliabilityis defined as the probabilityof failure-free operationofa software systemfor a
specified time in a specified environment.
FactorsInfluencingSoftwareReliability
 Auser’sperceptionofthereliabilityofasoftwaredependsupontwocategoriesof information.
o Thenumber offaultspresentinthe software.
o [Link] profile.
 Thefaultcountinasystemis influencedbythefollowing.
o Sizeand complexityofcode.
o Characteristicsofthedevelopmentprocessused.
o Education,experience,andtrainingofdevelopment personnel.
 o Operationalenvironment
Thereliability requirementsfordifferentcategoriesof softwareproductsmaybedifferent.A
goodreliabilitymeasureshouldbeobserver-independent,sothatdifferentpeoplecanagreeon
[Link] reliability
measurement would be possible. Six metrics that correlate with reliability as follows:

Rate of occurrence of failure (ROCOF): ROCOF measures the frequency of occurrence of

failures. ROCOF measure of a software product can be obtained by observing the behavior of a
softwareproductinoperationoveraspecifiedtimeintervalandthencalculatingtheROCOFvalue as the
ratio of the total number of failures observed and the duration of observation.

Meantimetofailure(MTTF):MTTFisthetimebetweentwosuccessivefailures,averagedover
[Link],wecanrecordthefailuredatafornfailures. Letthe failures
occur at the time instants t 1, t2, ..., tn. Then, MTTF can be calculated as

Meantimetorepair(MTTR):Oncefailureoccurs,[Link] measures
the average time it takes to track the errors causing the failure and to fix them.

Meantimebetweenfailure(MTBF):TheMTTFandMTTRmetricscanbecombinedtogetthe MTBF
metric: MTBF=MTTF+MTTR. Thus, MTBF of 300 hours indicates that once afailure occurs, the
next failure is expected after 300 hours. In this case, the time measurements are real time and not the
execution time as in MTTF.

Probabilityoffailureondemand(POFOD):Thismetricdoesnotexplicitlyinvolvetimemeasurements.
POFOD measures the likelihood of the system failing when a service request is made. For example, a
POFOD of 0.001 would mean that 1 out of every 1000 servicerequests would result in a failure. POFOD
metric is very appropriate for software products that are not required to run continuously.

Availability:Availabilityofasystemisameasureofhowlikelywouldthesystembeavailableforuseover a given
period of time. This metric not only considers the number of failures occurring during a time interval, but
also takes into account the repair time (down time) of a system when a failure occurs. This
metricisimportantforsystemssuchastelecommunicationsystems,andoperatingsystems,and
 embedded controllers, etc. which are supposed to be never down and where repair and restart time are
significant and loss of service during that time cannot be overlooked.

STATISTICALTESTING
Statisticaltestingisatestingprocesswhoseobjectiveistodeterminethereliabilityoftheproduct rather than
discovering errors. The test cases designed for statistical testing with an entirely different objective
fromthose ofconventionaltesting. To carryout statisticaltesting, we need to first define the operation
profile of the product.
Operation profile: Different categories of users may use a software product for very different
purposes. For example, a librarian might usethe Library AutomationSoftwareto create member
records, delete member records, add books to the library, etc., whereas a library member might
usesoftwaretoqueryabouttheavailabilityofabook,[Link],we can define
the operation profile of a software as the probability of a user selecting the different functionalities
of the software.
StepsinStatisticalTesting
The first step is to determine the operation profile ofthe software. The next step is to generate a
[Link] cases to the
software and record the time between each failure. After a statisticallysignificant number of failures
have been observed, the reliability can be computed.
For accurate results, statisticaltesting requires some fundamental assumptions to be satisfied.
[Link] percentage
oftest inputsthat are likelyto cause systemfailure to be included. Now let usdiscuss the implications
of these assumptions.
Itisstraightforwardtogeneratetestcasesforthecommontypesofinputs,sinceonecaneasily writeatest
casegeneratorprogramwhichcanautomaticallygeneratethesetest [Link],it is also required that
a statistically significant percentage of the unlikely inputsshould also be
[Link].
SOFTWAREQUALITY
[Link],agoodqualityproduct does exactly
what the users want it to do, since for almost every product, fitness of purpose is interpreted in terms
of satisfaction of the requirements laid down in the SRS document. The modernview ofa
qualityassociates witha software product severalqualityfactors (or attributes) such as the following:
Portability:Asoftwareproductissaidtobeportable,ifitcanbeeasilymadetoworkindifferent
hardwareandoperatingsystemenvironments,andeasilyinterfacewithexternalhardwaredevices and
software products.
Usability: Asoftwareproduct hasgoodusability, ifdifferent categoriesofusers(i.e., bothexpert and
novice users) can easily invoke the functions of the product.
Reusability:Asoftwareproducthasgoodreusability, ifdifferent modulesoftheproductcan easily be
reused to develop new products.
Correctness:A softwareproductiscorrect,if differentrequirementsasspecifiedin theSRS document have
been correctly implemented.
Maintainability:Asoftwareproductismaintainable,iferrorscanbeeasilycorrectedasandwhen they show
up, new functions can be easily added to the product, and the functionalities of the product can be
easily modified, etc.
McCall’squalityfactors
[Link]-levelattributes,knownasquality factor sor
externalattributes can only be measured indirectly. The second-levelqualityattributes are called
quality criteria. Quality criteria can be measured directly, either objectively or subjectively.
ISO9126
ISO9126 defines a set of hierarchical quality characteristics. Each sub characteristic in this is related to
exactly one quality characteristic. This is in contrast to the McCall’s quality attributes that are heavily
interrelated. Another difference is that theISO characteristic strictly refers toa softwareproduct, whereas
McCall’s attributes capture process quality issues as well.
SOFTWARE QUALITYMANAGEMENTSYSTEM
A quality management system is the principal methodologyused byorganizations to ensure that the
products they develop have the desired quality. In the following subsections, The following are some
of the important issues associated with a quality system.
Managerialstructureandindividualresponsibilities
[Link],everyorganization
hasaseparatequalitydepartment to performseveralqualitysystemactivities. Thequalitysystem of an
organization should have the full support of the top management. Without support for the quality
system at a high level in a company, few members of staff will take the quality system seriously.
Qualitysystemactivities
Thequalitysystemactivitiesencompassthefollowing:
o Auditingofprojectstocheckiftheprocessesarebeingfollowed.
o Collectprocessandproduct metricsandanalyzethemto check ifqualitygoalsare
beingMet
o Reviewofthequalitysystemto makeitmore effective.
o Developmentofstandards,procedures,andguidelines.
o Producereportsforthetopmanagement summarizingtheeffectivenessofthe
quality system in the organization.
EvolutionofQualitySystems
Qualitysystemshaverapidlyevolvedoverthelastsixdecades. Prior toWorldWarII,theusualmethodto produce
quality products was to inspect the finished products to eliminate defective products. Quality systems
oforganizations have undergone four stages ofevolution. The initialproduct inspection method
gave way to quality control (QC) principles.
Qualitycontrol(QC) focusesnot onlyondetecting the defective productsand eliminating them, but
also on determining the causes behind the defects, so that the product rejection rate can be reduced.

Figure:Evolutionofqualitysystemandcorrespondingshiftinthequalityparadigm.
 Thus, qualitycontrolaimsat correcting thecauses oferrorsand not just rejecting thedefective
[Link],wasthe developmentofthequalityassurance (QA)
principles.
The modern quality assurance paradigm includes guidance for recognizing, defining, analyzing, and
improving the production process. Total quality management (TQM) advocates that the process
followed by an organization must continuously be improved through process measurements. TQM
goes a step further than quality assurance and aims at continuous process
[Link] documenting processesto optimizing themthroughredesign. A term
related to TQM is business process re-engineering (BPR), which is aims at re-engineering the
waybusiness iscarried out inanorganization, whereasourfocus inthistext isre-engineering of the
software development process.
ProductMetricsversusProcessMetrics
Product metrics help measure the characteristics ofa product being developed, whereas process
metrics help measure how a process is performing.
Examplesofproduct metricsareLOCand functionpoint to measuresize, PM(person- month)to measure
the effort required to develop it, months to measure the time required to develop the product, time
complexity of the algorithms, etc.
Examples ofprocess metrics are review effectiveness, average number ofdefects found per hour of
inspection, average defect correction time, productivity, average number of failures detected during
testing per LOC, number of latent defects per line of code in the developed product.
ISO9000
Internationalstandardsorganization(ISO)isaconsortiumof63countriesestablishedtoformulate and
foster standardization. ISO published its 9000 series of standards in 1987.
ISO9000 certification serves as a reference for contract between independent parties. The ISO 9000
standard specifies the guidelines for maintaining a quality system. The ISO standard addresses both
operational aspects (that is, the process) and organizational aspects such as responsibilities,
reporting, etc.
ISO9000 isaseriesofthreestandards—ISO 9001,ISO9002,and ISO 9003.
ISO9001:Thisstandardappliestotheorganizationsengagedindesign,development,production, and
servicing of goods. This is the standard that is applicable to most software development
organizations.
ISO9002:Thisstandardappliestothoseorganizationswhichdonotdesignproductsbutareonly
[Link]
industries who buythe product and plant designs fromexternal sources and are involved in only
manufacturing those products. Therefore, ISO 9002 is not applicable tosoftware development
organizations.
ISO 9003: This standard applies to organizations involved only in installation and testing of
products.
ISO9000forSoftware Industry
ISO9000isagenericstandardthatisapplicabletoalargetypesofindustries,startingfromasteel
[Link],manyoftheclausesoftheISO
9000documentsarewrittenusinggenericterminologiesandit isverydifficulttointerpretthemin
[Link]
thefactthatsoftwaredevelopmentisinmanyrespectsradicallydifferentfromthedevelopmentof other types
ofproducts. Two major differences between software development and development of other kinds
of products are as follows:
 Software is intangible and therefore difficult to control. It means that software would not
bevisibletotheuseruntilthedevelopmentiscompleteandthesoftwareisupandrunning. It is
difficult to controland manage anything that you cannot see and feel. In contrast, in
anyothertypeofproductmanufacturingsuchascarmanufacturing, youcanseeaproduct being
developed through various stages such as fitting engine, fitting doors, etc.
 During software development, the only raw material consumed is data. In contrast, large
[Link] an
example, consider a steel making company. The company would consume large
amountsofrawmaterialsuchasiron-ore,coal,lime,manganese,[Link],
manyclausesofISO9000standardsareconcerned withrawmaterialcontrol. Theseclauses are
obviously not relevant for software development organizations.
ISO9000Certification
TheISO9000registrationprocessconsistsofthefollowing stages:
Applicationstage: Onceanorganizationdecidestogo forISO9000certification, it appliestoa registrar for
registration.
Pre-assessment: During this stage the registrar makes a rough assessment ofthe organization.
Documentreviewandadequacyaudit: Duringthisstage,theregistrarreviewsthedocuments submitted by
the organization and makes suggestions for possible improvements.
Complianceaudit:Duringthisstage,theregistrarcheckswhetherthesuggestionsmadebyit during review
have been complied to by the organization or not.
Registration:TheregistrarawardstheISO9000 certificateaftersuccessfulcompletionofall previous phases.
Continuedsurveillance: Theregistrarcontinuesmonitoringtheorganizationperiodically.
In India, ISO 9000 certification is offered by BIS (Bureau of Indian Standards), STQC
(Standardization, testing, and qualitycontrol), andIRQS (IndianRegister QualitySystem). IRQS has
been accredited by the Dutch council of certifying bodies (RVC).

SEICAPABILITYMATURITYMODEL
SEIcapabilitymaturitymodel(SEICMM)wasproposedbySoftwareEngineeringInstituteofthe Carnegie
MellonUniversity, USA. CMM ispatterned afterthe pioneering workofPhilip Crosby who published
his maturitygrid of five evolutionary stages in adopting quality practices.
[Link](DoD)insoftware
acquisition.
In simple words, CMM is a reference model for apprising the software process maturity into
different levels. This canbe usedto predict the most likelyoutcome to be expected fromthe next
[Link] ways—
[Link]
softwareprocessassessmentdifferinmotivation,objective,andthefinaluseoftheresult.
Capabilityevaluationprovidesawaytoassessthesoftwareprocesscapabilityofanorganization. The
different levels of SEI CMM have been designed so that it is easy for an organization to
[Link]
industriesintothefollowingfivematuritylevels:
Level 1: Initial — Few processes are defined, and success depends more on individual heroic
efforts than on following a process and using a synergistic team effort.
Level2:Repeatable—Basicprojectmanagementprocessesareestablishedtotrackcost,schedule, and
functionality. Planning and managing new products is based on experience with similar projects.
Level3:Defined—Processesformanagementandengineeringaredocumented,standardized,and
integrated into a standard software process for the organization. All projects use anapproved, tailored
version of the organization’s standard software process for developing software.
Level 4 : Managed—Detailed software process and product quality metrics establish the quantitative
evaluation foundation. Meaningful variations in process performance can be distinguished from
random noise, and trends in process and product qualities can be predicted.
Level 5 : Optimized—The organization has quantitative feedback systems in place to identify
processweaknessesand strengthenthempro-actively. Project teamsanalyze defectsto determine
theircauses;softwareprocessesareevaluatedandupdatedtopreventknowntypesofdefectsfrom recurring.
CMMLevel Focus KeyProcessAreas(KPAs)
Initial Competentpeople
Repeatable Projectmanagement Softwareprojectplanning
Softwareconfigurationmanagement
Definitionof Processdefinition
Defined processes Trainingprogram
Peerreviews
Productand Quantitativeprocessmetrics
Managed
processquality Softwarequalitymanagement
Defectprevention
Continuousprocess
Optimising Processchangemanagement
improvement
Technologychangemanagement
CMMShortcomings:[Link] are the
following:
 The most frequent complaint by organisations while trying out the CMM-based process
improvement initiative is that they understand what is needed to be improved, but they
need more guidance about how to improve it.
 Another shortcoming (that is common to ISO 9000) is that thicker documents, more
detailed information, and longer meetingsareconsidered [Link] is incontrast
 to the principles of software economics—reducing complexity and keeping the
documentation to theminimum without sacrificing the relevant details.
 Getting an accurate measure of an organisation’s current maturity level is also an issue.
TheCMMtakesanactivity-basedapproachtomeasuringmaturity;ifyoudotheprescribed set of
activities then you are at a certain level. There is nothing that characterises or quantifies
whether you do these activities well enough to deliver the intended results.
CapabilityMaturityModelIntegration(CMMI)
Capability maturity model integration (CMMI) is the successor of the capability maturity model
(CMM). The CMM was developed from 1987 until 1997. In 2002, CMMI Version 1.1 was
[Link] by
integrating many different models into one framework.
After CMMI was first released in 1990, it wasadopted and used in manydomains. For example,
CMMs were developed for disciplines such as systems engineering (SE-CMM), people management
(PCMM), software acquisition (SA-CMM), and others. Although many organizations found these
models to be useful, they also struggled with problems caused by overlap, inconsistencies, and
integrating the models. In this context, CMMI is generalized to be applicable to many domains.
PersonalSoftwareProcess(PSP)
PSP is based on the workofDavid [Link] is suitable for individualuse. It is important to note
that SEI CMM does not tell software developers how to analyze, design, code, test, or document
software products, but assumes that engineers use effective personal practices. PSP recognizes that
the process for individual use is different from that necessary for a team.
PSP is a framework that helps engineers to measure and improve the way they work. It helps in
developingpersonalskillsandmethodsbyestimating,planning,andtrackingperformanceagainst plans,

and provides a defined process which can be tuned by individuals.

Timemeasurement:PSPadvocatesthatdevelopersshouldrackthewaytheyspendtime.
Because,[Link],
theactualtimespentonataskshouldbemeasuredwiththehelpofastop-watchtogetanobjective picture of
the time spent.
PSP Planning: Individuals must plan their project. Unless an individual properly plans his activities,
disproportionately higheffort maybespent ontrivialactivitiesand important activities
maybecompromised,[Link],
minimum, and the average LOC required for the product. They should use their productivity in
minutes/LOCtocalculatethemaximum,minimum,[Link] record
the plan data in a project plan summary.
The PSP is schematically shown in following figure. While carrying out the different phases, an
individual must record the log data using time measurement. During post-mortem, they can compare
the log data with their project plan to achieve better planning in the future projects, to improve his
process, etc.

Figure:AschematicrepresentationofPSP
The PSP levels are summarized in following figure. PSP2 introduces defect management via the
use of checklists for code and design reviews. The checklists are developed by analyzing the defect
data gathered from earlier projects.

Figure:LevelsofPSP
SIXSIGMA
GeneralElectric(GE)corporationfirstbeganSixSigma in1995afterMotorolaandAlliedSignal blazed
the SixSigma [Link] purposeofSixSigma isto improve processesto dothings better, faster, and
at lower cost. It can be used to improve every facet of business, from production, to
humanresources, to order entry, totechnicalsupport. SixSigma canbe used for anyactivitythat is
concerned with cost, timeliness, and quality of results. Therefore, it is applicable to virtually
every industry.
Six Sigma at many organizations simply means striving for near perfection. Six Sigma is a
disciplined, data-driven approach to eliminate defects in any process – from manufacturing to
transactional and from product to service.
The statistical representation of Six Sigma describes quantitatively how a process is performing.
To achieve Six Sigma, a process must not produce more than 3.4 defects per million
opportunities. A Six Sigma defect is defined as any system behavior that is not asper customer
specifications. Totalnumber ofSixSigma opportunities is then the totalnumber ofchances for a
defect. Process sigma can easily be calculated using a Six Sigma calculator.
The fundamental objective of the Six Sigma methodology is the implementation of a
measurement-basedstrategythatfocusesonprocessimprovementandvariationreductionthrough the
applicationofSixSigma improvement projects. This is accomplished throughtheuseoftwo Six
Sigma sub-methodologies—DMAIC and DMADV.
The Six Sigma DMAIC process (define, measure, analyze, improve, control) is an
improvementsystemforexistingprocessesfallingbelowspecificationandlookingforincremental
[Link] SixSigma DMADV process(define, measure, analyze, design, verify)
isan improvement
[Link]
SixSigmaprocessesareexecutedbySixSigmaGreenBeltsandSixSigmaBlackBelts,andare
overseen by Six Sigma Master Black Belts.

CASE AND ITS SCOPE

A CASE tool is a generic term used to denote any form of automated support for software
engineering,Inamorerestrictivesensea CASE tool can mean any tool used to automatesome
activityassociated with software development. Many CASE tools are [Link] these
tools assist in phase-related tasks such as specification, structured analysis, design, coding,
testing, etc. and others to non-phase activities such as project management and configuration
management. The primary objectives in using any CASE tool are:
 Toincreaseproductivity
  Tohelpproducebetterqualitysoftwareatlowercost
CASEENVIRONMENT
CASEtoolsarecharacterizedbythestageorstagesofsoftwaredevelopmentlifecycleonwhich
[Link],itisrequired that
they integrate through some central repository to have a consistent view of information
associated with the software. CASE environment facilitates the automation of the step-by-step
methodologies for software development. In contrast to a CASE environment, a programming
environment is an integrated collection of tools to support only the coding phase of software
development. The tools commonly integrated in a programming environment are a text editor, a
compiler, and a debugger. The different tools are integrated to the extent that once the compiler
detects an error, the editor takes automatically goes to the statements in error and the error
statements are highlighted. Examples of popular programming environments are Turbo C
environment, Visual Basic, Visual C++, etc. A schematic representation ofa CASE environment
is shown in following figure.
 Figure:A CASE environment
BenefitsofCASE
Severalbenefitsaccrue fromtheuseofaCASE environmentoreven isolatedCASE tools. Some of
these benefits are:
 A key benefit arising out of the use of a CASE environment is cost saving through all
[Link],putthe effort
reduction between 30 per cent and 40 per cent.
 Use of CASE tools leads to considerable improvements in quality. This is mainly due to
the facts that one can effortlessly iterate through the different phases of software
development, and the chances of human error is considerably reduced.
 [Link]
relating to a software product are maintained in a central repository, redundancy in the
storeddataisreduced,andtherefore,achanceofinconsistentdocumentationisreducedto a great
extent.
  [Link],they need
not check meticulouslythe balancing of the DFDs,but can do it effortlesslythrough the
press of a button.
 CASE tools have led to revolutionary cost saving in software maintenance efforts. This
arises not only due to the tremendous value of a CASE environment in traceability and
consistencychecks, but also due to the systematic information capture during the various
phases of software development as a result of adhering to a CASE environment.
 IntroductionofaCASEenvironmenthasanimpactonthestyleofworkingofacompany, and
makes it oriented towards the structured and orderly approach.
CASESUPPORTINSOFTWARELIFECYCLE
CASE tools should support a development methodology, help enforce the same, and provide
certain amount of consistency checking between different phases. Some of the possible supports
that CASE tools usually provide in the software development life cycle are :
PrototypingSupport
TheprototypingCASEtool’srequirementsareasfollows:
 Defineuserinteraction.
 Definethesystemcontrolflow.
 Storeand retrievedatarequiredbythe system.
 Incorporatesomeprocessinglogic.
There are severalstand alone prototyping tools. But atoolthat integrates withthe data dictionary
canmakeuseoftheentriesinthedatadictionary,helpinpopulatingthedatadictionaryandensure the
consistency between the design data and the prototype.
Agoodprototypingtoolshouldsupportthefollowingfeatures:
 Since one of the main uses of a prototyping CASE tool is graphical user interface (GUI)
development, a prototyping CASE tool should support the user to create a GUI using a
graphics editor. The user should be allowed to define all data entry forms, menus and
controls.
 Itshouldintegrate withthedata dictionaryofaCASEenvironment.
 If possible, it should be able to integrate with external user defined modules written in C
or some popular high level programming languages.
  Theusershouldbeabletodefinethesequenceofstatesthroughwhichacreatedprototype can run.
The user should also be allowed to control the running of the prototype.
 The run time system of prototype should support mock up run of the actual system and
management of the input and output data.
StructuredAnalysisand Design
Several diagramming techniques are used for structured analysis and structured design. A CASE
tool should support one or more of the structured analysis and design technique. The CASE tool
should support effortlesslydrawinganalysisand designdiagrams. TheCASE toolshouldsupport
drawing fairly complex diagrams and preferably through a hierarchy of levels. It should provide
easy navigation through different levels and through design and analysis. The tool must support
completeness and consistency checking across the design and analysis and through all levels of
[Link],thesystemshoulddisallowanyinconsistentoperation, but it
may be very difficult to implement such a feature. Whenever there is heavy computational
loadwhileconsistencychecking,itshouldbepossibletotemporarilydisableconsistencychecking.
Code Generation
Asfaras code generation isconcerned,the generalexpectation fromaCASEtoolisquitelow. A
reasonable requirement is traceability from source file to design data. More pragmatic support
expected from a CASE tool during code generation phase are the following:
 TheCASEtoolshouldsupportgenerationofmoduleskeletonsortemplatesinoneormore
[Link],briefdescriptionof the
module, author name and the date of creation in some selectableformat.
 The tool should generate records, structures, class definition automatically from the
contents of the data dictionary in one or more popular programming languages.
 Itshouldgeneratedatabasetablesforrelationaldatabasemanagementsystems
 The tool should generate code for user interface from prototype definition for X window
and MS window based applications.
TestCase Generator
TheCASEtoolfortest casegenerationshould havethefollowingfeatures
 Itshouldsupportbothdesignandrequirement testing
 ItshouldgeneratetestsetreportsinASCIIformatwhichcanbedirectlyimported into
the test plan document.

CHARACTERISTICSOFSOFTWAREMAINTENANCE
[Link] the
hardware platform changes and a software product perform some low-level functions,
[Link],wheneverthesupportenvironmentofasoftwareproductchanges,
[Link],asoftware product
may need to be maintained when the operating system changes. Thus, every software product
continues to evolve after its development through maintenance efforts.
TypesofSoftwareMaintenance
There are three types of software maintenance, which are described as follows:
Corrective:Correctivemaintenanceofasoftwareproductisnecessaryeithertorectifythebugs
observed while the system is in use.
Adaptive: A software product might need maintenance when the customers need the product to
runonnew platforms, on newoperating systems, or whentheyneed the productto interface with
new hardware or software.
Perfective: A software product needs maintenance to support the new features that users want it
to support,tochangedifferent functionalities ofthesystemaccording to customer demands, orto
enhance the performance of the system.
CharacteristicsofSoftwareEvolution
LehmanandBeladyhavestudiedthecharacteristicsofevolutionofseveralsoftwareproducts.
[Link] the
following subsection.
Lehman’s first law: A software product must change continually or become progressively less
useful. Every software product continues to evolve after its development through maintenance
[Link]
therefore tend to incur higher maintenance efforts. This law clearly shows that everyproduct
irrespective of how well designed must undergo maintenance. In fact, when a product does not
needanymoremaintenance,itisasignthattheproductisabouttoberetired/[Link] contrast
to the common intuition that only badly designed products need maintenance. In fact, good
products are maintained and bad products are thrown away.
Lehman’s second law: The structure of a program tends to degrade as more and more
maintenance is carried out on it. The reason for the degraded structure is that when you add a
function during maintenance, you build on top of an existing program, often in a way that the
[Link],theadditionswill be more
complex that they should be. Due to quick-fix solutions, in addition to degradation of structure,
the documentations become inconsistent and become less helpful as more and more maintenance
is carried out.
Lehman’s third law: Over a program’s lifetime, its rate of development is approximately
constant. The rate of development can be quantified in terms of the lines of code written or
modified. Therefore this law states that the rate at which code is written or modified is
approximately the same during development and maintenance.
SOFTWAREREVERSEENGINEERING
Software reverse engineering is the process of recovering the design and the requirements
specification of a product from an analysis of its code. The purpose of reverse engineering is to
facilitate maintenance work by improving the understandability of a system and to produce the
necessary documents for a legacy system. Reverse engineering is becoming important, since
legacy software products lack proper documentation, and are highly unstructured.
The first stage of reverse engineering usually focuses on carrying out cosmetic changes to the
code to improve its readability, structure, and understandability, without changing any of its
functionalities. A way to carry out these cosmetic changes is shown schematically in following
figure.
Aprogramcanbereformattedusinganyoftheseveralavailableprettyprinterprogramswhich layout
the program neatly. Many legacy software products are difficult to comprehend with complex
control structure and unthoughtful variable names. All variables, data structures, and functions
should be assigned meaningful names wherever possible. Complex nested conditionals
intheprogramcanbereplacedbysimplerconditionalstatementsorwheneverappropriatebycase
statements.
 Figure:Aprocessmodelforreverseengineering
After thecosmetic changeshave beencarried out on legacysoftware, theprocess ofextracting the
code, design, and the requirements specification canbegin. These activities areschematically
[Link],afullunderstandingofthecodeisneeded.
Someautomatictoolscanbeusedtoderivethedataflowandcontrolflowdiagramfromthecode. The
structure chart (module invocation sequence and data interchange among modules) should also
be extracted. The SRS document can be written once the full code has been thoroughly
understood and the design extracted.

Figure:Cosmeticchangescarriedoutbeforereverseengineering
SOFTWAREMAINTENANCEPROCESSMODELS
The activities involved in a software maintenance project are not unique and depend on several
factors such as: (i) the extent of modification to the product required, (ii) the resources available
tothemaintenanceteam,(iii)theconditionsoftheexistingproduct(e.g.,howstructureditis,how well
documented it is, etc.), (iii) the expected project risks, etc. When the changes needed to a
softwareproductareminorandstraightforward,thecodecanbedirectlymodifiedandthechanges
appropriately reflected in all the documents.
Twobroadcategoriesofprocessmodelscanbeproposed.
Firstmodel
Thefirstmodelispreferredforprojectsinvolvingsmallreworkswherethecodeischangeddirectly and
the changes are reflected in the relevant documents later. This maintenance process is graphically
presented in following figure. In this approach, the project starts by gathering the requirements
for changes. The requirements are next analyzed to formulate the strategies to be adopted for
code change. At this stage, the association of at least a few members of the original development
team goes a long way in reducing the cycle time, especially for projects involving unstructured
and inadequately documented code. The availability of a working old system to the
maintenanceengineersatthemaintenancesitegreatlyfacilitatesthetaskofthemaintenanceteam
astheygetagoodinsightintotheworkingoftheoldsystemandalsocancomparetheworkingof
[Link],debuggingofthere-engineeredsystembecomes easier
as the program traces of both the systems can be compared to localize the bugs.

Figure:Maintenanceprocessmodel1
Secondmodel
The second model is preferred for projects where the amount of rework required is significant.
This approach can be represented by a reverse engineering cycle followed by a forward
[Link] is
depicted in following figure.

Figure:Maintenanceprocessmodel2
The reverse engineering cycle is required for legacyproducts. During the reverse engineering,
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
requirementsspecificationto arriveat thenewrequirementsspecification. At thispoint aforward
[Link],modulespecification,andcoding a
substantialreuse is made fromthe reverse engineered products. An important advantage of this
approach is that it produces a more structured design compared to what the original product had,
produces good documentation, and very often results in increased efficiency.
Besidestheamountofrework, severalotherfactorsmight affectthedecisionregardingusing
process model 1 over process model 2 as follows:
o Re-engineeringmightbepreferableforproductswhichexhibit ahighfailurerate.
 Re-engineering might also be preferable for legacyproducts havingpoordesignand code
structure
ESTIMATIONOFMAINTENANCECOST
Boehm proposed a formula for estimating maintenance costs as part of his COCOMO cost
estimation model. Boehm’s maintenance cost estimation is made in termsofaquantitycalled the
annual change traffic (ACT). Boehm defined ACT as the fraction of a software product’s source
instructions which undergo change during a typical year either through addition or deletion.

where, KLOC added is the total kilo lines of source code added during [Link]
[Link],thecodethatischanged,should be counted
in both the code added and code deleted.
The annual change traffic (ACT) is multiplied with the total development cost to arrive at the
maintenance cost:
Maintenancecost=ACT×Developmentcost
Mostmaintenancecostestimationmodels,however,giveonlyapproximateresultsbecausethey do
not take into account several factors such as experience level of the engineers, and familiarity of
the engineers with the product, hardware requirements, software complexity, etc.

BASICISSUESINANYREUSEPROGRAM
Thefollowingaresomeofthebasicissuesthatmustbeclearlyunderstood forstartinganyreuse program:
 Componentcreation
 Component indexingandstoring
 Componentsearch
 Componentunderstanding
 Componentadaptation
 Repositorymaintenance
Componentcreation:Forcomponentcreation,thereusablecomponentshavetobefirst identified.
Selection of the right kind of components having potential for reuse is important.
Componentindexingandstoring : Indexingrequiresclassificationofthereusablecomponents so
thattheycan beeasilysearchedwhen welookfora [Link] components need to be
stored in a relational database management system (RDBMS) or an object-oriented database
system (ODBMS) for efficient access when the number of components becomes large.
Component searching :The programmers need to search for right components matching their
[Link],the programmers
require a proper method to describe the components that they are looking for.
Component understanding : The programmersneed a preciseand sufficiently
complete understandingofwhat the component does to beable to decide whethertheycan reuse
[Link],thecomponentsshouldbewelldocumentedand should do
something simple.
Componentadaptation :Often, thecomponentsmayneedadaptation beforetheycanbereused, since
a selected component maynot exactlyfit the problem at hand. However, tinkering with the code is
also not a satisfactory solution because this is very likely to be a source of bugs.
Repository maintenance : A component repository once is created requires continuous
maintenance. New components, as and when created have to be entered into the repository. The
faulty components have to be tracked. Further, when new applications emerge, the older
applications become obsolete. In this case, the obsolete components might have to be removed
from the repository.
REUSEAPPROACH
Apromisingapproachthatisbeingadoptedbymanyorganizationsistointroduceabuildingblock
approach into the software development process. For this, the reusable components need to be
identified after every development project is completed. The reusability of the identified
componentshastobeenhanced andthese havetobecataloged intoacomponentlibrary. Domain
analysis is a promising approach to identify reusable components.

DomainAnalysis
Theaimofdomainanalysisistoidentifythereusable componentsfor aproblemdomain.
Reusedomain
A reuse domain is a technically related set of application areas. A body of information is
considered to be a problem domain for reuse, if a deep and comprehensive relationship exists
among theinformation items as characterizedby patterns of similarity among the development
components of the software product. A reuse domain is a shared understanding of some
community, characterized byconcepts,techniques, andterminologiesthat showsome coherence.
Examples of domains are accounting software domain, banking software domain, business
software domain, manufacturing automation software domain, telecommunication software
domain, etc.
Domain analysis identifies the objects, operations, and the relationships among them. For
example,considertheairlinereservationsystem,thereusableobjectscanbeseats,flights,airports, crew,
meal orders, etc. The reusable operations can be scheduling a flight, reserving a seat, assigning
crew to flights, etc. We can see that the domain analysis generalizes the application domain. A
domain model transcends specific applications. The common characteristics or the similarities
between systems are generalized.
Analysis ofthe application domain is required to identifythe reusable components. The actual
construction of the reusable components for a domain is called domain engineering.

Evolutionofareusedomain
The ultimate results of domain analysis is development of problem-oriented languages. The
problem-oriented languages are also known as application generators. These application
generators,[Link]. A s
a domain develops, we may distinguish the various stages it undergoes:
Stage1:[Link],noreusablecomponentsare
available. All software is written from scratch.
Stage2:Here,[Link] that
there is only knowledge reuse.
Stage 3: At this stage, the domain is ripe for reuse. The set of concepts are stabilized and the
notations standardized. Standard solutions to standard problems are available. There is both
knowledge and component reuse.
Stage 4: The domain has been fully explored. The software development for the domain can
largely be automated. Programs are not written in the traditional sense any more. Programs are
written using a domain specific language, which is also known as an application generator.
ComponentClassification
Components need to be properly classified in order to develop an effective indexing and storage
scheme. At the lowest level, the components are described in several forms—natural language
description, logic schema, timing information, etc. The higher the level at which a component is
described,[Link]-Diaz’sclassificationscheme.
Prieto-Diaz’s classification scheme
Prieto-Diaz’sfacetedclassificationschemerequireschoosingann-tuplethatbestfitsacomponent.
Faceted classification has advantages over enumerative classification. Strictly enumerative
[Link],theseforceyoutosearchforanitemthatbestfits
[Link] cross
referencing to other items can be included, the resulting network becomes complicated.
Searching
Apopularsearchtechniquethathasprovedtobeveryeffectiveisonethatprovidesawebinterface to the
repository. Using such a web interface, one would search an item using an approximate
automatedsearchusingkeywords,andthenfromtheseresultswoulddoabrowsingusingthelinks
[Link] to
fulfill some of the specified requirements. The items located through the approximate search
[Link]
[Link] found.
Browsing is done using the keyword-to-keyword, keyword- to-product, and product- to-
[Link].
Repository Maintenance
Repository maintenance involves entering new items, retiring those items which are no more
necessary, and modifying the search attributes of items to improve the effectiveness of search.
Also, the links relating the different items may need to be modified to improve the effectiveness
of search.
ReusewithoutModifications
Reuse without modification is much more useful than the classical program libraries. These can
be supported bycompilers through linkage to run-time support routines (application generators).
Application generators translate specifications into application programs. The specification
usually is written using 4GL. The specification might also be in a visual form. The programmer
would create a graphical drawing using some standard available symbols.
Application generators have been applied successfully to data processing application, user
interface, and compiler development. Application generators are less successful with the
development of applications with close interaction with hardware such as real-time systems.
REUSEATORGANISATIONLEVEL
Reusabilityshouldbe astandardpartin all softwaredevelopment activitiesincludingspecification,
design, implementation, test, etc.
Extracting reusable components from projects that were completed in the past presents an
important difficulty not encountered while extracting a reusable component from an ongoing
project—typically; the originaldevelopers are no longer available for consultation. Development
of new systems leads to an assortment of products, since reusability ranges from items whose
reusability is immediate to those items whose reusability is highly improbable.
Achievingorganization-levelreuserequiresadoptionofthefollowingsteps:
 Assessofanitem’spotentialforreuse
 Refinethe itemforgreaterreusability
 Entertheproductinthereuserepository
Assessingaproduct’spotentialforreuse
Assessment of a components reuse potential can be obtained from an analysis of a questionnaire
circulated among the developers. The questionnaire can be devised to assess a component’s
reusability. The programmers working in similar application domain can be used to answer the
questionnaire about the product’s reusability. Depending on the answers given by the
programmers,eitherthecomponentbetakenupforreuseasitis,itismodifiedandrefinedbefore it is
entered into the reuse repository, or it is ignored. A sample questionnaire to assess a
component’s reusability is the following:
o Isthecomponent’sfunctionalityrequiredfor implementationofsystemsinthefuture?
o Howcommonisthecomponent’sfunctionwithinitsdomain?
 o Wouldtherebeaduplicationoffunctionswithinthedomainifthecomponentistaken up?
o Isthecomponenthardwaredependent?
o Isthedesignofthecomponentoptimised enough?
o Ifthecomponentisnon-reusable,thencanitbedecomposedto yieldsomereusable
components?
o Canweparametriseanon-reusablecomponentsothatitbecomesreusable?
Refiningproductsforgreater reusability
For a product to be reusable, it must be relatively easy to adapt it to different [Link]
dependencymust be abstracted out or [Link] following
refinements may be carried out:
Namegeneralization:Thenamesshouldbegeneral,ratherthanbeingdirectlyrelatedtoaspecific
application.
Operation generalization: Operations should be added to make the component more general. Also,
operations that are too specific to an application can be removed.
Exception generalization: This involves checking each component to see whichexceptions it
[Link],severaltypesofexceptionsmighthavetobehandled.
Handlingportabilityproblems:Programstypicallymakesomeassumptionregardingthe representation
of information in the underlying machine. These assumptions are in general not trueforall machines.
The programs also often need to call some operating system functionality andthese callsmay
notbethe same on [Link] these
[Link]
operatingsystem and I/O procedures directly, abstract versions of these should be called bythe
application program
Figure:Improvingreusabilityofacomponentbyusingaportabilityinterface
CurrentStateofReuse
Inspiteofalltheshortcomingsofthestate-of-the-artreusetechniques,itistheexperience of
several organizations that most of the factors inhibiting an effective reuse program are
non- technical. Some of these factors are the following:
 Need forcommitmentfromthetopmanagement
 Adequatedocumentationtosupport reuse
 Adequateincentivetorewardthosewhoreuse
 Providingaccesstoand informationaboutreusablecomponents.