MC0071_February 2011_Software Engineering-Assignement

8/7/2019 MC0071_February 2011_Software Engineering-Assignement

1/23

February2011

MasterofComputerApplication(MCA)Semester3

MC0071SoftwareEngineering4Credits

(BookID:B0808&B0809)AssignmentSet1

1. Describetheconcurrentdevelopmentmodelinyourownwords.Ans: The concurrent process model can be represented schematically as a series of major technical

activities, tasks,and theirassociatedstates.Fore.g.:, theengineeringactivitydefined for thespiral

model is accomplished by invoking the following tasks. Prototyping and / or analysis modeling,

requirementsspecification,anddesign.

The below figure shows that it provides a schematic representation of one activity with the

concurrentprocessmodel.Theactivityanalysismaybe inanyoneofthestatesnotedatanygiven

time. Similarly,otheractivities (e.g.Designor customer communication) canbe represented inan

analogousmanner.Allactivitiesexist concurrentlybutreside indifferentstates.Fore.g.,early ina

project the customer communication activity has completed its first iteration and exists in the

awaitingChangesState.Theanalysisactivity(whichexisted inthenonestatewhile initialcustomer

communicationwas completed) nowmakes a transition into the under development state. If the

customerindicatesthatchangesinrequirementsmustbemade,theanalysisactivitymovesfromthe

underdevelopmentstateintotheawaitingchangesstate.

Theconcurrentprocessmodeldefinesaseriesofeventsthatwilltriggertransitionfromstatetostate

foreachofthesoftwareengineeringactivities.Fore.g.,duringearlystagesofdesign,aninconsistency

in theanalysismodel isuncovered.Thisgenerates theeventanalysismodel correction,whichwill

triggertheanalysisactivityfromthedonestateintotheawaitingChangesState.

The concurrentprocessmodel isoftenusedas theparadigm for thedevelopmentof client/server

applications.Aclient/serversystemiscomposedofasetoffunctionalcomponents.Whenappliedto

client/server,theconcurrentprocessmodeldefinesactivitiesintwodimensionsasystemdimension

andcomponentdimension.Systemlevelissuesareaddressedusingthreeactivities,designassembly,

anduse.Thecomponentdimensionaddressedwithtwoactivitydesignandrealization.Concurrency

is achieved in two ways; (1) System and component activities occur simultaneously and can be

modeled

using

the

state

oriented

approach

(2)

a

typical

client

server

application

is

implemented

withmanycomponents,eachofwhichcanbedesignedandrealizedconcurrently.

The concurrentprocessmodel isapplicable to all typesof softwaredevelopment andprovides an

accurate picture of the current state of a project. Rather than confining softwareengineering

activities toa sequenceofevents, itdefinesanetworkofactivities.Eachactivityon thenetwork

existssimultaneouslywithotheractivities.Eventsgeneratedwithinagivenactivityoratsomeother

placeintheactivitynetworktriggertransitionsamongthesatesofanactivity.


2/23

Representsastateofasoftwareengineeredactivity

UNDER

DEVELOPMENT

AWAITING

CHANGES

UNDER REVISION

UNDER REVIEW

BASELINED

DONE

Oneelementofconcurrentprocessmodel

Componentbaseddevelopmentmodel:

This model incorporates the characteristics of the spiral model. It is evolutionary in nature,

demanding an iterative approach to the creation of software. However, the componentbased

developmentmodelcomposesapplicationsfromprepackagedsoftwarecomponentscalledclasses.

Classescreatedinpastsoftwareengineeringprojectsarestoredinaclasslibraryorrepository.Once

candidate classes are identified, the class library is searched todetermine if these classes already

exist.Iftheydo,theyareextractedfromthelibraryandreused.Ifacandidateclassdoesnotresidein

the

library,

it

is

engineered

using

object

oriented

methods.

The

first

iteration

of

the

application

to

be

builtisthencomposedusingclassesextractedfromthelibraryandanynewclassesbuilttomeetthe

uniqueneedsoftheapplication.Processflowthenreturnstothespiralandwillultimatelyreenter

thecomponentassemblyiterationduringsubsequentpassesthroughtheengineeringactivity.

Thecomponentbaseddevelopmentmodelleadstosoftwarereuse,andreusabilityprovidessoftware

engineers with a number of measurable benefits although it is very much dependent on the

robustnessofthecomponentlibrary.

2. ExplainthefollowingconceptswithrespecttoSoftwareReliability:A)SoftwareReliabilityMetrics


3/23

Ans: Metricswhichhavebeenused for software reliability specificationare shown inbelow Figure.The

choiceofwhichmetric shouldbeuseddependson the typeofsystem towhich itappliesand the

requirementsof theapplicationdomain.For some systems, itmaybeappropriate tousedifferent

reliabilitymetricsfordifferentsubsystems.

METRIC EXPLANATION EXAMPLE SYSTEM

POFOD

PROBABILITY

OF FAILURE ON

DEMAND

This is measure of the likelihoodthat the system will fail when a

service request is made. For

example,aPOFODof0,001means

that1outof1000servicerequests

mayresultinfailure.

Safety critical and nonstopsystems, such as hardware control

systems.

ROCOF

RATE OF

FAILURE

OCCURRENCE

This isameasureof the frequencyof occurrence with which

unexpected behavior is likely to

occur. For example, a ROCOF of

2/100mansthat2failuresarelikely

to occur in each 100 operational

timeunits.Thismetricissometimes

calledthefailureintensity.

Operating systems, transactionprocessingsystem.

MTTF

MEAN TIME TO

FAILURE

This is a measure of the timebetween observed system failures.

Forexample,anMTTFof500 time

units. If the system is not being

changed, it is the reciprocalof the

ROCOF.

SystemswithlongtransactionssuchasCADsystem.TheMTTFmustbe

greaterthanthetransactiontime.

AVAIL

AVAILABILITY

This isameasureofhow likely thesystem is to be available for use.

Forexample,anavailabilityof0.998

means that in every 1000 time

units, the system is likely to be

availablefor998ofthese

Continuously running systems suchastelephoneswitchingsystem

Reliabilitymatrix

In some cases, system users are most concerned about how often the system will fail, perhaps

becausethereisasignificantcostinrestartingthesystem.Inthosecases,ametricbasedonarateof

failureoccurrence(ROCOF)orthemeantimetofailureshouldbeused.

Inothercases,itisessentialthatasystemshouldalwaysmeetarequestforservicebecausethereis

some cost in failing to deliver the service. The number of failures in some time period is less

important.Inthosecases,ametricbasedontheprobabilityoffailureondemand(POFOD)shouldbe

used.Finally,usersorsystemoperatorsmaybemostlyconcernedthatthesystemisavailablewhena

requestforserviceismade.Theywillincursomelossifthesystemisunavailable.Availability(AVAIL).

Whichtakesintoaccountrepairorrestarttime,isthenthemostappropriatemetric.


4/23

Therearethreekindsofmeasurement,whichcanbemadewhenassessingthereliabilityofasystem:

1.The number of system failures given a number of systems inputs. This is used tomeasure thePOFOD.

2.Thetime(ornumberoftransaction)betweensystemfailures.ThisisusedtomeasureROCOFandMTTF.

3.Theelapsed repairor restart timewhenasystem failureoccurs.Given that thesystemmustbecontinuouslyavailable,thisisusedtomeasureAVAIL.

Timeisafactorinallofthisreliabilitymetrics.Itisessentialthattheappropriatetimeunitsshouldbe

chosen ifmeasurementsare tobemeaningful.Timeunits,whichmaybeused,are calendar time,

processortimeormaybesomediscreteunitsuchasnumberoftransactions.

Software

reliability

specification

System requirementsdocuments, reliability requirementsareexpressed inan informal,qualitative,

untestableway. Ideally, the required level of reliability should be expressed quantitatively in the

software requirement specification.Dependingon the typeof system,oneormoreof themetrics

discussed in the previous section may be used for reliability specifications. Statistical testing

techniques(discussedlater)shouldbeusedtomeasurethesystemreliability.Thesoftwaretestplan

shouldincludeanoperationalprofileofthesoftwaretoassessitsreliability.

Thestepsinvolvedinestablishingareliabilityspecificationareasfollows:

1.Foreachidentifiedsubsystem,identifythedifferenttypesofsystemfailure,whichmayoccurandanalyzetheconsequencesofthesefailures.

2.From thesystem failureanalysis,partition failures intoappropriateclasses.Areasonablestartingpoint is touse the failure types shown in Figure shownbelow. For each failure class identified,

definethereliabilityrequirementusingtheappropriatereliabilitymetric.Itisnotnecessarytouse

the same metric for different classes of failure. For example, where a failure requires some

intervention torecover from it, theprobabilityof that failureoccurringondemandmightbe the

mostappropriatemetric.Whenautomaticrecoverispossibleandtheeffectofthefailureissome

userinconvenience,ROCOFmightbemoreappropriate.

FAILURE CLASSQ DESCRIPTION

TRANSIENT OccursonlywithcertaininputsPERMANENT OccurswithallinputsRECOVERABLE Systemcanrecoverwithoutoperatorintervention

UN RECOVERABLE Operatorinterventionneededtorecoverfromfailure


5/23

NON CURRUPTING FailuredoesnotcorruptsystemstateordataCURRUPTING Failurecorruptssystemstateordata

Failureclassification

Thecostofdevelopingandvalidatingareliabilityspecificationforsoftwaresystemisveryhigh.

Statisticaltesting

Statisticaltesting isasoftwaretestingprocess inwhichtheobjective istomeasurethereliabilityof

thesoftwareratherthantodiscoversoftwarefaults.Itusersdifferenttestdatafromdefecttesting,

whichisintendedtofindfaultsinthesoftware.

Thestepsinvolvedinstatisticaltestingare:

1.Determine

the

operational

profile

of

the

software.

The

operational

profile

is

the

probable

pattern

of usage of the software. This can be determined by analyzing historical data to discover the

differentclassesofinputtotheprogramandtheprobabilityoftheiroccurrence.

2.Selectorgenerateasetoftestdatacorrespondingtotheoperationalprofile.3.Apply these test cases to the program, recording the amount of execution time between eachobservedsystemfailure.Itmaynotbeappropriatetouserawexecutiontime.Asdiscussedinthe

previoussection,thetimeunitschosenshouldbeappropriateforthereliabilitymetricused.

4.Afterastatisticallysignificantnumberoffailureshavebeenobserved,thesoftwarereliabilitycanthenbecomputed.Thisinvolvesusingthenumberoffailuresdetectedandthetimebetweenthese

failurestocomputertherequiredreliabilitymetric.

Thisapproachtoreliabilityestimationisnoteasytoapplyinpractice.Thedifficulties,whicharise,are

dueto:

Operationalprofileuncertainty; Highcostofoperationalprofilegeneration; Statisticaluncertaintywhenhighreliabilityisspecified.B)ProgrammingforReliability

Ans: Thereisageneralrequirementformorereliablesystemsinallapplicationdomains.Customersexpect

their software to operate without failures and to be available when it is required. Improved

programmingtechniques,betterprogramminglanguagesandbetterqualitymanagementhaveledto

verysignificant improvements in reliability formostsoftware.However, forsomesystems,suchas

those,whichcontrolunattendedmachinery,thesenormaltechniquesmaynotbeenoughtoachieve

thelevelofreliabilityrequired.Inthesecases,specialprogrammingtechniquesmaybenecessaryto

achievetherequiredreliability.Someofthesetechniquesarediscussedinthischapter.

Reliabilityinasoftwaresystemcanbeachievedusingthreestrategies:


6/23

Faultavoidance:Thisisthemostimportantstrategy,whichisapplicabletoalltypesofsystem.Thedesignandimplementationprocessshouldbeorganizedwiththeobjectiveofproducingfaultfree

systems.

Fault tolerance: This strategy assumes that residual faults remain in the system. Facilities areprovided

in

the

software

to

allow

operation

to

continue

when

these

faults

cause

system

failures.

Fault detection: Faults are detected before the software is put into operation. The softwarevalidation process uses static and dynamic methods to discover any faults, which remain in a

systemafterimplementation.

Faultavoidance

Agoodsoftwareprocessshouldbeorientedtowardsfaultavoidanceratherthanfaultdetectionand

removal. It shouldhave theobjectiveofdeveloping faultfree software.Faultfree softwaremeans

software,whichconformstoitsspecification.Ofcourse,theremaybeerrorsinthespecificationorit

maynotreflecttherealneedsoftheusersofaultfreesoftwaredoesnotnecessarilymeanthatthe

softwarewillalwaysbehaveastheuserwants.

Faultavoidanceandthedevelopmentoffaultfreesoftwarerelieson:

1.The availability of aprecise system specification,which is an unambiguousdescription ofwhat,mustbeimplemented.

2.Theadoptionofanorganizationalqualityphilosophyinwhichqualityisthedriverofthesoftwareprocess.Programmersshouldexpecttowritebugfreeprogram.

3.Theadoptionofanapproachtosoftwaredesignandimplementationwhichisbasedoninformationhidingandencapsulationandwhichencouragestheproductionofreadableprograms.

4.The use of a strongly typed programming language so thatpossible errors are detectedby thelanguagecompiler.

5.Restriction on the use of programming construct, such as pointers,which are inherently errorprone.

Achievingfaultfreesoftwareisvirtuallyimpossibleiflowlevelprogramming

Languageswithlimitedtypecheckingareusedforprogramdevelopment.


7/23

CostPererror

deleted

NumberofresidualerrorsVeryfew Few Many

Theincreasingcostofresidualfaultofremoval

We must be realistic and accept that human errors will always occur. Faults may remain in the

softwareafterdevelopment.Therefore, thedevelopmentprocessmust includea validationphase,

whichchecksthedevelopedsoftwareforthepresenceoffaults.Thisvalidationphaseisusuallyvery

expensive.Asfaultsareremovedfromaprogram,thecostoffindingandremovingremainingfaults

tendstoriseexponentially.Asthesoftwarebecomesmorereliable,moreandmoretestingisrequired

tofindfewerandfewerfaults.

Structuredprogramminganderroravoidance

Structured programming is termwhich is tomean programmingwithout using go to statements,

programmingusingonlywhileloopsandifstatementsascontrolconstructsanddesigningusingatop

down approach. The adoption of structured programming was an important milestone in the

development of software engineering because it was the first step away from an undisciplined

approachtosoftwaredevelopment.

Gotostatementwasaninherentlyerrorproneprogrammingconstruct.Thedisciplineduseofcontrol

structures forceprogrammers to think carefullyabout theirprogram.Hence theyare less likely to

make mistakes during development. Structured programming means programs can be read

sequentiallyandare thereforeeasier tounderstandand inspect.However,avoidingunsafe control

statementsisonlythefirststepinprogrammingforreliability.

Faultsarelesslikelytobeintroducedintoprogramsiftheuseoftheseconstructsisminimized.These

constructsinclude:

1.Floatingpointnumbers:Floatingpointnumbersareinherentlyimprecise.Theypresentaparticularproblem when they are compared because representation imprecision may lead to invalid

comparisons.Fixedpointnumbers,whereanumber isrepresentedtoagivennumberofdecimal

places,aresaferasexactcomparisonsarepossible.


8/23

2.Pointer:Pointersare lowlevel constructs,which referdirectly toareasof themachinememory.They are dangerous because errors in their use can be devastating and because they allow

aliasing. Thismeans the same entitymaybe referencedusing differentnames.Aliasingmakes

programshardertomaybereferencedusingdifferentnames.Alilasingmakesprogramsharderto

understandsothaterrorsaremoredifficulttofind.However,efficiencyrequirementsmeanthatit

isoftenimpracticaltoavoidtheuseofpointers.

3.Dynamicmemoryallocation:Programmemory isallocatedatruntime rather thancompiletime.Thedangerwith this is that thememorymaynotbedeallocatedso that thesystemeventually

runsoutofavailablememory.Thiscanbeaverysubtletypeoferrorstodetectasthesystemmay

runsuccessfullyforalongtimebeforetheproblemoccurs.

4.Parallelism:Parallelism isdangerousbecauseof thedifficultiesofpredicting thesubtleeffectsoftiming interactions between parallel process. Timing problems cannot usually e detected by

programinspectionandthepeculiarcombinationofcircumstances,whichcauseatimingproblem,

maynotresultduringsystemtesting.Parallelismmaybeunavoidablebutitsuseshouldbecarefully

controlled tominimize interprocessdependencies.Programming language facilities, suchasAda

tasks,helpavoid someof theproblemsofparallelismas the compiler candetect somekindsof

programmingerrors.

5.Recursion:Recursion isthesituation inwhichasubroutinecalls itselforcallsanothersubroutine,which thencalls thecallingsubroutine. Itsuse can result inveryconciseprogramsbut itcanbe

difficult to follow the logic of recursive programs. Errors in using recursion may result in the

allocationofalltheysystemsmemoryastemporarystackvariablesarecreated.

6.Interrupts:Interruptsareameansofforcingcontroltotransfertoasectionofcodeirrespectiveofthecodecurrentlyexecuting.Thedangersofthisareobviousastheinterruptmaycauseacritical

operationtobeterminated.

Faulttolerance

A faulttolerant system can continue inoperation after some system failureshaveoccurred. Fault

toleranceisneededinsituationswheresystemfailurewouldcausesomeaccidentorwherealossof

systemoperationwouldcauselargeeconomiclosses.Forexample,thecomputersinanaircraftmust

continueinoperationuntiltheaircrafthaslanded;thecomputersinantrafficcontrolsystemmustbe

continuouslyavailable.

Faulttolerance facilities are required if the system is to failure. There are four aspects to fault

tolerance.

1.Failuredetection:Thesystemmustdetectaparticularstatecombinationhasresultedorwillresultin

a

system

failure.

2.Damageassessment:Thepartsofthesystemstate,whichhavebeenaffectedbythefailure,mustbedetected.

3.Faultrecovery:Thesystemmustrestoreitsstatetoaknownsafestate.Thismaybeachievedbycorrecting the damaged state or by restoring the system the system to a known safe state.

Forwarderrorrecoveryismorecomplexasitinvolvesdiagnosingsystemfaultsandknowingwhat

thesystemstateshouldhavebeenhadthefaultsnotcausedasystemfailure.

4.Fault repair:This involvesmodifying thesystemso that the faultdoesnot recur. Inmanycases,software failuresare transientanddue toapeculiar combinationof system inputs.No repair is


9/23

necessaryasnormalprocessingcanresume immediatelyafterfaultrecovery.Thisisanimportant

distinctionbetweenhardwareandsoftwarefaults.

Therehasbeenaneed formanyyears tobuild faulttoleranthardware.Themost commonlyused

hardware faulttolerant technique isbasedaround thenotionof triplemodular redundancy (TMR)

shown

in

the

below

figure.

The

hardware

unit

is

replicated

three

(or

sometimes

more)

times.

The

outputfromeachunitiscompared.Ifoneoftheunitsfailsanddoesnotproducethesameoutputas

theotherunits,itsoutputisignored.Thesystemfunctionswithtwoworkingunits.

A1

A2

A3

Output

Comparator

Triplemodularredundancytocopewithhardwarefailure

Theweaknessofboththeseapproachestofaulttolerance isthattheyarebasedontheassumption

thatthespecificationiscorrect.Theydonottoleratespecificationerrors.

Therehavebeentwocomparableapproachestotheprovisionofsoftwarefaulttolerance.Bothhave

beenderivedfromthehardwaremodelwhereacomponentisreplicated.

(1) Nversionprogramming:Usingacommonspecification,thesoftwaresystemisimplementedinanumberofdifferentversionsbydifferent teams.Theseversionsareexecuted inparallel.Their

outputsarecomparedusingavotingsystemandinconsistentoutputsarerejected.Atleastthree

versionsofthesystemshouldbeavailable.

Nversionprogramming

(2) Recovery Blocks: this is a finer grain approach to fault tolerance. Each program componentincludesa test tocheck if thecomponenthasexecutedsuccessfully. Italso includesalternative

code,whichallowsthesystemtobackupandrepeatthecomputationifthetestdetectsafailure.

Unlike Nversion programming, the implementation is different rather than independent

implementationofthesamespecification.Theyareexecutedinsequenceratherthaninparallel.


10/23

Algorithm1Acceptance

test

Recoveryblocks

Algorithm2 Algorithm2

Tryalgorithm1Testfor

success Continueexecutionit

acceptancetestsuccess

SignalExceptionifall

algorithmsfail

Retest

Retry

RetestAcceptance test

failsretry

ExceptionHandling

Whenanerrorofsomekindoranunexpectedeventoccursduringtheexecutionofaprogram,thisis

calledanexception.Exceptionsmaybecausedbyhardwareorsoftwareerrors.Whenanexception

has not been anticipated, control is transferred to system exceptions handling mechanism. If an

exceptionhasbeen anticipated, codemustbe included in theprogram todetect andhandle that

exception.

Mostprogramming languagesdonot includefacilities todetectandhandleexceptions.Thenormal

decisionconstructs(ifstatements)ofthelanguagemustbeusedtodetecttheexceptionandcontrol

constructsusedtotransfercontroltoexceptionoccursinasequenceofnestedprocedurecalls,there

isnoteasywaytotransmititfromoneproceduretoanother.

Considerexampleasshown infigurebelowanumberofnestedprocedurecallswhereprocedureA

callsprocedureBwhichcallsprocedureC.IfanexceptionoccursduringtheexecutionofCthismaybe

soseriousthatexecutionofBcannotcontinue.ProcedureBhastoreturnimmediatelytoProcedure

A, which must also be informed that B has terminated abnormally and that an exception has

occurred.

C:

B:

A

B

C

Exception

return

Exception

Occurrence

Call

sequence

Exceptionreturninembeddedprocedurecalls

Anexceptionhandlerissomethinglikeacasestatement. Itstatesexceptionnamesandappropriate

actionsforeachexception.


11/23

Exceptionsinafreezertemperaturecontroller(C++)

Abovetableillustratestheuseofexceptionsandexceptionhandling.Theseprogramfragmentsshow

the design of a temperature controller on a food freezer. The required temperaturemay be set

between 18 and 40 degrees Celsius. Food may start to defrost and bacteria become active at

temperatures over 18 degrees. The control system maintains this temperature by switching a

refrigerant pump on and off depending on the value of a temperature sensor. If the required

temperaturecannotbemaintained,thecontrolledsetsoffanalarm.Thetemperatureofthefreezeris

discoveredby interrogatinganobjectcalledSensorand the required temperatureby inspectingan

objectcalledtheexceptionsFreezer_too_hotandControl_problemandthetypeFREEZER_TEMPare

declared. There are no builtin exceptions in C++ but other information is declared in a separate

headerfile.

The temperature controller tests the temperature and switches the pump as required. If the

temperatureistoohot,ittransferscontroltotheexceptionhandler,whichactivatesanalarm.

InC++,Onceanexceptionhasbeen,itisnotrethrown.

Defensiveprogramming

Defensiveprogrammingisanapproachtoprogramdevelopmentwherebyprogrammersassumethat

theremaybeundetectedfaultsorinconsistenciesintheirprograms.Redundantcodeisincorporated

tocheck theSystemStateaftermodificationsand toensure that thestate change is consistent. If

inconsistenciesaredetected,thestatechangeisretractedorthestateisrestoredtoaknowncorrect

state.

Defensiveprogramming isanapproachtofaulttolerance,whichcanbecarriedoutwithoutafault

tolerant controller. The techniques used, however, are fundamental to the activities in the fault

toleranceprocess,namelydetectingafailure,damageassessment,andrecoveringfromthatfailure.

Failureprevention


12/23

Programming languages suchasAdaandC++allowmanyerrorswhich cause state corruptionand

system failure tobedetectedatcompiletime.Thecompilercandetect thoseproblemswhichuses

thestricttyperulesof the language.Compilerchecking isobviously limited tostaticvaluesbut the

compilercanalsoautomaticallyaddcodetoaprogramtoperformruntimechecks.

Damageassessment

Damageassessmentinvolvesanalyzingthesystemstatetogaugetheextentofthestatecorruption.

Inmanycases,corruptioncanbeavoidedbycheckingforfaultoccurrencebeforefinallycommittinga

changeofstate.Ifafaultisdetected,thestatechangeisnotacceptedsothatnodamageiscaused.

However, damage assessment may be needed when a fault arises because a sequence of state

changes(allofwhichareindividuallycorrect)causesthesystemtoenteranincorrectstate.

Theroleof thedamageassessmentprocedures isnot torecover from the faultbut toassesswhat

partsofthestatespacehavebeenaffectedbythefault.Damagecanonlybeassessedifitispossible

toapplysomevalidityfunction,whichchecksifthestateisconsistent.Ifinconsistenciesarefound,

thesearehighlightedorsignaledinsomeway.

Other techniqueswhichcanbeused for faultdetectionanddamageassessmentaredependenton

thesystemstaterepresentationandontheapplication.Possiblemethodsare:

Theuseofchecksumsindataexchangeandcheckdigitsinnumericdata; Theuseofredundantlinksindatastructureswhichcontainpointers; Theuseofwatchdogtimersinconcurrentsystems.A checksum isavalue that is computedbyapplying somemathematical function to thedata.The

function

used

should

give

a

unique

value

for

the

packet

of

data,

which

is

exchanged.

The

sender

who

appliesthechecksumfunctiontothedataandappendsthatfunctionvaluetothedatacomputesthis

checksum.Thereceiverappliesthesamefunctiontothedataandcomparesthechecksumvalues.If

thesediffer,somedatacorruptionhasoccurred.

When linked data structures are used, the representation can be made redundant by including

backwardpointers.Thatis,foreveryreferencefromAtoB,thereexistsacomparablereferencefrom

B toA. It isalsopossible tokeep countof thenumberofelements in the structure.Checking can

determinewhetherornotallpointershaveaninversevalueandwhetherornotthestoredsizeand

thecomputedstructuresizearethesame.

When processesmust reactwithin a specific time period, awatchdog timermay be installed. A

watchdogtimerisatimerwhichmustberesetbytheexecutingprocessafteritsactioniscomplete.

It isstartedatthesametimeasaprocessandtimestheprocessexecution. If,forsomereasonthe

processfailstoterminate,thewatchdogtimerisnotreset.Thecontrollercanthereforedetectthata

problemhasarisenandtakeactiontoforceprocesstermination.

Faultrecovery

Faultrecoveryistheprocessofmodifyingthestatespaceofthesystemsothattheeffectsofthefault

are minimized. The system can continue in operation, perhaps in same degraded form. Forward


13/23

recoveryinvolvestryingtocorrectthedamagedSystemState.BackwardrecoveryrestorestheSystem

Statetoaknowncorrectstate.

Therearetwogeneralsituationswhereforwarderrorrecoverycanbeapplied:

1.Whencoded iscorruptedTheuseofcodingtechniqueswhichaddredundancytothedataallowserrorstobecorrectedaswellasdetected.

2.When linkedstructuresarecorrupted if forwardandbackwardpointersare included in thedatastructure,thestructurecanberecreatedifenoughpointersremainuncorrupted.Thistechniqueis

frequentlyusedforfilesystemanddatabaserepair.

Backwarderrorrecoveryisasimplertechnique,whichrestoresthestatetoaknownsafestateafter

anerrorhasbeendetected.Mostdatabasesystems includebackwarderrorrecovery.Whenauser

initiatesadatabasecomputationatransactionisinitiated.Changesmadeduringthattransactionare

notimmediatelyincorporatedinthedatabase.Thedatabaseisonlyupdatedafterthetransaction is

finishedandnoproblemsaredetected.Ifthetransactionfails,thedatabaseisnotupdated.

DesignbyContract

Meyersuggestsanapproachtodesign,calleddesignbycontract,tohelpensurethatadesignmeets

its specifications. He begins by viewing software system as a set of communicating components

whoseinteractionisbasedonapreciselydefinedspecificationofwhateachcomponentissupposed

todo. These specifications, called contracts, govern how the component is to interactwith other

componentsandsystems.Suchspecificationcannotguaranteecorrectness,butitformsagoodbasis

fortestingandvalidation.

Contractiswrittenbetweentwopartieswhenonecommissionstheotherforaparticularserviceor

product. Each party expects somebenefit for someobligation; the supplier produces a service or

productinagivenperiodoftimeinexchangeformoney,andtheclientacceptstheserviceorproduct

forthemoney.Thecontractmakestheobligationandbenefitsexplicit.

Mayerappliesthenotionofacontracttosoftware.Asoftwarecomponent,calledaclient,adoptsa

strategytoperformasetoftasks,t1,t2,tn.Inturn,eachnontrivialsubtask,itisexecutedwhenthe

client calls another component, the supplier, to perform it. That is a contract between the two

componentstoperformthesubtask.Eachcontractcoversmutualobligation(calledpreconditions),

benefits (called postconditions), and consistency constraints (called invariant). Together, these

contractpropertiesarecalledassertions.

For example, suppose the client component has a table where each element is identified by a

characterstringusedasakey.Oursupplierscomponentstaskistoinsertanelementfromthetable

intoadictionaryof limitedsize.Wecandescribe thecontractbetweenthetwocomponents inthe

followingway.

1.Theclientcomponentensuresthatthedictionaryisnotfullandthatthekeyisnonempty.2.Thesuppliercomponentrecordstheelementintable.3.Theclientcomponentaccessestheupdatedtablewheretheelementappears.4.Ifthetableisfullorthekeyisempty,noactionistaken.


14/23

3. Suggestsixreasonswhysoftwarereliabilityisimportant.Usinganexample,explainthedifficultiesofdescribingwhatsoftwarereliabilitymeans.

Ans: Theneedforameanstoobjectivelydeterminesoftwarereliabilitycomesfromthedesiretoapplythe

techniquesofcontemporaryengineeringfieldstothedevelopmentofsoftware.Thatdesireisaresult

of the commonobservation,byboth laypersonsandspecialists, that computer softwaredoesnot

workthewayitoughtto.Inotherwords,softwareisseentoexhibitundesirablebehaviour,uptoand

includingoutrightfailure,withconsequencesforthedatawhichisprocessed,themachineryonwhich

thesoftwareruns,andbyextensionthepeopleandmaterialswhichthosemachinesmightnegatively

affect.Themorecriticaltheapplicationofthesoftwaretoeconomicandproductionprocesses,orto

lifesustainingsystems,themoreimportantistheneedtoassessthesoftware'sreliability.

Regardlessof the criticalityofany single softwareapplication, it isalsomoreandmore frequently

observed that softwarehaspenetrateddeeply intomost every aspectofmodern life through the

technologyweuse.Itisonlyexpectedthatthisinfiltrationwillcontinue,alongwithanaccompanying

dependency

on

the

software

by

the

systems

which

maintain

our

society.

As

software

becomes

more

andmorecrucial to theoperationof thesystemsonwhichwedepend, theargumentgoes, itonly

follows that the software should offer a concomitant level of dependability. In other words, the

softwareshouldbehaveinthewayitisintended,orevenbetter,inthewayitshould.

Asoftwarequalityfactorisanonfunctionalrequirementforasoftwareprogramwhichisnotcalled

up by the customer's contract, but nevertheless is a desirable requirement which enhances the

qualityof the softwareprogram.Note thatnoneof these factorsarebinary; that is, they arenot

eitheryouhaveitoryoudonttraits.Rather,theyarecharacteristicsthatoneseekstomaximizein

onessoftwaretooptimizeitsquality.Soratherthanaskingwhetherasoftwareproducthasfactor

x,askinsteadthedegreetowhichitdoes(ordoesnot).

Somesoftwarequalityfactorsarelistedhere:

Understandability

Clarity of purpose. This goes further than just a statement of purpose; all of the design anduser

documentationmustbeclearlywrittensothatitiseasilyunderstandable.Thisisobviouslysubjective

inthattheusercontextmustbetakenintoaccount:forinstance,ifthesoftwareproductistobeused

bysoftwareengineersitisnotrequiredtobeunderstandabletothelayman.

Completeness

Presenceofallconstituentparts,witheachpartfullydeveloped.Thismeansthat ifthecodecallsa

subroutinefromanexternallibrary,thesoftwarepackagemustprovidereferencetothatlibraryand

allrequiredparametersmustbepassed.Allrequiredinputdatamustalsobeavailable.

Conciseness

Minimizationofexcessiveorredundant informationorprocessing.This is importantwherememory

capacityislimited,anditisgenerallyconsideredgoodpracticetokeeplinesofcodetoaminimum.It


15/23

canbe improvedby replacing repeated functionalitybyonesubroutineor functionwhichachieves

thatfunctionality.Italsoappliestodocuments.

Portability

Ability to be runwell and easily onmultiple computer configurations. Portability can mean both

between different hardwaresuch as running on a PC as well as a smartphoneand between

differentoperatingsystemssuchasrunningonbothMacOSXandGNU/Linux.

Consistency

Uniformityinnotation,symbology,appearance,andterminologywithinitself.

Maintainability

Propensity to facilitate updates to satisfy new requirements. Thus the software product that is

maintainableshouldbewelldocumented,shouldnotbecomplex,andshouldhavesparecapacityfor

memory,storageandprocessorutilizationandotherresources.

Testability

Dispositiontosupportacceptancecriteriaandevaluationofperformance.Suchacharacteristicmust

bebuiltinduringthedesignphase iftheproduct istobeeasilytestable;acomplexdesign leadsto

poortestability.

Usability

Convenienceandpracticalityofuse.Thisisaffectedbysuchthingsasthehumancomputerinterface.

Thecomponentofthesoftwarethathasmostimpactonthisistheuserinterface(UI),whichforbest

usabilityisusuallygraphical(i.e.aGUI).

Reliability

Ability tobeexpected toperform its intended functions satisfactorily.This impliesa time factor in

thatareliableproduct isexpected toperformcorrectlyoveraperiodof time. Italsoencompasses

environmental considerations in that the product is required to perform correctly in whatever

conditionsitfindsitself(sometimestermedrobustness).

Efficiency

Fulfillmentofpurposewithoutwasteofresources,suchasmemory,spaceandprocessorutilization,

networkbandwidth,time,etc.

Security

Ability to protect data against unauthorized access and to withstand malicious or inadvertent

interferencewith itsoperations.Besides thepresenceofappropriate securitymechanisms suchas


16/23


17/23

4. What are the essential skills and traits necessary for effective project managers in successfullyhandlingprojects?

Ans: The Successful ProjectManager: A successful project manager knows how to bring together the

definitionandcontrolelementsandoperatethemefficiently.Thatmeansyouwillneedtoapplythe

leadershipskillsyoualreadyapply inrunningadepartmentandpractice theorganizationalabilities

youneedtoconstantlylooktothefuture.Inotherwords,ifyoureaqualifieddepartmentmanager,

you already possess the skills and attributes for succeeding as a projectmanager. The criteria by

whichyouwillbeselectedwillbesimilar.Chancesare,theprojectyoureassignedwillhaveadirect

relationshiptotheskillsyouneedjusttodoyourjob.Forexample:

Organizationalandleadershipexperience.Anexecutiveseekingaqualifiedprojectmanagerusuallyseekssomeonewhohasalreadydemonstratedtheabilitytoorganizeworkandtoleadothers.He

or sheassumes that youwill succeed in a complicated longtermprojectprimarilybecause you

havealreadydemonstratedtherequiredskillsandexperience.

Contact with needed resources. For projects that involve a lot of coordination betweendepartments, divisions, or subsidiaries, top management will look for a project manager who

already communicates outside of a single department. If you have the contacts required for a

project,itwillnaturallybeassumedthatyouaresuitedtorunaprojectacrossdepartmentallines.

Abilitytocoordinateadiverseresourcepool.Byitself,contactoutsideofyourdepartmentmaynotbeenough.Youmustalsobeabletoworkwithavarietyofpeopleanddepartments,evenwhen

theirbackgroundsanddisciplinesaredissimilar.Forexample,asacapableprojectmanager,you

mustbeabletodelegateandmonitorworknotonlyinareasfamiliartoyourowndepartmentbut

inareasthatarealientoyourbackground.

Communication and procedural skills. An effective projectmanagerwill be able to convey andreceiveinformationtoandfromanumberofteammembers,evenwhenparticularpointsofview

aredifferentfromhisown.Forexample,astrictlyadministrativemanagershouldunderstandthe

priorities of a salesdepartment,or a customer servicemanagermay need to understandwhat

motivatesaproductioncrew.

Ability todelegate andmonitorwork.Projectmanagersneed todelegate thework thatwillbeperformedbyeachteammember,andtomonitorthatworktostayonscheduleandwithinbudget.

Acontractorwhobuildsahousehastounderstandtheprocessesinvolvedforworkdonebyeach

subcontractor,even ifthework ishighlyspecialized.Thesame istrueforeveryprojectmanager.

Itsnot enoughmerely to assign someoneelse a task, completewith a schedule and abudget.

Delegationandmonitoringareeffectiveonlyifyourealsoabletosuperviseandassessprogress.

Dependability.Yourdependabilitycanbetestedonlyinoneway:bybeinggivenresponsibilityandthe chance to come through. Once you gain the reputation as a manager who can and does

respondasexpected,yourereadytotakeonaproject.

Theseprojectmanagementqualifications read likea listofevaluationpoints foreverydepartment

manager. Ifyou thinkof theprocessof runningyourdepartmentasaprojectof itsown, thenyou

already understandwhat its like to organize a projectthe difference, of course, being that the

projecttakesplaceinafinitetimeperiod,whereasyourdepartmentaltasksareongoing.Thus,every


18/23

successfulmanager should be ready to tackle a project, provided it is related to his or her skills,

resources,andexperience.

5. WhicharethefourphasesofdevelopmentaccordingtoRationalUnifiedProcess?Ans: TheRationalUnifiedProcessisaSoftwareEngineeringProcess.Itprovidesadisciplinedapproachto

assigning tasks and responsibilities within a development organization. Its goal is to ensure the

production of highquality software that meets the needs of its endusers, within a predictable

scheduleandbudget.

TheRationalUnifiedProcessisaprocessproduct,developedandmaintainedbyRationalSoftware.

ThedevelopmentteamfortheRationalUnifiedProcessareworkingcloselywithcustomers,partners,

RationalesproductgroupsaswellasRationalesconsultantorganization,toensurethattheprocessis

continuouslyupdatedandimprovedupontoreflectrecentexperiencesandevolvingandprovenbest

practices.TheRationalUnifiedProcessenhancesteamproductivity,byprovidingeveryteammember

with easy access to a knowledge basewith guidelines, templates and toolmentors for all critical

developmentactivities.Byhavingallteammembersaccessingthesameknowledgebase,nomatterif

youworkwith requirements,design, test,projectmanagement,or configurationmanagement,we

ensure that all team members share a common language, process and view of how to develop

software.

The Rational Unified Process activities create and maintain models. Rather than focusing on the

productionof largeamountofpaperdocuments, theUnifiedProcessemphasizes thedevelopment

and maintenance of modelssemantically rich representations of the software system under

development.

The RationalUnifiedProcess is a guide forhow to effectively use theUnifiedModeling Language

(UML). The UML is an industrystandard language that allows us to clearly communicate

requirements,architecturesanddesigns.TheUMLwasoriginallycreatedbyRationalSoftware,andis

nowmaintainedbythestandardsorganizationObjectManagementGroup(OMG).

EffectiveDeploymentof6BestPractices

TheRationalUnifiedProcessdescribeshowtoeffectivelydeploycommerciallyprovenapproachesto

software development for software development teams. These are called best practices not so

muchbecauseyou canpreciselyquantify theirvalue,but rather,because theyareobserved tobe

commonlyused in industrybysuccessfulorganizations.TheRationalUnifiedProcessprovideseach

teammemberwiththeguidelines,templatesandtoolmentorsnecessaryfortheentireteamtotake

fulladvantageofamongothersthefollowingbestpractices:

1.Developsoftwareiteratively2.Managerequirements3.Use componentbased architectures Rational Unified Process: Best Practices for SoftwaredevelopmentTeams


19/23

4.Visuallymodelsoftware5.Verifysoftwarequality6.ControlchangestosoftwareDevelopSoftwareIteratively

Giventodayssophisticatedsoftwaresystems,itisnotpossibletosequentiallyfirstdefinetheentire

problem,design the entire solution,build the software and then test the product at the end.An

iterative approach is required that allows an increasing understanding of the problem through

successiverefinements,andtoincrementallygrowaneffectivesolutionovermultipleiterations.The

RationalUnifiedProcesssupportsan iterativeapproach todevelopment thataddresses thehighest

risk itemsateverystage in the lifecycle, significantly reducingaprojects riskprofile.This iterative

approach helps you attack risk through demonstrable progress frequent, executable releases that

enable continuous end user involvement and feedback. Because each iteration ends with an

executable release, thedevelopment teamstays focusedonproducing results,and frequentstatus

checkshelpensurethattheprojectstaysonschedule.An iterativeapproachalsomakes iteasierto

accommodatetacticalchangesinrequirements,featuresorschedule.

ManageRequirements

TheRationalUnifiedProcessdescribeshow toelicit,organize,anddocumentrequired functionality

andconstraints; trackanddocument tradeoffsanddecisions;andeasily captureand communicate

businessrequirements.Thenotionsofusecaseandscenariosproscribedintheprocesshasprovento

beanexcellentway tocapture functional requirementsand toensure that thesedrive thedesign,

implementationand testingof software,making itmore likely that the finalsystem fulfills theend

userneeds. They provide coherent and traceable threads through both the development and the

deliveredsystem.

UseComponentbasedArchitectures

Theprocessfocusesonearlydevelopmentandbaseliningofarobustexecutablearchitecture,priorto

committing resources for fullscaledevelopment. Itdescribeshow todesigna resilientarchitecture

thatisflexible,accommodateschange,isintuitivelyunderstandable,andpromotesmore

effective software reuse. The Rational Unified Process supports componentbased software

development.

Components are nontrivialmodules, subsystems that fulfill a clear function. The RationalUnified

Process provides a systematic approach to defining an architecture using new and existing

components.Theseareassembled inawelldefinedarchitecture,eitheradhoc,or inacomponent

infrastructuresuchastheInternet,CORBA,andCOM,forwhichanindustryofreusablecomponents

isemerging.


20/23

VisuallyModelSoftware

The process shows you how to visuallymodel software to capture the structure and behavior of

architecturesand components.Thisallows you tohide thedetailsandwrite codeusing graphical

buildingblocks.Visualabstractionshelpyou communicatedifferentaspectsofyour software; see

howtheelementsofthesystemfittogether;makesurethatthebuildingblocksareconsistentwith

your code; maintain consistency between a design and its implementation; and promote

unambiguous communication. The industrystandardUnifiedModeling Language (UML), createdby

RationalSoftware,isthefoundationforsuccessfulvisualmodeling.

VerifySoftwareQuality

Poorapplicationperformanceandpoorreliabilityarecommonfactorswhichdramaticallyinhibitthe

acceptabilityoftodayssoftwareapplications.Hence,qualityshouldbereviewedwithrespecttothe

requirementsbasedon reliability, functionality, applicationperformance and systemperformance.

The Rational Unified Process assists you in the planning, design, implementation, execution, and

evaluationofthesetesttypes.Qualityassessmentisbuiltintotheprocess,inallactivities,involvingall

participants, using objectivemeasurements and criteria, and not treated as an afterthought or a

separateactivityperformedbyaseparategroup.

ControlChangestoSoftware

Theabilitytomanagechangeismakingcertainthateachchangeisacceptable,andbeingabletotrack

changes isessential inanenvironment inwhichchange is inevitable.Theprocessdescribeshow to

control,trackandmonitorchangestoenablesuccessful iterativedevelopment. Italsoguidesyou in

howtoestablishsecureworkspacesforeachdeveloperbyprovidingisolationfromchangesmadein

otherworkspacesandbycontrollingchangesofallsoftwareartifacts(e.g.,models,code,documents,

etc.).Anditbringsateamtogethertoworkasasingleunitbydescribinghowtoautomateintegration

andbuildmanagement.

TheRationalUnifiedProcessproductconsistsof:

Awebenabledsearchableknowledgebaseprovidingallteammemberswithguidelines,templates,andtoolmentorsforallcriticaldevelopmentactivities.Theknowledgebasecanfurtherbebroken

downto:

Extensiveguidelinesforall teammembers,andallportionsof thesoftware lifecycle.Guidance isprovided for both the highlevel thought process, as well as for the more tedious daytoday

activities.Theguidance ispublished inHTMLform foreasyplatformindependentaccessonyour

desktop.

Toolmentorsprovidinghandsonguidancefortoolscoveringthefulllifecycle.Thetoolmentorsarepublished in HTML form for easy platformindependent access on your desktop. See section

"IntegrationwithTools"formoredetails.


21/23

RationalRoseexamplesandtemplatesprovidingguidanceforhowtostructuretheinformationinRationalRosewhenfollowingtheRationalUnifiedProcess(RationalRoseisRational'stoolforvisual

modeling)

SoDA templates more than10 SoDA templates thathelpsautomate softwaredocumentation(SoDA

is

Rationales

Document

Automation

Tool)

MicrosoftWordtemplatesmorethan30WordtemplatesassistingdocumentationinallworkflowsandallportionsofthelifecycleMicrosoftProjectPlans

Many managers find it difficult to create project plans that reflects an iterative developmentapproach. Our templates jump start the creation of project plans for iterative development,

accordingtotheRationalUnifiedProcess.

Development Kit: Describes how to customize and extend the Rational Unified Process to thespecificneedsoftheadoptingorganizationorproject,aswellasprovidestoolsandtemplatesto

assisttheeffort.Thisdevelopmentkitisdescribedinmoredetaillaterinthissection.

Access toResourceCentercontaining the latestwhitepapers,updates,hints,and techniques,aswellasreferencestoaddonproductsandservices.

Abook"RationalUnifiedProcessAn Introduction",byPhilippeKruchten,publishedbyAddisonWesley.Thebook ison277pagesandprovidesagood introductionandoverviewtotheprocess

andtheknowledgebase.

6. DescribetheCapabilityMaturityModelwithsuitablerealtimeexamples.Ans: The Capability Maturity Model (CMM)) is a multistaged, process definition model intended to

characterize and guide the engineering excellence or maturity of an organizations software

development processes. The Capability Maturity Model: Guidelines for Improving the Software

Process(1995)containsanauthoritativedescription.SeealsoPaulketal. (1993)andCurtis,Hefley,

andMiller(1995)and,forgeneralremarksoncontinuousprocessimprovement,Somerville,Sawyer,

and Viller (1999) (see Table 3.2). The model prescribes practices for planning, engineering, and

managingsoftwaredevelopmentandmaintenanceandaddressestheusualgoalsoforganizational

system engineering processes: namely, quality improvement, risk reduction, cost reduction,

predictableprocess,andstatisticalqualitycontrol(Oshana&Linger1999).

However, the model is not merely a program for how to develop software in a professional,

engineeringbased manner; it prescribes an evolutionary improvement path from an ad hoc,

immature

process

to

a

mature,

disciplined

process

(Oshana&

Linger

1999).

Walnau,

Hissam,

and

Seacord (2002) observe that the ISO and CMM process standards established the context for

improvingthepracticeofsoftwaredevelop meantby identifyingrolesandbehaviorsthatdefinea

softwarefactory.

TheCMMidentifiesfivelevelsofsoftwaredevelopmentmaturityinanorganization:

Atlevel1,theorganizationssoftwaredevelopmentfollowsnoformaldevelopmentprocess. Theprocessmaturityissaidtobeatlevel2ifsoftwaremanagementcontrolshavebeenintroducedand some softwareprocess is followed.Adecisive featureof this level is that theorganizations

process is supposed tobe such that it can repeat the level of performance that it achieved on


22/23

similarsuccessfulpastprojects.ThisisrelatedtoacentralpurposeoftheCMM:namely,toimprove

the predictability of the development process significantly. Themajor technical requirement at

level2isincorporationofconfigurationmanagementintotheprocess.

Configurationmanagement(orchangemanagement,asitissometimescalled)referstotheprocesses

usedtokeeptrackofthechangesmadetothedevelopmentproduct(includingallthe intermediate

deliverables) and the multifarious impacts of these changes. These impacts range from the

recognitionofdevelopmentproblems; identificationoftheneedforchanges;alterationofprevious

work;verification thatagreeduponmodificationshavecorrected theproblemand thatcorrections

havenothadanegativeimpactonotherpartsofthesystem;etc.

Anorganization is said tobeat level3 if thedevelopmentprocess is standardand consistent.The

project management practices of the organization are supposed to have been formally agreed

on,defined,andcodifiedatthisstageofprocessmaturity.

Organizations

at

level

4

are

presumed

to

have

put

into

place

qualitative

and

quantitative

measures

of organizational process. These process metrics are intended to monitor development and to

signaltroubleandindicatewhereandhowadevelopmentisgoingwrongwhenproblemsoccur.

Organizationsatmaturitylevel5areassumedtohaveestablishedmechanismsdesignedtoensurecontinuousprocessimprovementandoptimization.Themetricfeedbacksatthisstagearenotjust

applied to recognize and control problems with the current project as they were in level4

organizations.Theyareintendedtoidentifypossiblerootcausesintheprocessthathaveallowed

theproblemstooccurandtoguidetheevolutionoftheprocesssoastopreventtherecurrenceof

suchproblemsinfutureprojects,suchasthroughtheintroductionofappropriatenewtechnologies

andtools.

ThehighertheCMMmaturitylevelis,themoredisciplined,stable,andwelldefinedthedevelopment

processisexpectedtobeandtheenvironmentisassumedtomakemoreuseofautomatedtoolsand

theexperiencegainedfrommanypastsuccesses(Zhiying2003).Thestagedcharacterofthemodel

lets organizationsprogress up thematurity ladder by settingprocess targets for theorganization.

Eachadvancereflectsafurtherdegreeofstabilizationofanorganizationsdevelopmentprocess,with

eachlevelinstitutionaliz[ing]adifferentaspectoftheprocess(Oshana&Linger1999).

EachCMM levelhasassociatedkeyprocessareas (KPA) that correspond toactivities thatmustbe

formalizedtoattainthat level.Forexample,theKPAsat level2 includeconfigurationmanagement,

quality assurance, project planning and tracking, and effective management of subcontracted

software.TheKPAsatlevel3includeintergroupcommunication,training,processdefinition,product

engineering, and integrated software management. Quantitative process management and

development quality define the required KPAs at level 4. Level 5 institutionalizes process and

technologychangemanagementandoptimizesdefectprevention.

Bamberger(1997),oneoftheauthorsoftheCapabilityMaturityModel,addresseswhatshebelieves

are somemisconceptionsabout themodel.Forexample,sheobserves that themotivation for the

secondlevel,inwhichtheorganizationmusthavearepeatablesoftwareprocess,arisesasadirect


23/23

response to the historical experience of developers when their software development is out of

control(Bamberger1997).Oftenthisisforreasonshavingtodowithconfigurationmanagementor

mismanagement!Amongthemanysymptomsofconfigurationmismanagementare:confusionover

which version of a file is the current official one; inadvertent side effects when repairs by one

developerobliteratethechangesofanotherdeveloper;inconsistenciesamongtheeffortsofdifferent

developers;etc.

Akeyappropriateresponsetosuchactualorpotentialdisorder istogetcontroloftheproductand

theproductpiecesunderdevelopment(configurationmanagement)by(Bamberger1997):

Controlling the feature set of the product so that the impact/s of changes are more fullyunderstood(requirementsmanagement)

Using the feature set to estimate the budget and schedule while leveraging as much pastknowledgeaspossible(projectplanning)

Ensuringschedulesandplansarevisibletoallthestakeholders(projecttracking) Ensuringthattheteamfollows itsownplanandstandardsandcorrectsdiscrepancieswhentheyoccur(qualityassurance)

BambergercontendsthatthiskindofprocessestablishesthebasicstabilityandvisibilitythataretheessenceoftheCMMrepeatablelevel.

MC0071_February 2011_Software Engineering-Assignement

Documents