July 2011

Master of Computer Application (MCA) - Semester 3

Mc0071 5oftwore nqineerinq 4 credits
4ssiqnment 5et 1

ues 1 whot is the importonce of 5oftwore vo/idotion in testinq?
4nswer
5oftwore vo/idotion 4/so known os softwore quo/ity contro/
vo/idotion checks thot the product desiqn sotisfies or fits the intended usoqe
{hiqh/eve/ checkinq) ie you bui/t the riqht product 1his is done throuqh
dynomictestinq ond other forms of review
verificotion 1he process of evo/uotinq softwore to determine whether
the products of o qiven deve/opment phose sotisfy the conditions
imposed ot the stort of thot phose
vo/idotion 1he process of evo/uotinq softwore durinq or ot the end of
the deve/opment process to determine whether it sotisfies specified
requirements
ln other words vo/idotion ensures thot the product octuo//y meets the users
needs ond thot the specificotions were correct in the first p/oce whi/e
verificotion is ensurinq thot the product hos been bui/t occordinq to the
requirements ond desiqn specificotions vo/idotion ensures thot you bui/t the
riqht thinq verificotion ensures thot you bui/t it riqht vo/idotion confirms
thot the product os provided wi// fu/fi// its intended use
lrom testinq perspective
lou/t wronq or missinq function in the code
? loi/ure the monifestotion of o fou/t durinq execution
? Mo/function occordinq to its specificotion the system does not meet
its specified functiono/ity
within the mode/inq ond simu/otion community the definitions of vo/idotion
verificotion ond occreditotion ore simi/or
? vo/idotion is the process of determininq the deqree to which o mode/
simu/otion or federotion of mode/s ond simu/otions ond their
ossocioted doto ore occurote representotions of the reo/ wor/d from the
perspective of the intended use{s)
4ccreditotion is the formo/ certificotion thot o mode/ or simu/otion is
occeptob/e to be used for o specific purpose
verificotion is the process of determininq thot o computer mode/
simu/otion or federotion of mode/s ond simu/otions imp/ementotions
xp/oin the fo//owinq concepts with respect to 5oftwore ke/iobi/ity
4) 5oftwore ke/iobi/ity Metrics 8) Proqromminq for ke/iobi/ity
4nswer
4) 5oftwore ke/iobi/ity Metrics
lntroduction
computers ond computer systems hove become o siqnificont port of our modern
society lt is virtuo//y impossib/e to conduct mony doytodoy octivities without the oid of
computer systems contro//ed by softwore 4s more re/ionce is p/oced on these softwore systems
it is essentio/ thot they operote in o re/iob/e monner loi/ure to do so con resu/t in hiqh
monetory property or humon /oss
1he N454 5oftwore 4ssuronce 5tondord N45451u87l98 defines softwore re/iobi/ity
os o discip/ine of softwore ossuronce thot
1 uefines the requirements for softwore contro//ed system fou/t/foi/ure detection
iso/otion ond recovery
keviews the softwore deve/opment processes ond products for softwore error
prevention ond/or reduced functiono/ity stotes ond
l uefines the process for meosurinq ond ono/ytinq defects ond defines/derives the
re/iobi/ity ond mointoinobi/ity foctors
1his section wi// provide softwore proctitioners with o bosic overview of softwore
re/iobi/ity os we// os too/s ond resources on softwore re/iobi/ity
5oftwore ke/iobi/ity 1echniques
ke/iobi/ity techniques con be divided into two coteqories 1rendinq ond Predictive
O 1rendinq re/iobi/ity trocks the foi/ure doto produced by the softwore system to
deve/op o re/iobi/ity operotiono/ profi/e of the system over o specified time
O Predictive re/iobi/ity ossiqns probobi/ities to the operotiono/ profi/e of o softwore
system for exomp/e the system hos o 5 percent chonce of foi/ure over the next
0 operotiono/ hours
ln proctice re/iobi/ity trendinq is more oppropriote for softwore whereos predictive
re/iobi/ity is more suitob/e for hordwore 1rendinq re/iobi/ity con be further c/ossified
into four coteqories rror 5eedinq loi/ure kote curve littinq ond ke/iobi/ity 6rowth
O rror 5eedinq stimotes the number of errors in o proqrom by usinq mu/tistoqe
somp/inq rrors ore divided into indiqenous ond induced {seeded) errors 1he
unknown number of indiqenous errors is estimoted from the number of induced
errors ond the rotio of errors obtoined from debuqqinq doto
O loi/ure kote ls used to study the proqrom foi/ure rote per fou/t ot the foi/ure
intervo/s 4s the number of remoininq fou/ts chonqe the foi/ure rote of the
proqrom chonqes occordinq/y
O curve littinq uses stotistico/ reqression ono/ysis to study the re/otionship
between softwore comp/exity ond the number of fou/ts in o proqrom os we// os
the number of chonqes or foi/ure rote
O ke/iobi/ity 6rowth Meosures ond predicts the improvement of re/iobi/ity
proqroms throuqh the testinq process ke/iobi/ity qrowth o/so represents the
re/iobi/ity or foi/ure rote of o system os o function of time or the number of test
coses
5oftwore ke/iobi/ity Metrics
Listed be/ow ore some stotic code ond dynomic metrics which ore re/oted to softwore
re/iobi/ity 1he stotic code metric is divided into three coteqories with meosurements under
eoch Line count comp/exity ond 5tructure ond ObjectOriented metrics 1he dynomic metric
hos two mojor meosurements loi/ure kote uoto ond Prob/em keports
5totic code Metrics
O Line count
4 Lines of code {LOc)
4 5ource Lines of code {5LOc)
O comp/exity ond 5tructure
4 cyc/omote comp/exity {cc)
4 Number of Modu/es
4 Number of 6o 1o 5totements {6O1O)
O ObjectOriented
4 Number of c/osses
4 weiqhted Methods per c/oss {wMc)
4 coup/inq 8etween Objects {c8O)
4 kesponse for o c/oss {klc)
4 Number of chi/d c/osses {NOc)
4 uepth of lnheritonce 1ree {ul1)
uynomic Metrics
O loi/ure kote uoto
O Prob/em keports




8osic Mothemotico/ concepts
Mothemotico//y re/iobi/ity k{t) is the probobi/ity thot o system wi// be successfu/ in the
intervo/ from time 0 to time t
k{t) P{1 t) t 0
where 1 is o rondom voriob/e denotinq the timetofoi/ure or foi/ure time
unre/iobi/ity l{t) o meosure of foi/ure is defined os the probobi/ity thot the system wi// foi/ by
time t
l{t) P{1 t) t 0
ln other words l{t) is the foi/ure distribution function 1he fo//owinq re/otionship opp/ies to
re/iobi/ity in qenero/ 1he ke/iobi/ity k{t) is re/oted to foi/ure probobi/ity l{t) by
k{t) 1 l{t)
8) Proqromminq for ke/iobi/ity
Modern static analyzers have been used to find hundreds of bugs in the Linux kernel
and many large commercial applications without the false alarm rate seen in previous
generation tools such as lint. Static analyzers find bugs in source code without the need for
execution or test cases. 1hey parse the source code and then perform dataflow analysis to find
potential error cases on all possible paths through each function. Ao technique is a silver
bullet, and static analysis is no exception. Static analysis is usually only practical for certain
categories of errors and cannot replace functional testing. However, compared with traditional
QA and testing techniques, static analysis provides a way to achieve much higher coverage of
corner cases in the code. Compared with manual code review, static analysis is impartial,
thorough, and cheap to perform regularly.
Inconsistent Assumptions
Mony types of buqs ore coused by mokinq inconsistent ossumptions consider Listinq One from /ine
188 of /inux4/drivers/scsi/oic7xxx/oic7770_osmc 1his seems /ike o stronqe error report why
wou/dohc_o//oc{) free the orqument nome? Lookinq ot the imp/ementotion you see Listinq 1wo
c/eor/y if this function returns NuLL then the orqument nome is supposed to be freed but the co//er
either didnt know or forqot this focet of the interfoce why wosnt this found in testinq? Probob/y
becouse this is code thot runs when o device driver is initio/ited ond this is usuo//y ot boot time when
mo//oc is un/ike/y to foi/ unfortunote/y this is not o/woys the cose ond it is possib/e thot o device
wou/d be initio/ited /oter {for exomp/e with devices thot con be hotp/uqqed)
nconsistent assumptions are relatively easy to avoid when initially designing and
writing code, but they are difficult to avoid when maintaining code. Most code changes are
usually localized to single functions or files, but assumptions made about that code may be
scattered throughout the code base.
rror-Handling Code
Developers typically program with the primary goal of implementing core functionality, while
handling exceptional cases is often seen as a distraction. Furthermore, designing test cases
that exercise error paths is difficult because it requires artificially inducing errors. Despite the
difficulty of handling errors, it is critical to do. Unfortunately, debugging code often passes as
error-handling code, such as in Listing Four from a Linux SCS device driver. 1he problem in
this case is that the call to printk does not terminate execution or signal an error to the caller.
ither the error check on line 918 is unnecessary, or the accesses on 92-922 will be out of
bounds, leading to memory corruption. 1here are plenty of cases where half-hearted error
checking potentially leads to serious errors. Code auditors should determine whether or not
error checking is needed, and that it is done properly when required.
1he error just described probably occurred because the programmer simply forgot to free the
memory. 1he widely used practice of having an error exit that performs cleanup would have
prevented this error. Alternatively, arenas or pools could have prevented this error by keeping
memory associated with a particular task together, then freeing all of the memory allocated by
the pool once the task is finished. n C++, the commonly used Resource Acquisition s
nitialization (RA idiom could prevent this sort of error by automating the cleanup task in
the destructors of scoped objects. However, take care even when using RA because resources
that must survive past the end of the scope must have their cleanup actions prevented. A
common way of doing this is to provide acommit( method for the RA object, but this
presents the potential for an error to occur if a commit( call is forgotten. n short, be careful
because it is ultimately up to you to decide how long objects should survive.


ues l 5uqqest six reosons why softwore re/iobi/ity is importont usinq on exomp/e exp/oin the
difficu/ties of describinq whot softwore re/iobi/ity meons
4nswer
1he need for a means to objectively determine software reliability comes from the desire to
apply the techniques of contemporary engineering fields to the development of software. 1hat
desire is a result of the common observation, by both lay-persons and specialists, that
computer software does not work the way it ought to. n other words, software is seen to
exhibit undesirable behaviour, up to and including outright failure, with consequences for the
data which is processed, the machinery on which the software runs, and by extension the
people and materials which those machines might negatively affect. 1he more critical the
application of the software to economic and production processes, or to life-sustaining
systems, the more important is the need to assess the software's reliability.
Regardless of the criticality of any single software application, it is also more and more
frequently observed that software has penetrated deeply into most every aspect of modern life
through the technology we use. t is only expected that this infiltration will continue, along
with an accompanying dependency on the software by the systems which maintain our society.
As software becomes more and more crucial to the operation of the systems on which we
depend, the argument goes, it only follows that the software should offer a concomitant level
of dependability. n other words, the software should behave in the way it is intended, or even
better, in the way it should.
4 softwore quo/ity foctor is o nonfunctiono/ requirement for o softwore proqrom which is not co//ed
up by the customers controct but neverthe/ess is o desirob/e requirement which enhonces the quo/ity
of the softwore proqrom Note thot none of these foctors ore binory thot is they ore not "either you
hove it or you dont" troits kother they ore chorocteristics thot one seeks to moximite in ones
softwore to optimite its quo/ity 5o rother thon oskinq whether o softwore product "hos" foctor x osk
insteod the deqree to which it does {or does not)
5ome softwore quo/ity foctors ore /isted here
understondobi/ity
c/ority of purpose 1his qoes further thon just o stotement of purpose o// of the desiqn ond user
documentotion must be c/eor/y written so thot it is eosi/y understondob/e 1his is obvious/y subjective
in thot the user context must be token into occount for instonce if the softwore product is to be used
by softwore enqineers it is not required to be understondob/e to the /oymon



comp/eteness
Presence of o// constituent ports with eoch port fu//y deve/oped 1his meons thot if the code
co//s o subroutine from on externo/ /ibrory the softwore pockoqe must provide reference to thot
/ibrory ond o// required porometers must be possed 4// required input doto must o/so be ovoi/ob/e
conciseness
Minimitotion of excessive or redundont informotion or processinq 1his is importont where
memory copocity is /imited ond it is qenero//y considered qood proctice to keep /ines of code to o
minimum lt con be improved by rep/ocinq repeoted functiono/ity by one subroutine or function which
ochieves thot functiono/ity lt o/so opp/ies to documents
Portobi/ity
consistency
uniformity in nototion symbo/oqy oppeoronce ond termino/oqy within itse/f
Mointoinobi/ity
Propensity to foci/itote updotes to sotisfy new requirements 1hus the softwore product thot is
mointoinob/e shou/d be we//documented shou/d not be comp/ex ond shou/d hove spore copocity for
memory storoqe ond processor uti/itotion ond other resources
1estobi/ity
uisposition to support occeptonce criterio ond evo/uotion of performonce 5uch o
chorocteristic must be bui/tin durinq the desiqn phose if the product is to be eosi/y testob/e o comp/ex
desiqn /eods to poor testobi/ity
usobi/ity
convenience ond proctico/ity of use 1his is offected by such thinqs os the humoncomputer
interfoce 1he component of the softwore thot hos most impoct on this is the user interfoce {ul) which
for best usobi/ity is usuo//y qrophico/ {ie o 6ul)
ke/iobi/ity
4bi/ity to be expected to perform its intended functions sotisfoctori/y 1his imp/ies o time
foctor in thot o re/iob/e product is expected to perform correct/y over o period of time lt o/so
encomposses environmento/ considerotions in thot the product is required to perform correct/y in
whotever conditions it finds itse/f {sometimes termed robustness)
fficiency
lu/fi//ment of purpose without woste of resources such os memory spoce ond processor
uti/itotion network bondwidth time etc


5ecurity
4bi/ity to protect doto oqoinst unouthorited occess ond to withstond mo/icious or inodvertent
interference with its operotions 8esides the presence of oppropriote security mechonisms such os
outhenticotion occess contro/ ond encryption security o/so imp/ies resi/ience in the foce of mo/icious
inte//iqent ond odoptive ottockers
1ime xomp/e
1here ore two mojor differences between hordwore ond softwore curves One difference is thot in the
/ost phose softwore does not hove on increosinq foi/ure rote os hordwore does ln this phose
softwore is opproochinq obso/escence there ore no motivotion for ony upqrodes or chonqes to the
softwore 1herefore the foi/ure rote wi// not chonqe 1he second difference is thot in the usefu//ife
phose softwore wi// experience o drostic increose in foi/ure rote eoch time on upqrode is mode 1he
foi/ure rote /eve/s off qroduo//y port/y becouse of the defects found ond fixed ofter the upqrodes





















"ues. 4- What are the essential skills and traits necessary for effective project
managers in successfully handling projects?
4nswer
1he 5uccessfu/ Project Monoqer
4 successfu/ project monoqer knows how to brinq toqether the definition ond contro/ e/ements
ond operote them efficient/y 1hot meons you wi// need to opp/y the /eodership ski//s you o/reody opp/y
in runninq o deportment ond proctice the orqonitotiono/ obi/ities you need to constont/y /ook to the
future
ln other words if youre o quo/ified deportment monoqer you o/reody possess the ski//s ond ottributes
for succeedinq os o project monoqer 1he criterio by which you wi// be se/ected wi// be simi/or
chonces ore the project youre ossiqned wi// hove o direct re/otionship to the ski//s you need just to do
your job lor exomp/e
Orqonitotiono/ ond /eodership experience 4n executive seekinq o quo/ified project monoqer
usuo//y seeks someone who hos o/reody demonstroted the obi/ity to orqonite work ond to /eod others
ne or she ossumes thot you wi// succeed in o comp/icoted /onqterm project primori/y becouse you
hove o/reody demonstroted the required ski//s ond experience
contoct with needed resources lor projects thot invo/ve o /ot of coordinotion between
deportments divisions or subsidiories top monoqement wi// /ook for o project monoqer who o/reody
communicotes outside of o sinq/e deportment lf you hove the contocts required for o project it wi//
noturo//y be ossumed thot you ore suited to run o project ocross deportmento/ /ines
4bi/ity to coordinote o diverse resource poo/ 8y itse/f contoct outside of your deportment moy
not be enouqh You must o/so be ob/e to work with o voriety of peop/e ond deportments even when
their bockqrounds ond discip/ines ore dissimi/or lor exomp/e os o copob/e project monoqer you must
be ob/e to de/eqote ond monitor work not on/y in oreos fomi/ior to your own deportment but in oreos
thot ore o/ien to your bockqround
communicotion ond proceduro/ ski//s 4n effective project monoqer wi// be ob/e to convey ond
receive informotion to ond from o number of teom members even when porticu/or points of view ore
different from his own lor exomp/e o strict/y odministrotive monoqer shou/d understond the
priorities of o so/es deportment or o customer service monoqer moy need to understond whot
motivotes o production crew
1hese project monoqement quo/ificotions reod /ike o /ist of evo/uotion points for every
deportment monoqer lf you think of the process of runninq your deportment os o project of its own
then you o/reody understond whot its /ike to orqonite o projectthe difference of course beinq thot
the project tokes p/oce in o finite time period whereos your deportmento/ tosks ore onqoinq 1hus
every successfu/ monoqer shou/d be reody to tock/e o project provided it is re/oted to his or her ski//s
resources ond experience
"ues. 5:- Which are the four phases of development according to Rational
Unified Process?
4nswer
1he kotiono/ unified Process is o 5oftwore nqineerinq Process lt provides o discip/ined
opprooch to ossiqninq tosks ond responsibi/ities within o deve/opment orqonitotion lts qoo/ is to
ensure the production of hiqhquo/ity softwore thot meets the needs of its endusers within o
predictob/e schedu/e ond budqet
1he kotiono/ unified Process is o process product deve/oped ond mointoined by kotiono/
5oftwore 1he deve/opment teom for the kotiono/ unified Process ore workinq c/ose/y with customers
portners kotiono/es product qroups os we// os kotiono/es consu/tont orqonitotion to ensure thot the
process is continuous/y updoted ond improved upon to ref/ect recent experiences ond evo/vinq ond
proven best proctices 1he kotiono/ unified Process enhonces teom productivity by providinq every
teom member with eosy occess to o know/edqe bose with quide/ines temp/otes ond too/ mentors for
o// critico/ deve/opment octivities 8y hovinq o// teom members occessinq the some know/edqe bose
no motter if you work with requirements desiqn test project monoqement or confiqurotion
monoqement we ensure thot o// teom members shore o common /onquoqe process ond view of how
to deve/op softwore
1he kotiono/ unified Process octivities creote ond mointoin mode/s kother thon focusinq on
the production of /orqe omount of poper documents the unified Process emphosites the deve/opment
ond mointenonce of mode/ssemontico//y rich representotions of the softwore system under
deve/opment
1he kotiono/ unified Process is o quide for how to effective/y use the unified Mode/inq
Lonquoqe {uML) 1he uML is on industrystondord /onquoqe thot o//ows us to c/eor/y communicote
requirements orchitectures ond desiqns 1he uML wos oriqino//y creoted by kotiono/ 5oftwore ond is
now mointoined by the stondords orqonitotion Object Monoqement 6roup {OM6)
ffective uep/oyment of 8est Proctices
1he kotiono/ unified Process describes how to effective/y dep/oy commercio//y proven
opprooches to softwore deve/opment for softwore deve/opment teoms 1hese ore co//ed "best
proctices" not so much becouse you con precise/y quontify their vo/ue but rother becouse they ore
observed to be common/y used in industry by successfu/ orqonitotions 1he kotiono/ unified Process
provides eoch teom member with the quide/ines temp/otes ond too/ mentors necessory for the entire
teom to toke fu// odvontoqe of omonq others the fo//owinq best proctices
1 ueve/op softwore iterotive/y
Monoqe requirements
l use componentbosed orchitectures kotiono/ unified Process 8est Proctices for 5oftwore
deve/opment 1eoms
4 visuo//y mode/ softwore
5 verify softwore quo/ity
contro/ chonqes to softwore
ueve/op 5oftwore lterotive/y
6iven todoys sophisticoted softwore systems it is not possib/e to sequentio//y first define the
entire prob/em desiqn the entire so/ution bui/d the softwore ond then test the product ot the end 4n
iterotive opprooch is required thot o//ows on increosinq understondinq of the prob/em throuqh
successive refinements ond to incremento//y qrow on effective so/ution over mu/tip/e iterotions 1he
kotiono/ unified Process supports on iterotive opprooch to deve/opment thot oddresses the hiqhest
risk items ot every stoqe in the /ifecyc/e siqnificont/y reducinq o projects risk profi/e 1his iterotive
opprooch he/ps you ottock risk throuqh demonstrob/e proqress frequent executob/e re/eoses thot
enob/e continuous end user invo/vement ond feedbock 8ecouse eoch iterotion ends with on
executob/e re/eose the deve/opment teom stoys focused on producinq resu/ts ond frequent stotus
checks he/p ensure thot the project stoys on schedu/e 4n iterotive opprooch o/so mokes it eosier to
occommodote toctico/ chonqes in requirements feotures or schedu/e
Monoqe kequirements
components ore nontrivio/ modu/es subsystems thot fu/fi// o c/eor function 1he kotiono/ unified
Process provides o systemotic opprooch to defininq on orchitecture usinq new ond existinq
components 1hese ore ossemb/ed in o we//defined orchitecture either od hoc or in o component
infrostructure such os the lnternet cOk84 ond cOM for which on industry of reusob/e components is
emerqinq
visuo//y Mode/ 5oftwore
Poor opp/icotion performonce ond poor re/iobi/ity ore common foctors which dromotico//y
inhibit the occeptobi/ity of todoys softwore opp/icotions nence quo/ity shou/d be reviewed with
respect to the requirements bosed on re/iobi/ity functiono/ity opp/icotion performonce ond system
performonce 1he
kotiono/ unified Process ossists you in the p/onninq desiqn imp/ementotion execution ond
evo/uotion of these test types uo/ity ossessment is bui/t into the process in o// octivities invo/vinq o//
porticiponts usinq objective meosurements ond criterio ond not treoted os on ofterthouqht or o
seporote octivity performed by o seporote qroup
contro/ chonqes to 5oftwore
1he kotiono/ unified Process product consists of
- 4 webenob/ed seorchob/e know/edqe bose providinq o// teom members with quide/ines temp/otes
ond too/ mentors for o// critico/ deve/opment octivities 1he know/edqe bose con further be broken
down to
- xtensive quide/ines for o// teom members ond o// portions of the softwore /ifecyc/e
6uidonce is provided for both the hiqh/eve/ thouqht process os we// os for the more tedious doyto
doy octivities 1he quidonce is pub/ished in n1ML form for eosy p/otformindependent occess on your
desktop
- 1oo/ mentors providinq hondson quidonce for too/s coverinq the fu// /ifecyc/e 1he too/
mentors ore pub/ished in n1ML form for eosy p/otformindependent occess on your desktop 5ee
section
lnteqrotion with 1oo/s for more detoi/s
- kotiono/ kose exomp/es ond temp/otes providinq quidonce for how to structure the
informotion in kotiono/ kose when fo//owinq the kotiono/ unified Process {kotiono/ kose is kotiono/s
too/ for visuo/ mode/inq)
- 5ou4 temp/otes more thon 10 5ou4 temp/otes thot he/ps outomote softwore
documentotion {5ou4 is kotiono/es uocument 4utomotion 1oo/)
- Microsoft word temp/otes more thon l0 word temp/otes ossistinq documentotion in o//
workf/ows ond o// portions of the /ifecyc/e
- Microsoft Project P/ons
Mony monoqers find it difficu/t to creote project p/ons thot ref/ects on iterotive deve/opment
opprooch Our temp/otes jump stort the creotion of project p/ons for iterotive deve/opment occordinq
to the kotiono/ unified Process


July 2011
Master of Computer Application (MCA) - Semester 3
Mc0071 5oftwore nqineerinq 4 credits
4ssiqnment 5et

1 xp/oin the fo//owinq with respect to confiqurotion Monoqement
4) chonqe Monoqement
chonqe monoqement is o systemotic opprooch to deo/inq with chonqe both from the perspective of
on orqonitotion ond on the individuo/ /eve/
4 somewhot ombiquous term chonqe monoqement hos ot /eost three different ospects inc/udinq
odoptinq to chonqe contro//inq chonqe ond effectinq chonqe 4 prooctive opprooch to deo/inq with
chonqe is ot the core of o// three ospects lor on orqonitotion chonqe monoqement meons defininq
ond imp/ementinq procedures ond/or techno/oqies to deo/ with chonqes in the business environment
ond to profit from chonqinq opportunities
l15M chonqe monoqement is not typico//y responsib/e for overseeinq chonqes thot occur within
dep/oyment or deve/opment projects which ore typico//y de/eqoted to o chonqe monoqement process
dictoted by the project monoqement methodo/oqy odopted for the project nowever c/ose /ioison
between deve/opment project monoqers ond the chonqe Monoqer is expected ond the project
monoqer moy be required to uti/ite chonqe Monoqement for items within the production or test
environments thot ore required for testinq or re/eose
8) version ond ke/eose Monoqement
1he release management process is a relatively new but rapidly growing discipline within
software engineering of managing software releases.
As software systems, software development processes, and resources become more distributed,
they invariably become more specialized and complex. Furthermore, software products
(especially web applications are typically in an ongoing cycle of development, testing, and
release. Add to this an evolution and growing complexity of the platforms on which these
systems run, and it becomes clear there are a lot of moving pieces that must fit together
seamlessly to guarantee the success and long-term value of a product or project.
1he need therefore exists for dedicated resources to oversee the integration and flow of
development, testing, deployment, and support of these systems. Although project managers
have done this in the past, they generally are more concerned with high-level, "grand design"
aspects of a project or application, and so often do not have time to oversee some of the more
technical or day-to-day aspects. Release managers (aka "RMs" address this need. 1hey must
have a general knowledge of every aspect of the software development process, various
applicable operating systems and software application or platforms, as well as various
business functions and perspectives.
A release manager is:
O loci/itotor serves os o /ioison between voryinq business units to quorontee smooth ond time/y
de/ivery of softwore products or updotes
O 6otekeeper "ho/ds the keys" to production systems/opp/icotions ond tokes responsibi/ity for
their imp/ementotions
O 4rchitect he/ps to identify creote ond/or imp/ement processes or products to efficient/y
monoqe the re/eose of code
O 5erver opp/icotion support enqineer he/p troub/eshoot prob/ems with on opp/icotion
{o/thouqh not typico//y ot o code /eve/)
O coordinotor uti/ited to coordinote disporote source trees projects teoms ond components
Some of the challenges facing a software release manager include the management of:
O 5oftwore defects
O lssues
O kisks
O 5oftwore chonqe requests
O New deve/opment requests {odditiono/ feotures ond functions)
O uep/oyment ond pockoqinq
O New deve/opment tosks














uiscuss the contro/ mode/s in detoi/s
Ans.
Control models:
1he models for structuring a system are concerned with how a system is decomposed into sub-
systems. 1o work as a system, sub-systems must be controlled so that their services are
delivered to the right place at the right time. Structural models do not (and should not include
control information. Rather, the architect should organize the sub-systems according to some
control model, which supplements the structure model is used. Control models at the
architectural level are concerned with the control flow between sub-systems.
1wo general approaches to control can be identified:
(1 Centralized control: One sub-system has overall responsibility for control and starts and
stops other sub-systems. t may also devolve control to another sub-system but will expect to
have this control responsibility returned to it.
(2 vent-based control: Rather than control information being embedded in a sub-system,
each sub-system can respond to externally generated events. 1hese events might come from
other sub-systems or from the environment of the system.
Control models supplement structural models. All the above structural models may be
implemented using either centralized or event-based control.
Centralized control
n a centralized control model, one sub-system is designated as the system controller and has
responsibility for managing the execution of other sub-systems.

shows an illustration of a centralized management model of control for a concurrent system.
1his model is often used in :soft' real-time systems, which do not have very tight time
constraints. 1he central controller manages the execution of a set of processes associated with
sensors and actuators.
vent-driven systems
n centralized control models, control decisions are usually determined by the values of some
system state variables. By contrast, event-driven control models are driven by externally
generated events.
1he distinction between an event and a simple input is that the timing of the event is outside
the control of the process which handless that event.
A sub-system may need to access state information to handle these events but this state
information does not usually determine the flow of control.
1here are two event-driven control models:
(1 Broadcast models: n these models, an event is, in principle, broadcast to all sub-systems.
Any sub-system, which is designed to handle that event, responds to it.
(2 nterrupt-driven models: 1hese are exclusively used in real-time systems where an
interrupt handler detects external interrupts. 1hey are then passed to some other component
for processing.
Broadcast models are effective in integrating sub-systems distributed across different
computers on a network. nterrupt-driven models are used in real-time systems with stringent
timing requirements.
1he advantage of this approach to control is that it allows very fast responses to events to be
implemented. ts disadvantages are that it is complex to program and difficult to validate.











l usinq exomp/es describe how doto f/ow dioqrom moy be used to document o system
desiqn whot ore the odvontoqes of usinq this type of desiqn mode/?
4ns
Data-flow design is concerned with designing a sequence of functional transformations that
convert system inputs into the required. 1he design is represented as data-flow diagrams.
1hese diagrams illustrate how data flows through a system and how the output is derived from
the input through a sequence of functional transformations.
Data-flow diagrams are a useful and intuitive way of describing a system. 1hey are normally
understandable without special training, especially if control information is excluded. 1hey
show end-to-end processing that is, the flow of processing from when data enters the system to
where it leaves the system can be traced.
Data-flow design is an integral part of a number of design methods and most CAS tools
support data-flow diagram creation. Different methods may use different icons to represent
data-flow diagram entities but their meanings are similar. 1he notation which use is based on
the following symbols:
Rounded rectangles represent functions, which transform inputs to outputs. 1he
transformation name indicates its function.
Rectangles represent data stores. Again, they should be given a descriptive name.
Circles represent user interactions with the system which provide input or receive output.
Arrows show the direction of data flow. 1heir name describes the data flowing along that
path.
1he keywords :and' and :or'. 1hese have their usual meanings as in Boolean expressions.
1hey are used to link data flows when more than one data flow may be input or output from a
transformation.






4 uescribe the c/ossic lnvo/id ossumptions with respect to 4ssessment of Process Life cyc/e
Mode/s
Ans. Classic nvalid Assumptions
Four unspoken assumptions that have played an important role in the history of software
development are considered next.
First Assumption: nternal or xternal Drivers
1he first unspoken assumption is that software problems are primarily driven by internal
software factors. Cranted this supposition, the focus of problem solving will necessarily be
narrowed to the software context, thereby reducing the role of people, money, knowledge, etc.
in terms of their potential to influence the solution of problems. xcluding the people factor
reduces the impact of disciplines such as management (people as managers marketing
(people as customers and psychology (people as perceivers. xcluding the money factor
reduces the impact of disciplines such as economics (software in terms of business value cost
and benefit financial management (software in terms of risk and return and portfolio
management (software in terms of options and alternatives. xcluding the knowledge factor
reduces the impact of engineering social studies politics language arts communication
sciences mathematics statistics and application area knowledge (accounting,
manufacturing, World Wide Web, government, etc.
t has even been argued that the entire discipline of software engineering emerged as a
reaction against this assumption and represented an attempt to view software development
from a broader perspective. xamples range from the emergence of requirements engineering
to the spiral model to human-computer interaction (HC. Aonetheless, these developments
still viewed non-software-focused factors such as ancillary or external drivers and failed to
place software development in a comprehensive, interdisciplinary context. Because software
development problems are highly interdisciplinary in nature, they can only be understood
using interdisciplinary analysis and capabilities. n fact, no purely technical software
problems or products exist because every software product is a result of multiple factors
related to people, money, knowledge, etc., rather than only to technology.
Second Assumption: Software or Business Processes
A second significant unspoken assumption has been that the software development process is
independent of the business processes in organizations. 1his assumption implied that it was
possible to develop a successful software product independently of the business environment
or the business goals of a firm. 1his led most organizations and business firms to separate
software development work, people, architecture, and planning from business processes. 1his
separation not only isolated the software-related activities, but also led to different goals,
backgrounds, configurations, etc. for software as opposed to business processes. As a
consequence, software processes tended to be driven by their internal purposes, which were
limited to product functionality and not to product effectiveness.
1his narrow approach had various negative side effects on software development. For
example, the software process was allowed to be virtually business free. Once the product was
finalized, it was tested and validated only for functionality, as opposed to being verified for
conformity to stakeholder goals. As a result, even if the product did not effectively solve the
underlying business problems or create a quantifiable business value for the organization, it
could still pass its test. Because software development was not synchronized with the business
process, software problems could be "solved" without actually solving business problems.
1hird Assumption: Processes or Projects
A third unspoken assumption was that the software project was separate from the software
process. 1hus, a software process was understood as reflecting an area of computer science
concern, but a software project was understood as a business school interest. f one were a
computer science specialist, one would view a quality software product as the outcome of a
development process that involved the use of good algorithms, data base deign, and code. f
one were an MS specialist, one would view a successful software system as the result of
effective software economics and software management.
Fourth Assumption: Process Centered or Architecture Centered
1here are currently two broad approaches in software engineering one is process centered
and the other is architecture centered. n process-centered software engineering, the quality of
the product is seen as emerging from the quality of the process. 1his approach reflects the
concerns and interests of industrial engineering, management, and standardized or systematic
quality assurance approaches such as the Capability Maturity Model and SO. 1he viewpoint
is that obtaining quality in a product requires adopting and implementing a correct problem-
solving approach. f a product contains an error, one should be able to attribute and trace it to
an error that occurred somewhere during the application of the process by carefully
examining each phase or step in the process.
However, an architecture-centered approach has several drawbacks. n the first place, one
only arrives at the design phase after a systematic process. 1he act or product of design is not
just a model or design architecture or pattern, but a solution to a problem that must be at least
reasonably well defined. For example, establishing a functional design can be done by
defining architectural structure charts, which in turn are based on previously determined data
flow diagrams, after which a transformational or transitional method can be used to convert
the data flow diagrams into structure charts. 1he data flow diagrams are outcomes of
requirements analysis process based on a preliminary inspection of project feasibility.
Similarly, designing object-oriented architectures in UML requires first building use-case
scenarios and static object models prior to moving to the design phase.





5 uescribe the concept of 5oftwore techno/oqy os o /imited business too/ 5oftwore 1echno/oqy os o
Limited 8usiness 1oo/
Software technology enables business to solve problems more efficiently than otherwise
however, as with any tool, it has its limitations. Solving business problems involves many
considerations that transcend hardware or software capabilities thus, software solutions can
only become effective when they are placed in the context of a more general problem-solving
strategy. Software solutions should be seen as essential tools in problem solving that are to be
combined with other interdisciplinary tools and capabilities. 1his kind of interoperation can be
achieved by integrating such tools with the software development process. Additionally, the
software development process can also be used as a part of a larger problem-solving process
that analyzes business problems and designs and generates working solutions with maximum
business value. Some examples of this are discussed in the following sections.
People have different needs that change over time
Software technology is limited in its ability to recognize the application or cognitive stylistic
differences of individuals or to adapt to the variety of individual needs and requirements.
1hese differences among individuals have multiple causes and include:
Use of different cognitive styles when approaching problem solving
Jariations in background, experience, levels and kinds of education, and, even more broadly,
diversity in culture, values, attitudes, ethical standards, and religions
Different goals, ambitions, and risk-management strategies
Assorted levels of involvement and responsibilities in the business organization's process
A software system is designed once to work with the entire business environment all the time.
However, organizational needs are not stable and can change for many reasons - even over
short periods of time - due to changes in personnel, task requirements, educational or training
level, or experience. Designing a software system that can adjust, customize, or personalize to
such a diversity of needs and variety of cognitive styles in different organizations and
dispersed locations is an immense challenge. t entails building a customizable software
system and also necessitates a continuous development process to adapt to ongoing changes in
the nature of the environment.
Most Users Do not Understand Computer Languages
A software solution can only be considered relevant and effective after one has understood the
actual user problems. 1he people who write the source code for computer applications use
technical languages to express the solution and, in some cases, they do not thoroughly
investigate whether their final product reflects what users asked for. 1he final product is
expected to convert or transform the user's language and expectations in a way that realizes
the system's requirements. Otherwise, the system will be a failure in terms of meeting its stated
goals appropriately and will fail its validation and verification criteria.
n a utopian environment, end-users could become sufficiently knowledgeable in software
development environments and languages so that they could write their software to ensure
systems were designed with their own real needs in mind. Of course, by the very nature of the
division of expertise, this could rarely happen and so the distance in functional intention
between user languages and their translation into programming languages is often
considerable. 1his creates a barrier between software solutions reaching their intended market
and users and customers finding reliable solutions.
n many ways, the ideal scenario, in which one approached system design and development
from a user point of view, was one of the driving rationales behind the original development of
the software engineering discipline. Software engineering was intended as a problem-solving
framework that could bridge the gap between user languages (requirements and computer
languages (the final product or source code. n software engineering, the user's linguistic
formulation of a problem is first understood and then specified naturally, grammatically,
diagrammatically, mathematically, or even automatically then, it is translated into a
preliminary software architecture that can be coded in a programming language. 1hus, the
underlying objective in software engineering is that the development solutions be truly
reflective of user or customer needs.












. Describe the round-trip problem solving approach.
Round-1rip Problem-Solving Approach
1he software engineering process represents a round-trip framework for problem solving in a
business context in several senses.
1he software engineering process is a problem-solving process entailing that software
engineering should incorporate or utilize the problem-solving literature regardless of its
interdisciplinary sources.
1he value of software engineering derives from its success in solving business and human
problems. 1his entails establishing strong relationships between the software process and the
business metrics used to evaluate business processes in general.
1he software engineering process is a round-trip approach. t has a bidirectional character,
which frequently requires adopting forward and reverse engineering strategies to restructure
and reengi-neer information systems. t uses feedback control loops to ensure that
specifications are accurately maintained across multiple process phases reflective quality
assurance is a critical metric for the process in general.
1he nonterminating, continuing character of the software development process is necessary
to respond to ongoing changes in customer requirements and environmental pressures.