wa pete ——

MU + Sem. 6 - Comp Tabla of Contents

Module 1

Introduction to Software Enea and Proceas Madoln 1-1 to 1-46

Chapter 1:
en

ee EO ee or La eA
Syllabua: Nature ‘ol Sottware, § sonhware “Engineering, Soltwaro Procoss, Capability Maturity Model (CHM). Genoric Process Model,
\\ Prescriptive Process Models : Tho Waterfall Model, Vemodol, Incremental Procoss Models, Evolutionary Process Models, Concurrent
| Models, Agito process, Agility Principles, Extremo Programming (XP),Scrum, Kanban modol.
{ 1 Sottwaro... Hs
v Syllabus Tople: Nature of Software.
‘ .2 Nature of Software.
1.24 Defining Software...
.2.1(A) Characteristics of Software...
1.2.2 Software Application Doman ...ssscsssesessnsescessssenen’ Ssscaciiaateacatscvesciataetarsnsenenn
nsusseasradsasseatsateasenocsoresseate 1-7
¥ Syllabus Tople : Software Enghnocring «sess nvbavas@eesansaseonanvnyensveapscossbsasssnpvensonssereberaveasstssoaeersas
AT
13 Softwaro Engineering (Dec. 15).
N\ 1.3.1 Layered Approach........
\ 1.3.2 _Activitios of Softwaro Enginooring...cssssscsssseesssen
1.3.3 Noed of Software Engineering ........sssssssss
v Syllabus Tople : Softwaro Process...
14 Software Process (Dec, 15).
1.44 Comparison with Conventional Engineering Process
v Syllabus Tople : Capability Maturity Model
15 Capability Maturity Model
N 1.5.1 Capability Maturity Model Integration
ho ov Syllabus Toplc : Generic Process Model
1.6 Generic Process Model i
¥ Syllabus Tople : Prescriptive Process MOdels . s cs s s srnerseseseansoes

17 Prescriptive Process Models .

v Syllabus Topic : Waterfall Model
17.1 Waterfall MOdeI.....ccscssssveersssssesessssrenseneentsnesnsnsnssvssvees
v Syllabus Topic : V-Model.....
— 1.7.2 VeModel ....sssessenees
Ite 1.7.2(A) Verification Phases
1.7.2(B) Validation Phases...
¥ Syllabus Tople : Incremental Process Models
1.8 Incremental Process Models (Dec. 16)
1.8.1 Difference between Waterfall Model and Incremental Model...ussnssemnnesennnnnrnnnnee
sssssunnnscsesssanssssscussosssscannnannsseqonenssses
oa Syllabus Tople : Evolutionary Process Models osaacssssssssesssssssssssscsssnsssssssscsssnssss
sscouveseauveeeReraiis
19 Evolutionary Process Models ........s.-++s+
1.9.1 Spiral Model (Dec. 17)...
1.9.2 Prototyping Model (Dec. 16)
aes Syllabus Tople : Concurrent Models
“4.40 Concurrent Models .n.annssnne
3 a Syllabus Tople: Agile Process seeceutssanennansancsuneste
18).........
0 1.41 Agile Process (May 15, Dec. 15, mane Dec. 16, May 17, May
} deve Syllabus Topic: Agility Principles
1.11.1 Agility Principles (May 15, Dec. 17)
1.11.2 Advantages ot Agile Process (May 16)
Agile Process Model...
1 Difference between Prescriptive Process Model and

Scanned by CamScanner
142

, 12, XP Values.
Syllabus Top
le; SOM
113 Scrum (Dec, vrs,
v 17)
Syllabus Top
le : Kanban Mo
1.14 del
Kanban Mode
!
1144
Lido
1.14.3
1.14.4
1.14.5
* Chapter Ends

Module 2
Chapter 2: Requirements
Analysis and Modelling
| : Use Cases (UML)
Syllabus : Requirement Elicitation, Software requirement specification (SRS), Developing ML).
Requirement Model : Scenario-based model, Class-based model, Behavioural model.
at Requirement Engineering (Dec. 16) ssssssssssssss
nscccecccsseessnsnesnesnesesteeee
2.1.1 Activities Involved in Requirements
Engineering
v Syllabus Topic : Requirement EVIcitAtiON.......ssssssevssssscssessovsss
ssoseccesscosseesescossssecc ennnsnnntsuseceausocsnsacganessessneeseeeseeess
2.2 Requirement Elicitation (Dec. 17) arerocsnasanerreee nee
e
oneeens oa tebesocaranssenstorse eceeereeese: seseseasersecavsecennaccosscoansconssnasap
23 Requirement Analysis sees avavenveenracssnoesens saeseenanees
tt em neta ete tee ese eeenounenaaenenastaeateneeseneotarsneusenerecnnecas besssenasie
2.4 Types of Requirements
2.4.1 Functional Requirements (Dec. 16)...
.
2.4.2 Non Functional Requirements (NFR) (DOC. 16) .....cssssesssssesssssssssnncsssesesnecsssecsnec
snensessnsnssansen ecsnesveeseascenenasanervseasancenseans -
2.4.2(A) Types of Non-Functional Requirements peneeensreas teen eeessnee tease nesenesssunnaeseerbesesenspessones
Se eewecercoececonseseneaseuosseenecsvacsuepeatersarenersey:

2.4.3 Domain Requirements...SO...

Pema n ere e Lt easnenasecesasenmeneeenensereeerenansestensseoagn sansa seness: Raeseeae scorer enevear enous eecenersnesseeremee ness Pay seen sanseenenes

Syllabus Topic : Software Requirement Specification (SRS)

25 Software Requirement Specification (SRS) (May 15)
2.5.1 Advantages of SRS SASS orev en naeeeeneneumeeneaaneneEsSLO DEL EEG OLIGDaaesaede reese eRe EEN DEAS EEDMLSSORH OD OESOOGEDDORSEMELDISUSSOESIOL
DEOL SEREDDREED SS SRESb EAS DO NEES
2.5.2
2.5.3
2.5.4
2.5.5 SRS for Hospital Management System (May 17, May 18)
v Syllabus Toptc : Developing Use Cases (UML)
2.6 Developing Use Cases (UML)

27
28

Scanned by CamScanner
 [EP software Engineering (MU - Sem, 6 - Comp) 3
2.9.3 Swimiane Diagrams......
iv Syllabus Topic: Class-based Model..
/ 2.10 Class-based Model... -
‘ 2.10.1 identitying Analysis Classes
C ‘
2.10.2 Specifying Attributes
2.10.3 Defining Operations.......
v Syllabus Toplc : Behavioural Model...
2.11 Behavioural Model..............0000

Chapter 3: Project Scheduling and Tracking 3-1 to 3-27

Syllabus : Management Spectrum, 3Ps (people, product and Process), Process and Project metrics.
Software Project Estimation : LOC, FP, Empirical Estimation Models : COCOMO II Model, Specialized Estimation Techniques.
Project scheduling : Defining a Task Set for the Software Project, Timeline charts, Tracking the Schedule, Eamed Vaiue Analysis.
34 Management Spectrum, 3Ps (People, Product and Process) 7 . soeesaessacenateraecenceseseetsonssenensen 3-1
v Syllabus Topic : Process and Project Metrics saseness 20-2
3.2 Process and Project Metrics.... “ a . oe oe FQ
3.2.1 Metrics in the Process and Project Domain ......sesssssssssseressenssessensancneseenrensensneerenerets in 3-2
3.2.1(A) Process Metrics and Software Process Improvemert....... a 3-3

3.2.1(B) Project Metrics........

Syllabus Topic : Software Project Estimation

Software Project Estimation ......-sssesescecssrsesesesnessersesarsersneseenenseasseneesneneennns

3.3.1 Metrics for Size Estimation (May 15, Dec. 16, May 17) :

Syllabus Topic : Line of Code (LOC).

3.3.2 Line of Code (LOC)
Syllabus Topic : Function Points (FP)
3.3.3 Function Points (FP) (May 17)
Syllabus Topic ; Empirical Estimation Models ...
Empirical Estimation Models ..,...vsssssssssssssnsessssrssseecesnsnssssnesssesssntennnannnnnnnrestnasnnensanenorgetasneneaanins
Syllabus Topic : COCOMO II Model ........-.s.s0
3.4.1 COCOMO II Model (May 15, Dec.16)
Syllabus Tople : Specialized Estimation Techniques
Specialized Estimation Techniques
3.5.1 Estimation for Agile Development...
3.5.2 Estimation for WebApp Projects ........
eee nnnnnns
sere eeetnnnnnna
......sseceeessessnsesseesttmmnnnrsensnenn
Syllabus Topic : Project SChEGUlNG

Project SCHECUIING ......ss.ssssesesssseeseceserenesennennnncnrers

ensesnerrrr
Syllabus Topic: Defining A Task Set for Software Project....---neeessenereeeseern
eecaesauseacsseceaveccessseseacceenvangnenneceneentegs
3.6.1 Defining A Task Set for Software Project
A Project
3.6.2 Reasons for creating a WBS in
ee anstanme ES nmn
ensestnm
Scheduling Techmique ..-sctucsses
3.7.1 Critical Path Method ...
» PERN sanasssavsevenssenveseensonmnesa
37.2 Program Evaluation and Reviewtla
SCHODUIC......s-sseeceeneescnsneneranneennennsnsnnensnnten!
Syllabus Topic : Tracking the

Scanned by CamScanner
 Soe ry IMU = SO6M
= Com sa Lk ounwaro Engineering
.p) ‘
ra 4.10.2(B) Applicat
Syllabus Topic ; TimeLino Charts... 4A0.2(C) User tr
3.8.1 TimeLine Charts occ 4.10.2(0) GUI Im
Syllabus Topic : Eamod Value Analysis 4.10.2(E) User tr
3.8.2 Enmod Valuo Anatysis © Chapter Ends ........
3.8.2(A) — Featuros of EVA cece
3.B.2(B) Noed for EVA... ceceeene —_
ChapterS: Softwar
a |

Ay, ||_ Slabus : Risk Ident

A-1 to ——s process, Software Quali
Chapter 4: Software Design
—— 6 Coupling. A rchitectural Design 5A Risk Manager
fo : Design Principles, Design Concepts, Effective Modular Design - Cohesion an ~ ‘, saan :
Componentevel design, User Interface Design. Cy siebecy

v Syllabus Topic: Design Principles... ie5

4.2
v Rick Cont

43 Syllabus

Risk Pre
°
44 Effective Modular Design. Syliabu
wun
4.4.1 Advantages of Modularization _
4.4.2 Functional independence

45 Cohesion (May 15, May 16, Dec. 16, May 17, Dec. 17, nee 18)... es
ee, 4 5a Syilal
ade

45.1 Different Types of Cohesion (Dec. 15) aa

45.2 Advantages of Cohesion -

4.5.3 Disadvantages of Cohesion.. Ae sy

v ee — A 5.
46 Coupling (May 15, May 16, Dec. 16, May 17, Dec. 17, May 18)............. Apedefousyussacenansssstbussscogssseers ; : ty :
46.1 Types of Coupling (Dec. 15) ..........cssersesesscsnssnsssnenensensnsseenens dinnesnecesvonaentan togeusnessncordnsonssuserennsassssbenieen dpseiacessnsoniee eeeid |
4.6.2 Advantages Of Coupling.........cccsesessenssesssssessesssesssceessersesensenenes ssaeuvoaesansi savennne engactaveorss Outs se suusnrenensssaevaneresteanersonsers
4.6.3 Disadvantages of Coupling............ saendvzqusr Stnssednesthrovtssesessfesssrobensechavstecetsiatutyeevesnenseszes}uee4s ssinnguegnensenosgnennece 4A
4.6.4 Advantages of High Cohesion and Low Coupling (Dec. 17)... nati sheneantéccincsiensee savaneateesasesonsvssipersnisssssnie 4A
47 Differences between Coupling and Cohesion ........cssssscsssesseesesseesee otsiscanndicnsesan er eSenovesant sooysons ise eonbeesbe
was Tenspevivtessoniee 4g
¥ Syllabus Topic : Architectural Design........
4.8 Architectural Design .......c.sscssssssecssecssessese
4.8.1 Functions of Architectural Design
4.8.2 Architectural Design Document.
4.8.3 Architectural Style (DOC. 15) ....acscssossunseusesssesesserecsossccs
v Syllabus Topic : Component - Level Design
49 Component - Level Design .......ccsssssesssee <i
v Syllabus Tople: User Interface DeSigh .scussunnemneteneneoec..
4.10 User Interface Design (Dec. 16, May 18) ...
4.10.1 Command Line intertace (CLI)
4.10.2 GrapUser
hiInter
caface
l (GUI)
4.10.21A) GUI Flamante

Scanned by CamScanner
Chapter5: Software Risk, Configuration Management & Quality Assurance 5-1 to 5-46

Syllabus : Risk Identification, Risk Assessment, Risk Projection, RMMM, Software Configuration management, SCM repositories, SCM
process, Software Quality Assurance Task and Plan, Metrics, Software Reliability, Formal Technical Review (FTA), Walkthrough.

5.1 Risk Management (May 15, Dec, 15, Dec. 16, May 18)....ecsssssccsessscsccsssssssessessesssssssenmisnsevesssasssssnssesssesseeseesesransessnunrannnsneatseneti 5-1
v Syllabus Toplc : Risk ASSCSSMEN...........ecssssssecssssecssescsscsssessesnssasesssnssesaveneonssnssessessnencaneetearenseacensensenscnessarcansacescaesesenseerensaraetsess 5-4
§.2 Risk Assessment... - ies seevnsseeeorer onlineegneqre signs ceva ssncnrq mona erecelOESnn 5-4
v Syllabus Tople : Risk Identification ......ssssssessesseresssssessesersecsssnessascasensnsaressassonscerenstennessetserssnessenees esseseninenereeceessnnentsnnenencnereceen 5-5
§.2.1 Risk Identification ..........cccsccsscsescssssssscscsssssnsssesssersssecssccssscssesssssseorsasceduensassesenarecsesesessnensnencnesssnsenenersseanesnsasseneneaneasenes 5-5

5.2.2 Risk Analysis .....sssessssssssssesseccsscesssscsssssvessssesssnssssnsesssscessrseensesersssensscrsacersuecesusessansconssssnsesonscseavecsacsanenancanscanecoanesenasseats 546

5.3 Risk Containment........... sesusavesveussuenvcsossusnvevssusavsavanveasenccsssusssenscsscsecascuesussnssosensoneasenvenscssonsavensaneueguesssenannanenscassnesssescessesnacecensensecs 5-7
Syllabus Tople : Risk Projection .........sssssssssesssosssesssssnerssenserecssnsosesasenscennessersecsseenecensssnenersnssassecansenuesansansarensansanenaseaterserensensstnass 5-7
5-7
5.4 Risk Projection .......sssssssssssssssssserssnssessesnesnssnscnssseassarsssenseneesstessocsasansnesenes agrosesesecssccansecscessssuvcssessoesesuecansessesnequecnoranceneenseenscansetaat
5-9
Syllabus Topic : RMMM........ssssssssssssssssssssessssssesssscesssseensonsesensnvenssssnossssnsunensnsssenssssscenunecsensessoasesisnnssascavecnnnsssiagegniecresssensnssenssectt
5.5, RMMM (May 15)......ccsssecsssessssrerssssssecsseneesscansaneesensnenes 7 ssseseavessaneossnsauceseesecsensenencaucatacssonensacsensacsananaenensaneseanes 5-9

5.5.1 The RMMM Plan........csccccccsssscsseccsscssossessesscsnesenssecssssccssssnsseseceasescaesansesanasnassnscsssenseusensnausaneuancusssaassassnsnssasasenensasesease 5-10

5-11
Syllabus Topic : Software Configuration Management.........sssssssssessssssssssssssesssesesscennnansesesesssesnannnesecacccsessenscenassecconaanaasansanentys
seanecnanconesens5-11
Software Configuration Management.......... : seceecsavccscssucusssensssusesevseacenecesceaescsacstssscseceecasscusesansansnstauseusespecsuaeseenauneeseens
5.6.1 Benefits of Software Configuration Management .........scssssssssssesssssnsersnecseensneaneessnssansaesnsensssanencnnataenaseasensessnennsasneses 5-11
5.6.2 SCM DISCIPINeS........sersesersesecsensereneevssnnvenentessenes aseusseavagensdesursdtecvescesniaenossecisbinsteoveelss sansebenssnnsnnsens B sasctssavesonserees
unsses
Syllabus Topic : SCM Repositories..........ssssssssscsssvsssssssesnnsessecssnnvssesssnnsnssesscenssssssnassneasernsnnansesenasavessescansengnasssen
5.6.3 SCM Repositories..........csessssssssesssessnsecssesssessnsengeeonnssssssanessnesenussavensuennesenvenannsaneseusasnensavsnnssensanssecenesenes

5.6.4 SOM PrOoCeSS...ccccscssessssvssecssessesscansssscsscsecsssassecssnseneacsassesecnensessensseessnsensanenuarssesesanenseesee

5.6.4(A) Configuration Identification .........sssssessscsesecnenereessnesnenrsesseaneanensensnesnereesessensnsonssreess
5.6.4(B) Change Control (Configuration Control) (Dec. 15, May 17, May 18)
5.6.4(C) Version Control (Dec. 15, May 17, May 18) sie ssassorosssousesenrsvocceenosesosescesscacorensssesensneasoasnaese5-21
5-21
5.6.4(D) Configuration AUdit .........sssssssssssernesssessssernesanessnsessessnescasansnesenersassnsecsnsenseenncavacsnssnessnsscanscguannenasscnsaqunczanasesesesse4ssses
5.6.4(E) Status Reporting................+- sesussassceseuseacegesessecvecceseaseseccesenescsossessecsesscssensessnssencassacsscuseenanenesesses 5-22
ened ot i eee st . sssitlcdenencaeliSnaibuchina dee
deottsiss OOS

Scanned by CamScanner
 a
a ~—vnvspgens =
ine
Hee
es —sasnn stT cae
RES
Softwaro Quality ASBUTRMOD occurrent
5.8
eesni
nrrenet
mmtaatt
rnsrttten n vssveseshovessssectsseesysnnasaesonssennent®5-27
5.81 Comrypenmnernts of SCA SYSor asseresre see nnnrsenemr 828
ually ASSUTEIIOD. ces veeseereereeerserenerees
5.82 Pre-project Software Q
ss
en eme se
rnn ne
mer er
see eeen we 529)
s.....nss.
¥ Sytlnbus Tople : Metric os
rsernessnne
5.8.3 NMieotrins (May TB) ccc sscscsssenssesnssnse a
eneernee
5.8.4 in-process Quality MEtMIOS .svvcecerece 531
5.8.8 Defect Density During Machine Testing «..- nieaeescatetnsenetareTucereentnn
t
eunveuseciaetnet 32
snrnseunenesevesectneenstenusens
5.86 Defect Arrival Pattem During Testi saessnvssess eacgs eecan esstn ansan sanen cste
ssarecersensseenenevensnenssnessestancas 5-42
Phase-Based Defect Removal Patten sesscssessnoreesssncesnsnorcecccensonrearesea
$.87
ore dihin taHidlo tr msiatedsiviitad 5-32
ereenureerenreree seneasanresesssesenedenees iptavusttterctesteweitert erik cd
5.8.8 Maintonance Quality Metrics........ssess 5-33
r
t [GOK saressssenssessonersesnarsssscnsneneesstee
5.8.9 Fix Backlog and Backlog Managemen
BBO Fix QUOT . enes
cr rereeeee

5.8.14 Defective Fix..

5.9 SQA ProcOSSeS wvesesserreeee

sasonucnnnennnrents
acsnnsn rse -
ce eee
5.10 Baonefits Of SQA. sserssesscssessuesssterssssnrcesseetsnecen tee A gnen
teste ett
senn seennnen
Task and PLAID. dossssssssssesseesnnesss
v Syllabus Topic : Software Quality Assurance
rnnannrnr
ee EEEsen
SEE snee
rerSES
tumnmensnnnntnmens
5.11 Sotware Quality Assurance Task and Plam.cesssss
5.11.1. Test Management Reviews and AUIt secesesseseeeees
5.11.2 Implementation of the Quality Assurance......
5.11.3 Review the Process... ‘
ee nsanen sssesanennsnnnannnnncnee
eee ssnena
nsannersessseesenreeressee
5.12 Quality Evaluation Standards .......ssscsssssessssssa
ne sietnsprsaenne
sereenssss
annnnsnansserssensrnn
5.12.1 Quality Evaluation Stamdards.......--sssessessseescesssssnnss
eee ee
eee snnee
enaneeennsnne naneee esnneS nnenen
5.13 Six SIGMA esecseneecessenssseenssennensnesnne
scanensereceanies
5.13.1 Characteristics of Six Signa ......-ss-sccscssssrsssssessenseensanenseensennnnanecn
erssnnennnansereccenesstin
5.13.2 Key Concepts of Six Sigal ......--sssssrssssssessessesnnnnanen
arers
5.13.3 Benefits of Six Sigrma.........ssscsscssssessenesssnrsssenenssessansaeno
5.13.4 —_ Elements of Six Sigma.........sssessssseeseesersess
5.13.5 Responsibilities/roles in a Six Sigma ,
ecessasecesnececeuacsenucsuavecssnecansecanenssunasnen egessanecaneeanconseensuanegeasgesseeeee
v Syllabus Topic : Software Reliability ............. cossussesssnuecessauetassss
5.14 Software Reliability
.
5.14.1
sssusansssscnusvonsonecennsesssesnuscensesnsanesarssss crasscenseess wee 43
v Syllabus Tople : Formal Technical Review (FTIR) .ssessssssssscssnssessnnsen
rseeseerassserssseres ve 5-43
5.15 Forme! Technical Review (FTR) (Dec. 15, May 16, May 17, May 18)........sssssssssssse
anesanssnavanssansnsssssssassase nnesnana navansss ecenncan asssssse gseeesen eess 5-43
5.15.1 Steps in FTR (May 18)......cssssssssssssssesecsscssonsssonusssnsssnssnssonssnnnens
ene
ecsesronsnsnsannanssnecnanccnsangganccnngsnnsansnanasenenaneaanseenseneeagesaeys tat 5-45
v Syllabus Topic: Walkthrough ....ssssssssssssnsnsssssssseessnvanseesceremannaranseers
ssscnscasete
snsstanseseenenesueunnnanssonsnensacecencnnacaneaaganancannnanganesannyanayasnes 5-45
5.16 Walkthrough (May 16)....csssssssessesssssuvsnsseseeerssvanssereenssessssesseeseen
ensssensoussansennssarsseseenseevensssensanesesssansossnens 5-45
5.17 Comparison between FTR and Woligurcsdh (MY 16) ou... a ecsecsecsessscsssssscessssssssenssonsnns
nssnscoesequtans¢aesensoecnseenveenseshyaneceoessies achouauarenee BEEN s inaiecancoansecssosveasones 5-46
e Chapter Ends .......... sncovenensseiasesausesoeesesshesntnattscntoaaccsnavceesoesasocu
Module 6

Scanned by CamScanner
 ‘e c

ae

‘a a

“teh BT Sofware Engineering (MU - Sem. 6 - Comp) ,

Sy O49 Adtvarniages of Software Teating tatta «4 Cortaran
Testing! roy
by ALL Types ot Softwa
, : , : 62
ae Testing
Ditterence between Maerua! and AttomationSdeascmncimenensceass
M8 eT T TUNG
of Software
Princysles me roca
ae % 6.14 § as serene
a
“8g, G15 of Sohware Testing (Dee, 16)..
Objectives -
— eS
B10 Software Testing Process... sascosihiet
~ %
65
Y Byfebus Topte : Strategic Approach to Software Testing won oe ntibre “1
Soft t “eee : sertercaees ee
82 Strategic Approach to
1
2 Sytiabus Tople : Verification and Validation
6.2.1 Verification and Validation 0... _
6
622 Difference between Verification
and Validation (May 15, Dee. 17)..... = : “9

‘63 Unit Testing (Dec. 15)

6.3.1 Stubs and Drivers in Unit Testing. oe
63.2 List of Errors Detected by Unit Testing. veees tiie 14
Integration Testing eu
wv Syllabus Topic :
eis
ad Integration Testing (Dec. 15, Dec. 16)...
6.4.1 Types of Integration Testing S15
v Syllabus Topic : Validation Testing 128

65 Validation Testing, 18
6.5.1 Validation-Test Criteria 618

Configuration Review E13

6.5.2

65.3 Alpha and Beta Testing........ 619

G21
6.5.3(A) Difference between Alpha and Beta Testing
6-21
v Syllabus Toplc : System Testing ........---ssesessensnensesnerersserees
sesvenenusesseassessasseseeete 621
6.6 System Testing (May 17) ......... :
to 6-24
¥' Syllabus Topic : Software Testing Fundamentals.........
seecneseesonosessavensonensnensonseeess 6-24
6.7 Software Testing Fundamentals ............s+sssse0
..esssssssssssesssssessessnssnserssssnsenesnenessseanenneeet so 25
6.7.1 Characteristics of a Good TeSt
v Syllabus Topic : White-Box Testing.............

6.8 Whito-BOx Testing .......ssssssssscsssscsscensecsnsessssesssecennenceseansnaneansensanessansesensece

6.8.1 Advantages of White Box Testing........
6.6.2 Disadvantages of White Box Testing
SES
fifieiesbag Y Syllabus Topic : Basis Path Testing ...svnsnenesnnnnnrnnstannninne
Dec. 17)
6.9 Basis Path Testing (Dec. 15,
Seesuasee
6.9.1 Flow Graph Notation

= 6.9.2 Basic Terminology associated with The Flow Graph...

18) ......sscssseers avaiadbbastoneneesit vans sonasasnsaucnsnuavssoesesanences
6.9.3 Cyclomatic Complexity (Dec. 47, May
6-1 to 6-45

6.9.4 Deriving Test Cases ........ sees

cmapie vents ctohapteerramcsncerorerereeneenern
ystem Testing. 6.9.5 Graph Matrices .......s0 vie

Testing.....
ting, Softwar; y Syllabus Tople : Control Structure peacouceranssesnnasensnees
rannmnnnnertese easinsese om
.....ssssesssnseesnoreesnereemannema
Control Structure Testing.
&1

Scanned by CamScanner
 . 6 - Comp)
ineering (MU - Sem
eer Software Eng rr
Cond itio n Testing.......-eseee
6.10.1
Data Flow Test ing.
6.10.2

Topic:
Sytlabus
eeeeeeee
ing (Dec. 1G) see
6.11 Black Box Test -..
k Bo Testing
x
6.11.1 Types of Blac ..
of Bla ck Box Testing
6.11.2 Advantages g.. .
tin e
and Black Box Testing Techniqu
Tes
s of Black Box (May 15, May 16)
e113 isadvan' an
Di e White Box Testing
Differe
6.11.4
te nance
: Software Main
Syllabus Tople
(May 17).-----
intenance 6-24 Nature of Software, Software En
6.12 Software Ma
nce .------ =
6.12.1 Cost of Maintena ue 6-39 Prescriptive Process Models
re ven
ab us Top ic : Types of Softwa ~
Models, Concurrent Models, Ac
Sy ll . 16) -
-..
e (May 16, Doc
es of So ft wa re Maintenanc 6-43
6.13 Typ e
nennv
s TT enmne
w ren
aanenseene
n e! mneon

twa_re Fre
le : Sof— -engineeing. ee ree
v labus Top
Sylee 7
sasiaer

6.14
erse Engineering.
Syllab us Topic : Rev naneeses
May 18).....-- ceceacensene
v
(May 15, May 16,
6.15 Reverse Engineering
nnannnnneate aaneeee:
Chapter Ends. sesrneennn
«
@ Definition
Computer software,
instructions that tell
built, that actually ;

- In computer
d
processeby
Nae

-— Computer s
7 as online di

- Computer
own,

— At the \
individu

- A mack
chang¢

- Fore
comp

- Ani
:
syst

Scanned by CamScanner
 | Introduction
C to Soft ‘ware
Engineering and Process Models
ts 2Emoaui+ e
“Bn | AS

Model,
ity Maturity Model (CMM). Generic Process
Naturo of Software, Software Engineering, Software Process, Capabil
Incremental Process Models, Ev olutionary Process
,Pre neon Process Models : The Waterfall Model, V-model,
' model.
ili Principles, Extreme Programming (XP), Scrum, Kanban
i process, Agility
lodels, . Conc urrent Models, Agile

1.1 Software
ie Marks) |

la. 1.1.1 What is software? (Ref. sec. 1.1)

@ Definition of data or computer|-

are, is a gener ic te rm that refers t ‘0 a collection
Computer software, or simply softw u vhich the system is
to work , in cont rast to the physical hardware from
instructions that tell the computer how
the work.
built, that actually performs is; all the information
computer software
software engineering,
- In computer science and . .
systems, programs and data
processed by computer executable data, suc
h
programs, libraries and related non-
computer
Computer software includes
n or digital media.
as online documentatio listically used on its
req uir e eac h oth er and neithe r can be rea
and software
Computer hardware
to an
own.
ch in e language instructions specific
sists of ma
executable code con
At the lowest level, Unit (CPU).
so r- ty pi ca ll y a Central Processing
individual proces sig nif yin g processor instru
ctions that
va lu es
oups of binary
ge consists of gr
~ A machine langua te.
eceding sta
sta te of the computer from its pr in the
chan ge the
or ed in a pa rt ic ul ar s torage location
ge the value st
ex am pl e, an i ns truction may chan
For to the user.
a t is not directly observable
computer - an eff ect th of the computer
in g to app e: ar on a display
may also (indirect ly) ¢2 uses someth
instruction
An e to the user.
e ch an ge wh ic h should be visibl it is 1 nstructed to
system - a stat provided, unless
ns i
es so r - ag out the instructio
The proc
n.
jum p"toa diff
erent instructio

Scanned by CamScanner
 __Introduction to Software Engineeri 085, vy oo a
1-2 and Proc
sotware Engineering (MU- Sem. 6 - Comp)
La
EP
languages th: at are easie® _
_ ‘The majority of software is written in high-level programming
than machine languages
pavor®
\ Infor
use because they are closer local
y

to
more efficient for programmers
Bi

busi
languages. a compiler or an inter?’
roter OF
Pana

into machi ne language using - Ag

High-level languages
are trans lated /
combination ofboth. offe
which has stronneg corre spondence Ov
assem bly langu age,lated into machi language V5!N8 -
may ter's
also be writt
machi ne en
langu a low-l
in age eveluctio
instr ns and is trans
- So ftware
to the compu’ - No
;
as
an assembler. a typical desktop computer,
interacts with appli cation .software on 3
a. in turn communicates in.
how user
how are 18yeF jnterfaces with the operating
the syste m, which ;
- Fig.
*: 11. 7 sion softw
shows
.
The application flow.
arrows indicate information
with the hardware. The
- §
t

1.241 1
\c
application
Fig. 1.1.1: User interaction with
re
Syllabus Topic : Nature of Softwa

1.2 Nature of Software

it]Marke) |
Q. 1.2.4 Explain changing nature of software. (Ref. sec. 1.2)
ct, it also becomes an interface for delivering
~ Now-a-days the software is not only remains a produ
a product.
ied by
As a product, software is able to deliver the computing potential which is basically embod
computer hardware or precisely we can say, by a network of computers which one can access

through local hardware.

~ Software is considered as an information transformer or producer irrespective of whether it

resides within a smart phone or functions inside a mainframe compute: r.

. Just like any transport vehicle, softw are can work as the basis for the control of the computer
on and ——
(operating systems), the transport of information (networks) and the Be generati nt
softwar e tools),
of other programs (such as various

Scanned by CamScanner
2c
SSs My,
|f
ag ie, *

Sto ay,
na, % 6 - Comp) 1-3 Introduction to Software Engineering and Process Models,
ta, i [EP sottware Engineering (MU - Som.
important as pect of software. To make any data more useful in a
4

Information delivery is the most

eness ofa
sform the data. It also helps in improving the competitiv
"TPE;
~ | local context, software cm n tran
information.
Q business by managing the business
and
information networks (e.g., the Internet),
- A gat eway is provided by software to worldwide
ation in several different forms.
“Pong,
‘aRe si, offer the way to gather inform
computer software.
ant changes are occurred in the role of
8 — Over the last half-century, signific
as complex because of various
omes more sophisticated as well
— Now-a-days the software bec s
"ompy, ty mance, tremendous up-gradation
rovements in hardware perfor
aspects such as spectacular imp nsive
QUnica . age capacity, and exte
enhancements in memory and stor
te in computing architectures, huge
options.
diversity of exotic input and output
they may
lts on success of systems, but
plexity leads to amazing resu
- Sophistication as well as com
p complex systems.
for those who want to develo
also lead to huge problems as a
software industry is considered
world, the big
— In the economies of the industrialized

dominant factor.
m works for it in
re was dev elo ped ind ivi dua lly. Now-a-days an entire tea
— Inan earlier era, softwa essary to deliver a
|
pon sib le for one part of the technology which is nec
which every person is res
.
complex application.
;
1.2.1 Defining Software
(2 Marks) |
, sec. 1.2.1)
Q.1.2.2 _ Define software. (Ref
in different ways :
Sy
Software can be defined

@ Definitions when executed provide

desired features, function,
ter pro gra ms) that
ctions (compu
J. Software is set of instru
____.}
— and performance. y manipulate information.
s that ena ble the programs to adequatel
Software is data str uct ure operation and use
tarks) 2,
har d copy and virt ual forms that describes the
information in both
. 3, Software is descriptive :
of the programs.
ver y) e some charac teristics of it which
d the sof twa re exa ctly we have to examin
_ Now to understan
.
aining human made things
make it different from rem there are
ed k tha n a phy sic al system element. Hence,
l rather
Software is considered as logica
com . -
: ‘ ferent than those of hardw are.
os icantly dif
oa. re whi ch are sig nif
characteristics of softwa
re
.
al
1.2.1(A) Characteristics of Softwa oR (5 Marstks)
Bi 114 ) oe
good sof twa re (Ref . sec. 12.
1.2.3 rate ay four atbutes of
i sec. 1.2. 1(A))
1.2.
: ware. (Ret
,
i .
0, 1.2.4 Describe the characteristios: of soft
yf

Scanned by CamScanner
 1-4 Introduction
ing (M
_ gem. 6 - COMP) to Software re &; En
gineer
ea Software En
Se
ics of so
ftware (EP sot
| characterist ——Sa

ered;
re is developed or engine3
" pe manufactured in the Classical sense
2. Softwar
e doesn't “wear out

re _
ilt softwa
3. Custom bu

4, Efficiency

5. Maintainability

, 6. Dependability

of software
Fig. 1.2. 1: Characteristics
is not manufactured in the classical sense
or engineered; it
> 1. Software is developed
software development and hardware
re are som e simi lari ties found jin
Even though the entally different.
bot h the acti viti es are con! sidered as fundam
manufacturin g, >
ufacturing
desi gn is ba se for hig h qua lity, but in the process of man
In both of the activities, good en t in case of software.
in hardware which may not pres
there may be quality problems
there is vast difference in
inent dependency on people but
In both of the activities there is prom
accomplished.
the relationship between people and work
are not
ruction of a “product”, but the perspectives
The main aim of both the activities is const
same.

indicates that it is difficult to manage

Software costs are concentrated in engineering which
software projects similar to manufacturing projects.

“> 2. Software doesn’t “wear out”

eres Elaborate tha software characteristic “Software does not wear out”.
(Ret. sec. 1.2.1(A)(2)) (5 Marks)
In case of hardware, the failure rates are high as compared to software early in its life. Such
failures are mainly concerned with design or manufacturing defects. It is possible to correct the
defects and drop the failure rate to a steady-state level for some time period

increase in the failure rate as there are

oe after some time period, there is again
ee es of dust, vibration, mishandling, tremendous high or low temperature, and
ro ™ r environmental maladies on components of hardware. In simple words, tl
Mp , the
hardware begins to wear out.

Software does not have any risks of ;

to wear out of
ch environmental maladies which lead
hardware.
In early life of software there may be hi
these can be corrected. ¥ be high failure rates because of undiscovered defects. However,

Scanned by CamScanner
 [BP enonsonwara Engineering
(MU - Sem. 5 6 - Comp) i 1 5 Introduction to Software
re EI n ginee
§ ring and Proce
Proc: ss
Models
Nowwe it i Ss clear that there is
i no possibi ility of software wear out but it do es deteri or ‘a te
In 1 it lif e chan
h is an
ge inte; gral part of software, Whenever any change is made, e, thi there : is
i possibilit: y
of introduction of errors which increase the failure
rate.
Before the so: ftware gets consistent state by corrections, ‘
any new chan Be ge { introduced which
again increases the failure rate.
Gradually, the lo west failure
i rate level starts to increase which indicatess that the software ee i
18
deteriorating due to change.

There is one im ote

Olmert i i hardware and software regarding wear aspect is that in case
in
’ mponent can be replaced by spare parts. This facility is not available in
software as there are no such spare parts.

All th e software failures

i point
i out that there isi an error in design or in the method by which the
respective design was transformed into machine executable code.

Van, Hence the tasks of software maintenance which handles requests for change has significantly
more complexity as compared to hardware maintenance.

ring > 3 Custom built software

Component reusability is an important aspect in software industry.

in software component in such a
It is responsibility of software engineer to design and implement a
different programs.
way that it should be reused easily in many
as well as the processing which is applied to
Lot Latest reusable components summarize both data
to develop new applications from ‘existing
the data, which helps the software engineer
components.
user
used in the development of modern interactive
Re
For example, reusable components are
as well as wide
of graphics windows, pull-down menus,
interfaces that enable the generation
s.
range of interaction mechanism
e

> 4. Efficiency LN

the most efficient manner and

it uses the available resources in
Software is said to be efficient if
manner.
produce desired result in timely

> 6. Maintainability
to fulfill those
cha nge s, pro gra mme rs need to modify the software
If customer requireme nts
requirements. ifying the
abil ity to mai nta in the software throu gh mod
vides the
Software engineering pro
dware.
ng whole product like har
software rather than changi

> 6. Dependability sted by = .

tha t pro vid es ser vices which can be tra
ability of the software to
Dependability is the req uirements, 50 that
it is helpful
cus tom er' s
to fulfill the
vides services
Dependability pro
st of cus tom ers on the system.
achiev e tru

Scanned by CamScanner
 ker Software Engineer
ing (MU - Sem. 6 - Comp
)
1.2.2 Software Application Domain > 4:
ad categories:
: to few bro
7
Virtually on all computer platforms, software can be grouped in
.

Software Categories

1, System Software

ftware
2. Application So

it
3. Engineering Software
0

4. Embedded Software

5, Product-line Software
6. Web Applications
Software {
7. Artificial Intelligence

Fig. 1.2.2 : Software Categories

> 1. System software

ams. Few of them such as
a ide service to other progr :
This is @ to provi utilities are us
set of programs used geme ed to process complex but determinate
compilers, editors, and file mana nt
information structures.
drivers, netw orking relate d
Some other system software such as components of OS, s everal wind .
software, and telecommunications processors are generally used to process heavily indete ale >
data.
In all the situations, the system software area is broadly depends upon the interaction with
computer hardware.

“> 2. Application software

These are the stand-alone programs which are specially developed for specific business needs.
The Application Software helps to process business or technical data in such a way that it should
be useful to manage business operations as well technical decision making.
With traditional processing applications, one can also use application software to keep control on
business functions in real time.

“> 3. Engineering/scientific software

- These types of saltware are characterized through the “number crunching” algorithms. There
are
aaaier se engineering software in various fields like astronomy, space
shuttle orbital dynamics,
automotive stress analysis, automated manufacturing, molecular biology etc.
~ However, there are drastic changes in modern applications within the engineering/scientific area
as they are shifting from traditional numerical algorithms.

Scanned by CamScanner
 [EP software Engineering (MU - Sem. 6 - Comp) 1-7 _Introduction to Software Engineering and Process Model iS

> 4, . Embedded software

whi :
ai a
Theseoaen
Ganie so ftware which are merged within electronic devices and are used © for th
e. nting and :
controlling the features as well as functions for the end us er as. well osas system
aes
itself,

= 5. Product-line software

— . are developed to provide

These software i i
a particular functionality for use by several customers
e focus o: duct-li
product-line software may be on a restricted marketplace like inventory control
applications
aoe hice bavedor eat
can ae on ee consumer ¢
markets such as word processing, spreadsheets,
pplications, multimedia, database management, and personal as well as business
financial products.

-> 6. Web applications

Th . Ts software category
applica tions are also called as “WebApps”. This is a network-centric
ese
which covers large number of applications.
provide
In shortest form, WebApps are same as of the group of linked hypertext files which
re
information through text and limited graphics.
Mat, | of sophisticated computing
Now-a-days the modern WebApps are evolving into environments
ons, as well as content to the end user.
which offer stand-alone features, computing functi
late f .
corporate databases and b usiness applications
It is also possible to integrate WebApps with
Nate
- 7. Artificial intelligence software
for the purpose of solving
l algorithms are generally used
vith In these applications non-numerica ard analysis.
led by computation o r straightforw
comp lex problems which cannot be hand
s, expert syste ms, artificial
in th is category such as robotics, game
There are various applications
patte rn matching like image
and voice.
neural networks, proving theorem,
ineering
. Syllabus Topic : Software Eng
Id

1.3. Software Engineering

15)
=} (Mu - Dec.
(5 Marks)
Engineering’. (Ref. sec. 1.3)
1.3.1 Explain the term ‘Software
. (Ref. sec. 1.3)
Engineering.
in g co mb in es tw o con! cepts, Software and
Software Engineer

a@ Software related to specific fun’ ctiona

lity. Se!
set of exe cut ed pr og ra ms
seen Software is
Ee As we have already
m.
le inst ructions
is called as 8 progra
of executab

—— Scanned by CamScanner
 7
‘
iS
7

Ed
m. 6 - Comp) 1-8 Intr i
‘oduction to Software Engineering and process moc
ering (mu - Se
ef Software Engine structures which allow proB™
axoB
progral m code; it also includes data

es
more than just a nee the
Software is producterswhich def? .
mation, and documentation related to software puild
to manipulate info wa re en gi ne de si gn a?
is so ft wa re . So ft
the user to use th
dance for
functionality and gui
the software product.

to develop products.
@ Engineering
edge and well defined principles
ion of knowl
is an applicat
Engineering
ering
Software Engine

ng scie ntif ic and tec hno log ica l kno wle dge , procedures, and rules ta
eee she methodtwaofreapplyiuct,
+

oo is
5 sof prod
Atay

es

intaining
ma
Definition? de© veloping, testing and
@
ap pr oa ch to de signinenig, g, it pr od uc t re fe rr ed as software
and ad mi ni sts’ratw
re
equirements with best qual y of
jen tif ie, a cu st om er
i technologicai l, scte!er to meet
Applying
in ord
the software product
engineering.

1.3.1 Layered Approach

( 5Marks)8) |
neering. (Ref. sec. 1.3.1)
Q.1.3.3 Describe 4 layers of software engi

ware Technology
Fig. 1.3.1 : Layered Approach of soft

This approach is divided into 4 layers :

1. Aquality focus

- Any engineering approach must rest on the quality.

- The most important aspect in software Engineering is Quality Focus.

2. Process
Foundation for SE is the Process Layer.
SE process$8 is the GLUE
: that holds all the technology layers together and enables the tir
development of computer software.
- It forms the base for management control of software project.

Scanned by CamScanner
 ay
< Softw. Engi
Softwa
: are & ng worn
rit a (MU = SsSen,
Se 6 = CS comp)
Pp ~9
1-9 Introduction to Softwar
t e Eng
Hglneoring33} and 1 Procosa
Procesg Mode! \) is

3 Methods
SE
SE me
methods a
provide the weyTechnical
: Questions" Software,
for building Soft

Method gs containi a broad array oft asks

th at include
i i
communication requirement
; analysis,
yeis, d design”
modeling, program construction testing and support

4. Tools

ws
SE tools prov ri ide automated or semi eS automated support for the "Process" and 4
the ethods",
"Met

Tools are integrated

integrate so that information
inf i created by one tool can bo used by another

1.3.2 Activitles of Software Engineering

(2 Marks) \
10. 1.3.4 __ Enlist Activitios of Software Engineering. (Ref. sec. 1.3.2)
Software Engineering includes many activities as follows :
nt activity in so {tware engineering.
Understanding the user requirements is the first most importa
decisions is
According to the requirements, the process of designing the syste m and taking

sful completion of development of product.

implemented, which further leads to succes
r is the next
n designs and decisions made earlie
Constructing the software product based upo
activity in software engincering.
product is essen! tial after
of software, testing the software
To verify the performance and quality
s.
it ig constructed by software engineer
is deployed to the customer.
nce for software product which
The next step is to provide maintena

ng
1.3.3 Need of Software Engineeri
; (2 Marks) |
neering. (Ref, sec. 1.3.3)
Q.1.3.5 Explain need of Software Engi
king
environme nt on which software is wor
tec hno log y cha nge s, the user requirements and
As the ples used
ran ked bas ed on the software engineering princi
anization is
also changes. So every org
by that organization. ic method to
of sof twa re, pr og ra mmer requires 3 specif
ging large size
Implementing and mana the software quality. Sof
tware
re can 't h arm
so tha t size of softwa
modularize the tasks x sof twa re systems with high qua
lity.
co mp le
ogy for impleme nting
engineering Pp rovides methodol product and
, it is dif fic ult to address de fects in the
ment
d method or manage
Without any sta ndar pr ovides this functional
ity.
wa re En gi ne er in g
correc t them as
early as possible. Soft of time to
on al it y re qu ir es more cost in terms
d new func ti
end ing the pr ev ious software to ad ve lo ping new software
to
Ext the pr oc es s of de
en by peo ple, as compare to can be
develop and eff ort s tak in wh ic h software system
a wa y
ity. Soft ing provides
ware engineer
prev ide that functional
needed in future.
able to scale as

Scanned by CamScanner
 DSS} En BAA

ware from
anaging the creation of soft
selected process typically involves
a. process 18is the .
A software engineering leas e of the fine
tion to the. re
customer initia
as
methods such

ement gathe
(i) Requir
anal ys is

(ii) Design __
tion
(ii ) Implementa

process
re engineering
Fig. 1.4.1: Softwa
software.
in order to develop
:
se qu en ti al fl ow
cle follows the points +
The software life cy cl e in detail in subsequent
of thi s lif e cy
every stage
We will see each and
ing and analysis
(i) Requirement gath er s te m users to gather the
business
custom er an d sy
communica te with stem? What should
In this phase stakeholders us er wi ll in tera ct with the sy
How
will use the sys tem?
requirements like who
output? etc.
be the system input and is prepared.
ir em en t Sp ec if ic at ion Document (SRS)
irements, Requ
— Depending on these requ
°
(ii) Design icat
req uir e me nt ga th er in g ph ase i.e. requirement specif
output of
This phase makes use of
document as an input.
tware design is prepared.
Based on requirement specifications sof
atio n whic h spec ifie s har dwa re and software requirem
Output of this phase is design spec ific

of system.
ication document.
Data Flow Diagram, flowcharts etc. are included by design specif
Design specification acts as an input for implementation phase. :

Scanned by CamScanner
 eer? Softwaro Engineering (MU - Sem. 6 - Comp) 1-11 ___ Introduction to Software Engineering and Process Hertel,

> (iii) Implementation phase

Implementation phase of development process decomposes the system

e \
work A into varia ms smaller

parts called modules.

ia started,
These modules are assigned to development team members and actual coding

This is longest phase of system development.

Output of this phase is actual code using specific programming language.

-> (iv) Testing

of user in order to
against requirements
- Testing phase involves testing of actual code of system
ensure that system will satisfy all needs of users.
testing, integration testing etc.
Various testing strategies used are unit testing, system
software code.
Output of testing phase is corrected and modified

=> (v) Deployment

ed at users’ site for their use.
In this phase the system is deploy
nt team for any changes
use s the sof twa re and give feedback to developme
- In this phase custom er

or modifications in system if any.

=> (vi) Maintenance is

ctive will come up. It
is dep loy ed act ual pro blems from users pe rspe
Once the software as
. This process is called
pme nt tea m to sol v e user’s problems time to time
responsibility of develo
maintenance of system. application as per user's
ona l fun cti ona lit y ma y need to add in the
iti
’ In this phase some add
requirement.
Process
entional Engineering
4.4.1. Comparison with Conv ‘|
Sof twa re e n g i nwit
e li
e venntiognal Engineering Process.
Coni
r
0.1.4.2 Comp ar e ( 5 Marks)

(Ref. sec. 1.4.1) ering.

as the pri nci ple s ofconventional engine
has some similar things re or data processin
g
Software engineering
is associated the design of softwa
to to
ftware engineering .
class of problems related
It is ass ume d tha t so
problem solvin!
g domain, including the
to its
products and belon: gs
software and data processing. me thods that are gene
rally used in
drawing similarity from the
This idea is expanded by
of scientifeiceresee
l ,*
arch
isis used i
in n th e fi eld
us scientifi ic method
th at , ju st as th e fa mo
oc es s of PTONGIR SST g
ItEiseobe
se rv ed in th e pr
er in g re si gn process are used
,gi ne
the steps of f en
engineering.

eee
Scanned by CamScanner
 Models
g and Process
keep Softw,
= are Engine_ to So ft
a ware Engineerin

@ | IE
ering (MU - Sem. 6 - Co Introduct ion &) S
mp) ie
— Followi
‘wing steps are mostly repetitive :
1. Problem formulation, ”

2. Problem analysis,
3. Search for alternatives,
4. Decision,
5. Specification,

6. Implementation oftwa re engin eering 45

well.
able to the fie ld of 8
ese steps are applic ems
It is advised that th re and syst
in te gr at ion of hardwa
idered as 4 result of cilitate the
Software engineering is‘ cons e dures which fa
elements - methods, tools and proc
engineering, including a set of 3 key
of software development.
manager to control the process ‘
or semith-
an ted aan
nica l “how to’s » for buil ding software; tools offer
The methods give the tech methods, the
meth ods; and proc edur es describe the series of applying
automated support for
ctives.
deliverables, the controls, and the obje
software engineering. demonstrates Some
to traditional engineering disciplines,
Compared
remarkable differences. other
to a concrete product. On
s from an abstract design
In conventional engineering, one move
hand, in software engineering,
one moves from design to coding.

Abstract Design |— More Abstract Code|

Software Engineering

Abstract Design |— | Concrete Produets |

| Manufacturing Engineering

engineering can be anything, from word processing to real-time

The problem domains of software
cs.
control and from games to roboti
ering discipline, it is therefore much larger in scope and thus
In contrast to another engine
.
provides bigger challenges.
mally emphasize mass production is loaded with
Traditional manufacturing engineering that nor
trated. Software engineering, in contrast,
production features. Thus, it is highly production concen
is inherently design concentrated.
facturing, whereas such a possibility is
~ Product standardization assists in cost reduction in manu
remote in software engineering.

~ The possibility of process standardization, however, is very high in the latter.

plication-
d number of domain and ap
~ Conventional engineering process makes the use of unlimite
ed. Soft ware engi neer ing, 0 contrast, makes °° of teat, Pub
specific ideas which are prov
global concepts such as loops, cenditions ete.

Scanned by CamScanner
 er Software Engineering
(MU - Sem. 6 - Comp)
1-13
Introduction t 0 Software
Engineerin ig and Process
Mod, els
Syllabus Topic :Capability
Maturity Model

1.5 Capability Maturity Model

la. 1.5.
5.1 Write note on Capability
i Maturity
i Model (CMM).
| (Ref. sec. 1 -5)
(10 Marks) \
The Capabilit;
pability Maturity
i Model (CMM) invented
i by Software: Engineering Institute (SE
growing sequence of levels of a software development organization
iene
The hiigher = level, the better the software development procedure so reaching every level i
cost consuming and time consuming procedure. —s
e Capability Maturity Model (CMM) is a mechanism used to create and refine software
creation procedure of organization.

The CMM is same as ISO 9001, one of the ISO 9000 sequences of standards determined by the
' International Organization for Standardization (ISO).

The ISO 9000 standards state an efficient quality system for manufacturing and service

industries; ISO 9001 applied particularly to software development and maintenance.

uses - ISO 9001 states a lowest
’ The major variation among the two systems present in their
the CMM use a framework for
acceptable quality level for software procedures, while
explicit than the ISO standard in defining use
uninterrupted procedure improvement and is more
of employed to that end.

Following are levels of CMM :

Fig, 1.5.1: CMM Levels °

1 :e
Lev tial
Inil
1. ally chaotic.
is st at ed as in co ns istent and occasion
ure .
This software proced es en t ar e di sc ar de d at the time of crisis
ices that pr
and standard pre , capacity, and he
roics.
Stated procedures ef fo rt s ta ke n by each person
depend s on
cc es s of th e as sociation mainly dg e or lessons learnt with
them.
Su th ei r kn ow le
othe + associat
ion taking
ve on to an
Th.e heroes mo

Scanned by CamScanner
 s MOGs
ering and Proces
EP5,
SS_LOftware Engineering (MU
- Sem. 6 - Comp) 4-14 _Introduc tiO ? to Sortware engine
project - ch
2. nsistent
. Level 2: Repeatabie fandamental and co 1L.

— imThis level of Software Development associa tion bas 2

ab onality:
ctionalit .
s ep the track of cost, chi edule, and
fun! . nilar applications. 2
anagement processe to ke ects with tio8) n
pe at the lat est su cc es ses 07 pro] «
on to re
The procedure is in regi .
s cial
t ature ofa level two as
a most importan fe
am management is a
standardized,
3. Level 3 : Defined
i g actii ons are
di locum: ented,
m
a and ere
en gi ne er in tion and
; each
The software procedure for managem' ent and the overall assoch ft w
pr ocedure for standard
into a standard software rsion of the
tailored ve
and incorporated
associ ation use an approved, . ftware produc
t.
ining the so
every projec t develo ped by
d ma in ta
procedure of association for creating, testing an‘

4, Level 4 : Managed ent through

for software developm
efforts required
hgh

can successfully control the

Management
and software
a

precise measurements. procedure

At this level, association set a quantitativ' ¢ quality aim for both software

maintenance. and 0 ther quantitative

of procedures is contro led through statistical
At this level, the performance
ctable.
mechanisms, and is quantitatively predi

5. Level § : Optimizing
improving procedure
=

characteristic of this level is concentra ting on repeatedly

- he important
gical corrections.
increasing and innovative technolo
performance with the help of both
e performance and
dures are done to increase the procedur
At this level, modifications to the p roce quantitative procedure-
same time main tain ing stati stica l probability to ge t the recognized
at the
improvement aims.

1.5.1 Capability Maturity Model Integration

la. 1.5.2 Write note on Capability Maturity Model Integration

(CMMI. (Rol, 8c. 4-5-1) (5 Marks)|
model's application in software development has sometimes been problematic.
- The CMM
ization could be
Applying multiple models that are not integrated within and across an organ
costly in training, appraisals, and improvement activities.

- he Capability Maturity Model Integration (CMMI) project was formed to sort out the problem of
using multiple models for software development processes, thus the CMMI model has superseded
the CMM model, though the CMM model continues to be a general theoretical process capability
model used in the public demain.

~ CMMI framework consists of a collection of computer programs based on knowledge, system

and process development and provider
engineering. software engineering, integrated product
sourcing.
*

Scanned by CamScanner
 tent,
Oj Sey =e on
AS Styrene FE rgerveserrieny (MM) « Sewn A Ocerrm
leirihitnn tp Sotwars tramaret Pon
ation t

CMM frermewerte thaw three grennpepe Math Prone tees

a. ~ oe
1 Chan Ae tie
. or Developement (MMI - DEV;
2. CMM1 fort Service (CMMI - BV)

8. CMMI fer Acquisition (CMMI - AC)

andarg j

a ~ These three groups forme model compen

1 each Pertiont,
designed for will
penente which sre nniqaely them :
d cong great: anit tinny eng emnates ae which _. Nr enug
core processes aaa pert nf
Qn,
seis
these “ ™ See amon, ae ee ¥:

extend CMM
~ Itis also possible to ‘ 7
I frame te it
ework by making addition of model component
|
j
ay
*hroug,
'

softwar,

titative

Fig. 1.5.2 : CMM Framework Groups

cedure
_—_ Syllabus Topic : Generic Process Model
;
e and
d 1.6 Generic Process Model
(10 Marea) \
[1.6.1 Write note on Generic Process Model. (Rel. se0. 1.6) be 2
software process which can also
we have already seen the important phases of a
— Insection 1.4
Life Cycle.
termed as Software Development model with some
s ] a generic process
going to discuss all these phases in detail for
_~ Now we are

ic. important aspects.

a System Engineering wonky

be i
the a larger system
modules of reco one can starts“
always makes ene
As software approximately izing not only
_ for all components of
the system,
world.
forming requirements 5 i tside
of & ‘
with the ov
is ‘
importantly, its interface and interaction aS
by the software but, more - a
with ae .
Jementsaa such
if necessary when software must interface
This ‘system view’ is
i
| _ ‘de of, and ahead of e control 0
computers outside °",
hardware, people, databases and
y |
f ¢ the following issues :.
followin!
designer. :
3 ‘ .
discovering some 0 the
;
ji contains
: og
f _ In essence Systems engineering the overall picture:
solution fit0 into
i
the software
teem essere

(i) Where does

—

Scanned by CamScanner
 EP scmeare Engineering (MI < Rem 6 - Comp) 16

i) What dors the syriem do? Ie if necessary to examine £° ;

performing analysis of data? em is online, realtime,
(iii) What environment will the system be placed in? That is £756 -
, embedded ete.
on)
: (iv) What user interface is required and how is it used? - Any

(v) How systems communicate with other computers? - An

(vi) Does the system provide the required performance? » What BO dget does the customer agr
it is. automating some Th
(vii) What time period has been planned and how serious ffs to the user in
have and is it realistic? What are the cost/benefits tradeo!ls
manual procedure? ood
slinse position to evaluate the
When answers of these questions are received, the developer 18 1? °
RISK involved in implementing the system.

(1) Requirements Gathering and Analysis

@ specificati o
ification and a design.
important step towards creating
i
Requirements Analysis is the first
the nature and
- Trying to design a solution to without totally understanding
a problem
requirements of the user will always fails down the solution.
e that are rejected by the customers
4 — It bas been shown that more than ninety percent of softwar
; i after delivery is because the software does not meet the customer needs, expecta tion or
; requirements so it is important to understand those requirements completely.
(3) De
: - Requirements analysis is an iterative process carried out together by an analyst and the customer
and represents an attempt, to discover the customer’s needs, even as at the same time assessing
i the viability of a software solution. a
«
- Analysis gives the designer the demonstration of the information which is processed by the
system and the nature of the processing. i.e., what does the system do with the information which
it processes?

Analysis enables the designer to identify the software’s function and performance. Also where the
customer is not sure about how the system will eventually behave; the analyst may discover the
concept of a prototype.

F (2) Analysis Summary

The aim of requirements analysis is to generate a “requirements specifi

cation document” or a
“target document” that illustrates
great extent de’ tail in an unambiguou a manner regarding exactly
s
whatha the product should do. Thisi requirem
i ents document will then form the
’ design phase. basis for the succeedi 8:

The requirements document

may consists of :
- AProject
yect plan contai..ning :
details of delivery times and
cost estimates.

Scanned by CamScanner
 _
oe
a
(y ‘| Software Enginoering (MU - Sem. 6 « Comp) 1:17 Introduction to Software Engineering and Procesa Moralsmy

A model of the software's functionality and behavior in the form of ‘data flow / UML diagrams’
t and, where suitable, any performance and data considerations, any input/output details ete.

~ The results of any prototyping so that the emergence of the software and how it should behave
can be exposed to the designer. This might contain a user's manual,

- Any formal Z or VDM specifications for the system requirements.

~ Any test data that may be used to find out whether the end product is build according to the
agreed specification or not,

The Fig. 1.6.1 illustrates the activities that are sum-up by the analysis.

Software Requirements
ae project Review analysis or
planning prototyping

Project plan
Prototype Requirements
specification

Fig. 1.6.1 : Activities in Analysis

(3) Design and Implementation (Coding) >

When the analysis of the system has been completed, design or development can start. This is an
attempt to convert a group of requirements and program/data models that are specified in the
“requirements document” into a well-organized, designed and engineering software solution.
Design can be best summarized with the help of following steps :

~ The data flow / UML (Unified Modeling Language) diagrams that signify the system model are
transformed into appropriate hierarchical, modular program and data structure/architecture.
- Every program module is transformed into a correct cohesive function subroutine or class that is
designed to do an individual task which is well-defined.
- Design further focus on the implementation of individual module/class. The user interfaces of
module and its communication with other modules/objects is also considered and evaluated for
good design.
- The algorithm of module can afterwards converted into a flowchart, which is a step-by-step
graphical representation of the actions which are held by the module demonstrated in terms of
sequence, selection and repetition.
~ The flowchart can then be converted into Pseudo code, which conveys the same information as a
flowchart, but presents it in a way that is more acceptable to translate into program code.

Scanned by CamScanner
 J Sottwenre Prginanting (Mi. Seen 9. Cop)
1.18 temnetantion te Gommara ENgresnd
2 —
Oe
‘ is
ets
pian mins
pis ready fo ir
~ Al the end, the Porude cade for every‘ meslule fa cerrwerted inte & anlerted pease
: «
and the number of modules entered are compiled and integrated into 4 ayntem 7 1.7
charts, nena
testing.
etrt scturet>
the architecture, data
~ The final result of design o nd coding contains
dapicted below-
m fet ree code lietings,
Peeudo code, algorithms and all progra

| oe
j

| im Program source

entation (Coding)
specification Fig. 1.6.2: Design and Implem
_—

(4) Software Testing ing can

=
been written, testing and debugg
re components/modules has VW
When the part of the softwa
be started.
involved in testing :
_ Following techniques are
useful for checking that the software meets
' (i) Verification and Validation : This technique is
its operation. ,
ing that the software is correct in
the agreed specification and verify
: g the insides of the
ck and whi te box tes tin g tec hniques : It is helpful for testin
(ii) Bla
the interfaces of the module.
modules for correct operation and testing
rly.
the modules all working together prope
| (iii) Integration Testing : Testing that
to test. the product.
(iv) Acceptance Testing : Allowing the customer
cause of failure in a part of software
Debugging can be defined as it is an art of recognizing the
and correcting
it.

(5) | Deployment
nt site. This process is
After completion of software development, we have to install it at clie
known as deployment.

(6) Software Maintenance

Software maintenance reapplies all of the previous life cycle steps to an existing program instead
of a new one in order to correct existing or insert new functionality.

Scanned by CamScanner
 iy a} Sottw are Enginnoring
Inmet (MU « team
& 6 = Comp) 1-19 Introduction to fothwara Enginaering and Pre in
: 04% Ve seheaby
Syllabus Toplo ; Prescriptive Process Modela

1.7 Prescriptive Process Models

lo. 1.7.1___Expiain Prescriptive Process Models (Met sec, 1.7)

(5 Marks)s \
= The following framework activities are performed irrespecti
ve of the process model selected by the
organization,
. -
1, Communication
2. Planning

3. Modelings
4. Construction
5. Deployment

- The name 'prescriptive' is given because the model prescribes a set of activities, actions, tacks,
quality assurance and change the mechanism for every project.

d debugging Syllabus Topic : Waterfall Model

&
1.7.1 Waterfall Model

Q. 1.7.2 Whatis waterfall model ? State the practical situations in which

it can be used.
Software (5 Marks)
Meey (Ref. sec. 1.7.1)
on.
1.7.3 __ Explain the waterfall model. (Ref. sec. 1.7.1) (5 Marks)

insides of 4, Waterfall model is the first approach used in software development process.
It is also called as classical life cycle model or linear sequential model.
— In waterfall model any phase of development process begins only if previous phase is completed.

~ Requirement
Analysis |
t of softwa

Implementation

Verificatiori/Testing |

Fig. 1.7.1 : Waterfall Model

Scanned by CamScanner
 ie
Es se
ee F euptmmenririn (WALI - Renee, . Cusnne

1. Flevepe sir present Anatyete

of eyatent are gather
shored or”
Tne thie pitonem ml) poysedereuen rhipeitermenta
eters etakedecbite TS Ae prreteermey cor Weer ” sn ia created

At the end of thie phase Requirement Spevifinntioy —

alted eoftevnre
2 Design eee 14 created S —

ifeation decumvert design ae om

= Raced
ee] CF en reyperirerment,
quirement, specifreatic oa— -

spuctare and pehavier- 42

architecture

~ Ibis blue print of system representing system? internal #true

ing hardvor,
3 implementation software architecture using
is constructed for 9
Im implementation phase actual coding
-

and software requirements of system.

~ Itis responsibility of developer.

to ensure,
ed against requirements of useT in order
*Wersieation “resting js verified a8
- Here coding or job done by developer
. * © ments 0 f user.
that software will satisfy all business oe loyed at user’s site for their use.
. . are is deploye
~ After the successful verification softw

5. Maintenance plems must be solved time to tim,

‘ : ftw. faces some problems, then those pro
——
= Co ee . task comes under maintenance of software.
by development team. This task © | eriicemsisiital
. ce also includes adding new functionalities in software as per user require

= Advantages of waterfall model

(i) Itis very simple to understand and easy to use.

Gi) Phases of waterfall model do not overlap with each other.
initially.
(iii) It is useful for small projects in which requirements are clear
(iv) Since development is linear it is easy to manage development process.

@ Disadvantages of waterfall model

Gi) It is not useful for large projects.

(ii) Not suitable for projects in which requirements are not clear initially.
(iti) System or product is available only at the end of development process.
(iv) It is very difficult to modify system requirements in the middle of development process.

® Practical situations in which Waterfall model can be used

- This model is used only y when th € requirements

i are very well known, clear and . fixed.
- Product definition is stable,

ai

Scanned by CamScanner
 “
™~
i j Somware f eeneeting (MU « Sem. - Corn) " 1-31 Pritenehuvetiowy fey Sestiware . EngineeringAe | orand Process. Models
a ’

Technology is understand

There are no ambiguous roquifements,

Ample resources with required expertise are available freely,

The project is shert,

een re PTE ete

Syllabus
o=
Topic : V-Model
Some IRIS ea

1.7.2 V-Model

1.7.4 Write note on V-Modtel with verification and validation phases.

(Ret, sec. 1.7.2) had.
In software development, the V-model represents a development process that may be considered
an extension of the waterfall model, and is an example of the more general V-model.

Instead of moving down in a linear way, the process steps are bent upwards after the coding
i

phase to form the typical V shape.

The V-Model demonstrates the relationships between each phase of the development life cycle
and its associated phase of testing.
right) and level of
The horizontal and vertical axes represent time or project completeness (left-to-
abstraction respectively.

Fig, 1.7.2 : V-Model

cation and validation.

This model is basically divided into two phases; verifi

Scanned by CamScanner
 eSs Mor,
frware Engineering And FIOC
,
EP sotware Engineering (MU - Sem. 6 - Comp
1.7.2(A) Verification Phases
Phases
Verification

sis
ent Analy
1 Requirem

\i i
2, System Design
re Design
g, Architectu

7. Module Design

ficati on phases
Fig. 1.7.3: Veri

p ‘0ce:
e ve:

h
, Hi .
requirements of the system are collected by an Lowever UE doy
the ideal syste m has to perform.
This phase is concerned with establishin: g what 5
be designe d or built.
not determine how the software will ocument j
and a docu ment called the user requirements
interviewed
Usually, the users are
generated.
interfay
document will typically describe the system's functional,
The user requirements by the user.
etc. requirements as expected
performance, data, security,
system to the users.
busi ness analy sts to comm unic . ate their understanding of the
It is used by
eline for th
y revi ew this docu ment as this docu ment would serve as the guid
The users carefull
e.
system designers in the system design phas
in this phase.
The user acceptance tests are designed
g requirements of both soft and hard methodologies
There are different methods fo r gatherin
analysis, observation, throw-away prototype
including; interviews, questionnaires, document
use case-and static and dynamic views with users.

System Design
e and understand the business of the
Systems design is the phase where system engineers analyz
proposed system by studying the user requirements document.
ted
They figure out possibilities and techniques by which the user requirements can be implemen
informed regarding the issue. : A resolutia
If any of the requirements are not feasible, the user is according
document is edited ly.
is found and the user requirement
The software specification document which serves as ‘ it
a bl
ueprint for the development phase!
generated.
em organizati
This document contains the general syst rganization, me
data structures ett.)
le windows, reports Go then
may also hold business scenarios, samp r understanding.

Scanned by CamScanner |
EF sottware Engineoring (MU - Sem. 6 -Comp) 1-23 _ Introduction to Softwara Enginooring and Process Models

- Other technical documentation like entity diagrams, data dictionary will also be produced in this
phase. The documents for system testing are prepared here.

> 3. Architecture Design

- This phase of the design of computer architecture and software architecture can also be referred
to as high-level design.

- The baseline in selecting the architecture is that it should realize all which typically consists of
the list of modules, brief functionality of each module, their interface relationships, dependencies,
database tables, architecture diagrams, technology details etc.

_- The integration testing design is carried out in the particular phase.

=~ 4. Module Design

- The module design phase can also be referred to as low-level design. The designed system is
divided into smaller units or modules and each of them is explained so that the programmer
should be able to start coding directly.

- The low level design document or program specifications will contain a detailed functional logic of
the module, in pseudo-code :

o Database tables, with all elements, including their types and sizes.

o All interface details with complete API (Application Programming Interface) references.

o All dependency issues. ,

o Error message listings.

o . Complete input and outputs for a module.

- The unit test design is developed in this stage.

1.7.2(B) Validation Phases

Validation Phases

1. Unit Testing

2. Integration Testing

3. System Testing

4. User Acceptance Testing

Fig. 1.7.4 : Validation phases

In the V-model, each stage of verification phase has a corresponding stage in the validation
phase.

Scanned by CamScanner
 I. = UTP) amma

Loe V-Model : er Softwaro Engineering (MU -

The following are the typical phases of validation 17 the
1. Unit Testing r
Disadvantages of V-n
:. i
module design P! hase,
In the V-Model, Unit Test Plans (UTPs) are developed during 1. This model is con
nit level. 2. The developmen
These UTPs are executed to eliminate bugs at code
level or
am module, Tegarding the sof
A unit is the smallest entity which can .
independently exist,ist, e.g.5 2 Prost
3. If there are che
the reg ‘
‘ correctly when isolated from
Unit testing verifies that the smallest entity can function requirement doc
the codes/units. ene

Se
2. Integration Testing
1.8
re Incre
ee menta l Pr
Pr
Integration Test Plans are developed during the Architectural Design = me nt al

These tests verify that units created and tested independently

can coexist and communi,
among themselves, 9.1.8.4 Discuss inc
Test results are shared with customer's team. (Ref. sec,
- The increment!
3. System Testing
- The series o!
System Tests Plans are developed during System Design Phase. functionality|
Unlike Unit and Integration Test Plans, System Test Plans are composed by client's businey
- After the firs’
team.
— Based on cus
System Test ensures that expectations from application developed are met. The
whole application - made accord
is tested for its functionality, interdependency and communication.
- This process
System Testing verifies that functional and non-functional The increme
requirements have been met.
Load and performance testing, stress testing,
regression testing, etc., are subsets of systen Following tasks are
testing.
1. Communi:
4, User acceptance Testing
2. Planning
User Acceptance Test (UAT) Plans are devel functions ¢
oped during the Requirements Analysis
phase.
Test Plans are composed by business users 3. Modellin:
, UAT is performed in a user
resembles the production environment, usin environment thal
g realistic data. UAT verifies 4, Construc
that delivered systen
a

meets user's requirement and system

is ready for use in réal time.
5. Deploym
Advantages of V-model
®& Characteristics
1. This model is simple and easy to use.
1. System i
2. The testing activities such as planning,
curred prior to coding.
codi 2. Partial s
wastage of time. Hence it has better chance of Success comp; Thisis avoi avoids
3. Proactive defect tracking - that means the diagnosis ared to waterfall model. 3. First ta
- of de: fects is do
ne at early stage, 4. The req
4. Avoids the downward flow of the defects,
.
It is considered as good for small projects in whi ch requireme
nts are easily understood

aT IE 2 VTE NRE Nee MEET ny

Scanned by CamScanner
@ Disadvantages of V-model

1. This model is considered as very rigid and least flexible.

2. The development of software is done in the implementation phase hence no early prototypes
regarding the software are produced.
8. If there are changes in midway, then there is need to update the test documents along with
requirement documents.

Syllabus Topic : Incremental Process Models

1.8 Incremental Process Models

=> (MU - Dec. 16)

Q.1,8.1 Discuss incremental model for software development with merits and demenits.
(Ref. sec. 1.8) re
- The incremental model applies the waterfall model incrementally.
- The series of releases is referred to as “increments”, with each increment providing more
functionality to the customers.

- After the first increment, a core product is delivered, which can already be used by the customer.
- Based on customer feedback, a plan is developed for the next increments, and modifications are
- made accordingly.

- This process continues with increments being delivered until the complete product is delivered.
The incremental philosophy is also used in the agile process model.

Following tasks are common to all the models:

1. Communication : Helps to understand the objective.

2. Planning : Required as many people (software teams) work on the same project but different
functions at same time.
3. Modelling : Involves business modelling, data modelling, and process modelling.
4. Construction : This involves the reuse of software components and automatic code.

5. Deployment : Integration of all the increments.

@ Characteristics of Incremental Model

System is broken down into many mini development projects.

Partial systems are built to produce the final system.
PSN

First tackled highest priority requirements.

The requirement of a portion is frozen once the incremented portion is developed.

Scanned by CamScanner
 -

ee poo
are Engineering and Process Mod,
Software Enainceri . 4-26 _IntroductiC’
=—=— nginesring (MU - Sem. 6 - Comp) er Software Engine

2 communication
Hi Pianning
ert #7
| Modelling(analysis, designs) oor
s @ Construction(code, test) pelivery of 3” increment
2] [il Deployment(delivery, feedback) °
S °
5 Increment #2 °

poe Delivery of 2" increment

=
z Increment #1
aaa
a Chr >

nos Delivery of 1* increment \ ' : ‘ . Se

— 1.9 TT
Evolu
Project calender time
- Nor
Fig. 1.8.1 : Incremental Model gro
ai
= Advantages of Incremental Model \
1, After each iteration, regression testing should be conducted. During this testing, faulty elements im
of the software can be quickly identified because few changes are made within any singk -D
iteration. is
2. It is generally easier to test and debug than other methods of software development becaus: - 7
relatively smaller changes are made during each iteration. This allows for more targeted and
rigorous testing of each element within the overall product.
3. Customer can respond to features and review the product for any needed or useful changes.
4. Initial product delivery is faster and costs less.

@ Disadvantages of Incremental Model

1. Resulting cost may exceed the cost of the organization.

2. As additional functionality is added to the product, problems may arise related to system
architecture which were not evident in earlier prototypes. _

1.8.1 Difference between Waterfall Model and Incremental Model F

c
@. 1.8.2 Differentiate between waterfall model and incremental model,
(Ref. sec. 1.8.1) na : e z ae
SERS, (5 Marks)

Parameter Waterfall Model |: Incremental Model =

Simplicity Simple Intermediate

Risk Inv olvement High
S S Easily manageable

Scanned by CamScanner
 ee

ing and Process Models

1-27 Introduction to Software Enginoer
- Sem. 6 - Comp)
[7 sotware Engineering (MU
Waterfall Model Incremental Model
Parameter
Easy
Flexibility to change | Difficult
| Only at beginning Intermediate
User involvement
Rigid Less Flexible
Flexibility

Least Promotes maintainability

Maintenance

Long Very Long

Duration

cess Models
Syllabus Topic : Evolutionary Pro

1.9 Evolutionary Process Models

ist of
the Evolu tiona ry Devel opme nt Mode l is base d on the principle, that “stages cons
Normally evolution being
are product, with the way of
growing increments of an operational softw
discovered by operational experience”.
nature of the market there are lot of
According to the business need and th e changing
over a time.
improvements required in the software product
product hence evolutionary develo ments model
Due to this lot ofimprovement is required in the
is iterative in nature.
They are:
There are two types of models in Evolutionary process.

1. Spiral model 2. Prototyping model

Evolutionary Process Models

1. Spiral Model

2. Prototyping Model

Fig. 1.9.1 : Evolutionary Process Models

1.9.1 Spiral Model

=> (MU - Dec. 17)

Q. 1.9.1 With aneat diagram explain the Spiral model of software development.
: (Ref. sec. 1.9.1) ' : (Dec. 17/10 Marks

- Spiral model is a combination of iterative model and waterfall model.

Spiral model has four phases of development each of these phases is called as spiral.

Scanned by CamScanner
 wary Uy = OUT. UO «LOM
1-28

1. Identification

ma
3,Evaluation and .Construet
3
Risk Analysis

Fig. 1.9.2 : Spiral Model

(i) Identification

~ This phase identifies all business ginning. It involves ¢|

requirements of system at Oe
unde rstanding of requirements by communication between and customer. *
stakehol ex
.
In the subsequent iterations all subsystem requirem ents and unit: require
irements are identified.

(ii) Design

In first iteration, design phase develops conceptu

al design of system based on initially gathere4
requirements .
In further spirals or iterations, it develops logic
al désign, physical design, architectural desig
and final design of system.
n

(iil) Construct

Initially construct phase develops a code

for conceptual design to get user feedback
.
In next subsequent spirals, detailed
working model of software is cons
tructed with increment
number and are delivered to customer
for feedb: ack,
(iv) Evaluation and risk analysis

overrun are identified

feasibility of system is also don and monitored, technical
e.
At end of each spiral cus
tomer evaluates software
feedback. for Potential risks in sy
stem and provides

Advantages of spiral model

(i) Itis more flexible to changing requirements,

(ii) Requirements are achieved
more accurately,

Scanned by CamScanner
(ey Software Engineering (MU - Som. 6 - Com; 1-29 Introduction to Software Engineering and Process Madals

(iii) User can see the system from 1" iteration to end of development.

(iv) Risk management is easier.

@ Disadvantages of spiral model

(i) It is difficult to manage development procesa.

(ii) Not useful for small projects development.
(iii) Spiral can run indefinitely.
(iv) It requires excessive documentation work as documentation is prepared for each iteration.

1.9.2 Prototyping Model

> (MU
- Doc. 16)

1Q. 1.9.2 Discuss prototyping model for software development with merits and demerits,
(Ref. sec. 1.9.2)
- Prototyping model refers to developing software application prototypes (early approximation /
version) which displays the behaviour of product under development but may not actually contain
the exact logic of the original application.
- Prototyping allows user to evaluate developers’ proposal and try it before actual implementation.
— Prototyping model is widely used popular software development model as it helps to understand
user requirements in early stage of development process.

f Requirement gathering
. and analysis

Quick design

User
evaluation

)
Fig. 1.9.3 : Prototyping Model

Phases of prototyping model are as follow :

(i) Requirement gathering and analysis

- Building of prototype begins with requirement gathering and analysis,

- In this phase various users of system are interviewed in order to know their system requirements
or expectations from system.
- Requirement specification report is generated as an output of this phase.

Scanned by CamScanner
 oF
software ENg ineering and Procoss ty,OMG,
a Softwara Engi
Ngineering (MU -. Som. 6 - Comp) Introducone
1-30
By i
, Software Engineering 19
Quick Design
totype design)
i of synten, ; 7 Advantages
~ After gathering and analysis of user requirements quick design (prototy! ™ jy tages of pr
ve ig and analysis of user re
Gi) It enables es
leveloped,
ly necessary characteristics of the development
= : rg : , + jt contains on
Quick design is not detailed design of system; i (i) Refining of y
system which gives basis idea of system to the end users. i
(iii) Communica’
Git) Build prototype
the first prototype ofsyste (iv) More involy
: . tem
- Based on feedback received from user about quick design of system, greater exte
is created. © Disadvantages.
— Prototype is working model of system under development.
Ancona
(iv) Use Evaluation
9.19.3 Vihar
tem for its evaluation.
- Once prototype is built, proposed system is presented to end user of sys (i) Refining of
- User determines strengths and weaknesses of prototype ie. what needs to be added or what is, expensive |
be removed. (ii) More invel
— All the comments and suggestions given by user in feedback are passed to developer. (iii) Refining of
(v) Refining protot (iv) Practically
; eae extends be
— Depending on comments and suggestions came from user, developers refine previous prototype to ‘rupeiselanesinsneeaieemneniacae
form new prototype of system. saeco
- Ne to} i in evaluatedjust like ious prototype.
ow peotutype
is again evaluated just like prévions p = 1.10 Concurrer
— The process of evaluation and refining prototype continues until all user requirements are met by rs
prototype. fa. 1.10.1 Wi
(vi) Engineer a product

- Once evaluation. and refining of prototype completes i.e, when user accepts final prototype of
system the final system is evaluated thoroughly and deployed at user’s site.
- Deployment of engineered product is further followed by regular maintenance of
system.
When to use Prototype model

- Prototype model should be used when the desired

system needs to have a lot of interaction with
the end users.

- Typically online system in which web interfaces have

a very high amount of interaction with end
Seemann

users, are best suited for Prototype model.

- It might take a while for a system to be built that allows ease of use and needs minimal traini
minimal training
for the end user.

Prototyping ensures that the end users constantly work with the
. system : and provide
i a feed! back
which is incorporated in the prototype to result in a useable system
They are excellent for designing good human computer interface systems

Scanned by CamScanner
[2 sottware Engineoring (MU - Sem. 6 - Comp) 1-01 — Introduction to Software Eng inoring and Process Models

@ Advantages of prototyping model

(i) It enables early evaluation of system by providing working mode] to end users at early stage of
development.
(ii) Refining of prototype results in better implementation of system requirements.

(iii) Communication between developer and user reduces ambiguity.

(iv) More involvement of user in development process results in meeting users requirement at
greater extent.

@ Disadvantages of prototyping model

=D (MU - Dec. 17)

Q. 1.9.3 Whatare the potential problems of Prototyping Model ? (Ref. sec. 1.9.2) PER IAELIC
(i) Refining of prototype continues until user is completely satisfied, thus it is time consuming and
expensive process.
(ii) More involvement of user in development process is not accepted by developer always.
(iii) Refining of prototype again and again may disturb the working of development team.
(iv) Practically prototyping model results in increasing the complexity of system as scope of system
extends beyond original plan.

"Syllabus Topic : Concurrent Models

1.10 Concurrent Models

Q. 1.10.1 Write note on Concurrent Models. (Ref. sec. 1.10) ; (10 Marks)

Modeling activity
ey
Under : Represents the state
development of a software engineering
activity or task

Under
revision

Baselined

Nase ; : J

Fig. 1.10.1 : Concurrent Models

Scanned by CamScanner
 on to S oftwa
re Engineering and Process Mor,
le Software Engineering (MU - Sem. Introducti
6 - Comp) ng.
is engineeri
current
The concurrent development model is: also know? as c on . we t
fiterative 45 1] as concurren elemey,. |
This model helps software team in the representation 9
various process models. fined for the spiral model igcary,
ich has been de 2 ‘ ty
4
Fo r example, considi er the modeling
i iv y which ha
activit prototyping, analysis, and desig,
uch 068
out by calling one or more software engineering actions § og a software engineering Actiy;
In Fig. 1.10.1 we: can observe schematic representation re
‘ rr modeling approach. " 7 Agil
gue so
in the scopepe of tt he modeling
oH ‘ vity with the help of concu
activity .
re noted : at any particular ting a
’ The state of activity modeling may be any out of the
states which
g activi ties, actions, or tasks sua, % function:
In the same way, it is possible to re present remainin
communication, construction etc. in an analogous manner. . sly but
All the activities regarding software engineering are executed simultaneously but exis,exj ; oo improve
ae

different states. _ icati - The te

: : A communication acti;
For example, consider in the early phase of a project, first iteration 7 an ng changes state acti Dereleg
-_ ~The va
(not displayed in the diagram) has been completed and exists in the aw
: . j i ‘a *

is inactive at the time of comple’

tion of initial communicatig,
The modeling activity whose state Tange¢
now changes its state to under development. Th
~ : : B id be necessarily done, th ~ ere
However, if the customer enforces that changes in requirements shoul , agility
state.
modeling activity shifts from the under development state into the awaiting changes
| Agile softwa
Concurrent modeling describes a sequence of events which will activate transitions in betwee
states for all the software engineering activities, actions, or tasks. ~ Basec
sever
For example, in the previous phase of design (an important action regarding software engineeriy
which occurs in the process of. modeling activity), an inconsistency in the requirements model is sf
uncovered.
°

Because of it the event analysis model correction, is generated that will activate the requirements
analysis action from the done state into the awaiting changes state. : 3
Concurrent modeling is proved to be compatible for all the types of software development ant S
offers an exact picture of the ongoing state of a project. - As)
Instead of encircling all the software engineering actions, and tasks to a series of events, # o
process network is defined by the concurrent modeling.
All the activities, actions, or tasks on the network execute concurrently with other activities : °
actions, or tasks. -

In the process network, events which are generated at one point activate transitions between tl? °
states.

> (MU (mu- May 15, Dec. 15, May 16, Dec. 16, May
17, May1
Q. 1.11.4 What is Agile Methodology ? (Ref. sec. 1.11)

Scanned by CamScanner
j

“ S

POCO, Mog
eR

clement, | EB sonware Engineering

(MU - Som. 8 - Comp)
of 1-33 _Introduction to Software
Q.1.11.2 Whatis agility in context Enginoering and Process
Models
el ig Carrie of software Engineering
Q.1.11.3 2 (Ref. sec. 1.11 )
What are Agile Processes
ind deg; ? (Rol. sec, 1.11)
Q.1.11.4 Write short note on Agile
ing Activ, Methodology, (Ref. sec.
Q. 1.11.5 1,11)
Write short ote on Agile
Process Models.(Ret,
sec. 4.1 1)
ula , Agile software dev ERO ONES
elopment describe,
T time, S an approach to
software development under
requirem ents and solutions evolve which
S such as through the collaborative effor
functional teams and t of self-organizing and crogs-
their customers (end users),
. — It advocates adaptive planning,
evolutionary developm
ent, early delivery, and
exist, in improvement, and it encourages rapi continual
d and flexible response to change.
~ The term Agile was Populari
Activity zed, in this context, by the
Development. Manifesto for Agile Software

icati : ~ The values and Principles adopted in this

‘On, manifest o were derived from and underpin a broad
range of software developme
nt frameworks, includin
g Scrum and Kanban.
ne, th - There is significant subjecti
> e ve evidence that adopting
aye agile practices and values
agility of software professional improves the
s, teams and organizations.
tween = AL
Agile software development
values
— Based on their combined experience of developing software
ering seventeen signatories to the mani
and helping others do that, the
festo proclaimed that they valu
e:
del is © Individuals and Interactions over
processes and tools,
ts o Working Software over comprehen
1en sive documentation.
o Customer Collaboration over cont
ract negotiation.
and o Responding to Change over followin
g a plan.
— As per the view of Scott Ambler (Ca
nadian software engineer, consulta
nt and author) :
3, aA ©. Tools and processes are important, but it is more importan
t to have competent people
working together effectively.
es, © Good documentation is useful in helping
people to understand how the software is
built and
how to use it, but the main point of develo
pment is to create software, not documentatio
n.
ne o A contract is important but is no substitute for
working closely with customers to discover
what they need.
ot
.
o A project plan is important, but it. must not An
a be too rigid to accommodate changes in:
technology or the enviro: nment, stakeholders' 1s as es, and people's'
prioriti understandin: g of the
problem and its solution.

Scanned by CamScanner
 ess Mods,
ware Engineering and Proc
et Software Engineering (MU - Sem. 6 - Comp) introduction 12So ——S
1-34 ay Software Engineering |
rinciples <= SESS ee

Syllabus Topic : Agility P 1.11.3 Difference be

1.4464 Agllity Principles > (MU-May 15, De .4.11,9 Differer

’ c. 17)
(Rof. si

Q. 1.11.6 Explain principles of Agile Methodology. (Ref. sec: 1. 11 A)

Q. 1.11.7 Describe and discuss charactorstios of Agile Process Model. PALETTE Basic aim Devel
(Ref. sec, 1.11.1) to the
principles :
The Manifesto for Agile Software Development is bi ased on twelve Functionality | It
ry of valuable 80
Customer satisfaction by early and continuous delive Tequi
® ww p

Welcome changing requirements, even in late development.

SPAR”

s rather than months).

Working software is delivered frequently (week Popularity It is

Close, daily cooperation between business peopl le and developers. Examples Wat
should be trusted.
Projects are built around motivated individuals, w!who
ication (co-location).
Face-to-face conversation is the best form of commun

Working software is the primary measure of progress.

a constant pace.
Sustainable development, able to maintain
and good design.
Continuous attention to technical excellence
1.12 Extreme |
10. Simplicity is essential.
from self-organizing teams.
11. Best architectures, requirements, and designs emerge
, and adjusts accordingly. fa. fizieee
12. Regularly, the team reflects on how to become more effective
‘= Extrem
1.11.2 Advantages of Agile Process softwar
> (MU- May
Q.1 ‘11.8 What are Advantages of Agile Processes ? (Ref. sec. 1.11.2)
There are number of advantages of Agile Process :
Stakeholder Engagement,
Transparency,
Early and Predictable Delivery,
Predictable Costs and Schedule,
Allows for Change,

Focuses on Business Value,

Focuses on Users,
Improves Quality .

Scanned by CamScanner
 LE sonware Engi
neering (MU - Sem. 6 - Com Pp)
1-35
1.11.3 Difference betwee troduction to Sof
tware Er gir eor
n Prescriptive Pr ing and Procasa Model:
ocess Model and ‘3
Agile Procesg Model

(Ret, sec, 1.11.3)

ae | Prescriptive Proces
s Model
Basic aim Agile Process Mod
Developed to bring el
order and structure
to the software deve | These models satis
lopment Process. fy customer through
continuous delivery, early and
:
Functionality | It
can —_ accommodate Pe
changing | Defines a
requirements distinct set of activitie
s, actions, tasks,
milestones, and ‘work
products that are req
uired
to engineer high-qual
ity software.
It is more Popular.
Comparatively less pop
ular.
Water fall model, Inc
remental models | Scr
um, eXtreme Progra
mming (XP), Feature
Driven Development (FD
D), Dynamic Systems
Development Method (DS
DM), Adaptive Software
Development (ASD).

Syllabus Topic : Extreme

Programming (XP)

1.12 Extreme Programming (XP)

. ; - _

> (MU - Dec. 15, May 17)

la.t121 Explain Extreme Programming (XP) with suita
ble diagram. (Ref. sec. 1,12)
'- Extreme Programming (XP) is a
|
software development methodology
which is intended to improve
software quality and responsivene
ss to changing customer requirem
y 16) ents.
Planning/Feedback Loops’

Release Plan
Months
Iteration Plan
Weeks'
Acceptance Test
Days

Stand Up Meeting
Ona Day

Pair Negotiation
Hours

Unit Test
Mi

Pair Programming

Code

Fig. 1.12.1 : Extreme Programming

Scanned by CamScanner
 Engineerin gq and Procoss Modo,
ction 10 software «+ short devel
S Oftware Engineering (MU - Sem. 6 - Comp) 1-36 Introd! ent “releases” in sho ve OPMeny
er Softy
: cates freq checkpoints at which ney
— As a type of agile software development, it ee and introduce > 2
cycles, which is intended to improve productiv . tens} /
. d -. naira or doing extensive Coq 7
customer requirements can be adopted.
mming in P
— Other elements of extreme programming include
a : of features until
i] they are actually neeq ‘
a in the custo, td _
Teview, unit testing of all code, avoiding programming . ec! ting change mer,
: Jarity, ©XP uent communica):
a flat management structure, code simplicity and het understood, and freq Mating
requirements as time passes and the problem is ne
with the customer and among programmers.
— The methodology takes its name from the ide a that the benefi
" cial elements of traditional softy, =
. * . “extreme” levels. i trem
SOR Peary yraceates Ste: (akan 0 <e inl practices taken to thé extreme, code Cay
- Asan example, code reviews are considered a benefici
. of pairi progra mming-
be reviewed continuously, i.e. the practice .

1.12.1 XP Values
. icati .
. unicati on, simp}; ~
- Extreme programming initially recognized four values 19 , on
mreond edition ‘of a
feedback, and courage. A new value, respect, Was added in the
™ E
Programming Explained. Those five values are described below.

XP values

1.Communication

2. Simplicity

3. Feedback

Fig. 1.12.2 : XP values

1. Communication

~ Building software systems requires communicating system requirements to the developers of hk

system. In formal software development methodologies, this task is accomplished throw
documentation. '
—- Extreme programming techniques can
: we be viewed as
disseminating institutional knowledge among members of a methods for rapidly building at!
pidly . building =

- The goal is to give all developers a shared view development team. i

of the sys
users of the system. tem which matches the view held by tt
- To this end, extreme programming favors simple designs
users and programmers, frequent verbal communication common .
metaphors, . d
collaboratiot
» and feedback. > 4

Scanned by CamScanner
ler Software Engineering (MU- Sem. 6 « Comp 1-37 Introduction to Software Enginaering and Protigg Modols

> 2 Simplicity

- Extreme programming encourages starting with the simplest solution. Extra functionality ca.
then be added later.

- The difference between this approach and more conventional system development methods is the
focus on designing and coding for the needs of today instead of those of tomorrow, next week, or
next month.
- This is sometimes summed up as the "You aren't gonna need it" (YAGNI) approach.
- Proponents of XP acknowledge the disadvantage that this can sometimes entail more effort
tomorrow to change the system; their claim is that this is more than compensated for by the
advantage of not investing in possible future requirements that might change before they become
relevant.
- Coding and designing for uncertain future requirements implies thé risk of spending resources on
something that might not be needed, while perhaps delaying crucial features.
- Related to the "communication" value, simplicity in design and coding should improve the quality
of communication. A simple design with very simple code could be easily understood by most
programmers in the team.
> 3. Feedback

- Within extreme programming, feedback relates to different dimensions of the system

development :
o Feedback from the system : By writing unit tests, or running periodic integration tests,
the programmers have direct feedback from the state of the system after implementing
changes. .

o Feedback from the customer : The functional tests (aka acceptance tests) are written by .
the customer and the testers. They will get concrete feedback about the current state of their
system. This review is planned once in every two or three weeks so the customer can easily
steer the development.

o Feedback from the team : When customers come up with new requirements in the
planning game the team directly gives an estimation of the time that it will take to
implement.
Feedback is closely related to communication and simplicity. Flaws in the system are easily
communicated by writing a unit test that proves a certain piece of code will break.

- The direct feedback from the system tells programmers to recode this part.
A customer is able to test the system periodically according to the functional requirements,
known as user stories.
extreme programming),
As per Kent Beck (American software engineer and the creator of
“Optimism is an occupational hazard of programming. Feedback is the treatment”.

=> 4, Courage

Several practices represent courage. One is the commandment to always design and code for

today and not for tomorrow.

Scanned by CamScanner
 Process Modes,
frware Engineering and
IF sotvare Engineering (MU - Som. 6 - Comp) 1-38 Introduction to So! f£ effort to imp]
1g Jotof effo mMpleme ef
- This is an effort to avoid getting delayed in design and pee. refactoring their code x, KE) Software Engineer
1 a

anything else. Courage enables developers to feel comfortable ©

necessary.
- This means reviewing the existing system and modif} ying it 60 that future changes can he
. Stakeholder
implemented more easily.
code away: courage to FemMOve source ga,
- Another examplple of courage isi knowing
i w hen to th
r ow te that 8 ource code.

} of that is obsolete, no matter how much effort was used to crea Product ¢
uck on a complex problem for ,,
. . a progr .
- Al So, courage means persistence: ammer might benasil
st if they are persistent.
entire day, then solve the problem quickly the next day, bu

> 5. Respect
j
self-respect.
respect for others as well as
- The respect value includes ting unit-tey,
ation, that make exis
Programmers should never commit changes that break compil:
fail, or that otherwise delay the work of their peers.

Members respect their own work by always striving for high quality and seeking for the bez
design for the solution at hand through refactoring. ‘
i|
from others in the team.
| fi — Adopting the four earlier values leads to respect gained
a high level of motivatin
Nobody on the team should feel unappreciated or ignored. This ensures The wi
the project.
and encourages loyalty toward the team and toward the goal of tailore
teamwork.
This value is dependent upon the other values, and is oriented toward

I Syllabus Topic : Scrum

=== ———— =

1.13 Scrum

> (Mu-Deec.i

Q. 1.13.1. Write short note on SCRUM. (Ref. sec. 1.13) SPR TART

~- Scrum is an agile framework for managing knowledge work, with an emphasis on softwa
development. It is designed for teams of three to nine members, who break their work: into actss
that can be completed within time boxed iterations, called "sprints", no longer than one ord
and most commonly two weeks, then track progress and re-plan in 15-minute stand-up meetis# Ser
called daily scrums. , for pro
proces:
Scrum principles are mostly based on the agile manifesto and help to guide activities regal
development inside a process which includes framework activities such as requi: irements
nts, anal — Bi

design, evolution , and del ive ry. cu

as
called
In all the framework activities, work tasks happen within a Process pattern called ot
; a sprint. = s

OW

Scanned by CamScanner
 a \
IP sottware Engineering (MU - Sem. 6 - Comp 1-39 Introduction to Software Engineering and Process Models

et
Stakeholder liaison
o
oy

Development team

Potentially
i= ~ Sprint , _ _teleasable
planning backlog i increment 3

Topic! : forecast PBI's a E25

Topic2 : Plan work (e.g. tasks) Gees Sprint

Product backlog oon, retrospective

Fig. 1.13.1 : Scrum Framework

and is defined and usually

- The work implemented in a sprint is tailored to the problem at hand
tailored in real time by the respective Scrum team.

Sprint backlog Sprint Working increment

Product backlog of the software
, |
Fig. 1.13.2 : The scrum pracess |

e process patterns which are proved effective

Scrum mostly focus on the use of a bunch of softwar
requirements, and business criticality. All such
_ for projects with restrictive timelines, changing
development actions :
process patterns defines several sets of
or features which offer business value for the
- Backlog <A prioritized list regarding project needs uct manager
backlog at any time. The respective prod
customer. It is possible to add items to the
assesses the ba cklog and chan
ges the priorities as per necessity.
log
Sprints - Includes work units ts whic
} h are necessary to gain a requirement defined in the back
- ).
prede fined time-box (usually thirty days
which should be incorporated in
.
?_=

Scanned by CamScanner
 Pr: ae
= When 1
d e aviroe
sinble
wedst gta ntly basis by \
onmedai
), ‘ massiv'
ey Ss oftware Engineering (MU - Sem. 6 - Com cted °
rms Tocom
jtems)
. ions (such as backlos work! yin 0 SPO a inp? cond¥ ™ ust be answered hy a _—
- Modificat int to WOF p pinutes) moe t?
re asked and pass a |
all owe d by the sp ”
members are 4 When:
gies ‘ons whic _
are short (usuallyt key quest
- Scrum meetin
— . the w4
importan
Scrum team. Three most ootif g? : on.
: - |
team members are
last tea™; - Lo
1. What did you do since the and evaluates 4,
an
ext te meating meeting ‘ factor;
teriné
9. What obstacles are you encoun ter, pandles
accomplish ny master,
What do you plan to ~The
warel
cover critical issues as early ,,
3,
, ® |
_ A team leader, who is known a8 -. that it: can up "just I
person.
responses from each -alization” and thNy
tea™ r
Scrum meeting to the wiedge gocl
Kanbi
The important use of 1.14.1
\

—_ ,
Jeatl\ °
tings is that they
ly mee An! - Agile
customer) 60 that the nev}
e these dai
One more benefit of sid e mate!
_
ucture. the e client
encourage a self-organizing team str : rement at nas evel .
tomer. by the cus _ This
Demos - implement the software inc as ed fanction: ality,
but i
throt
_ as We: .
fun cti ona lit y can be demonstrated tai n.
developed to 0 ated sime-boX.
le tha t the dem o may not able — Wh il

_ Tt is also possib SS

h _—ee
rro—
softs
such functions whic within the
estat
—
“ " aes
Mod 4
———<anban - Inp
F
und
CC
tic etal - Unl
2 nn
ae (10 Marks)
1.14) _ ca
el in detail. (Ref. sec. nee
Explain the Kanban Mod requires real
Q. 1.14.1
lem ent agi le sof twa re development. It
mework used to imp
_— Kanban is a popular fra . ; 1.14.2 Kar
n of cap aci ty and full tra nsparency ofwork| ,
time communicatio
members to see the state
are rep res ent ed vis ual ly on a kanban board, allowing team - Th
_ Work items
e.
of every piece of work at any tim the kanbas
op
am on g today's agile . software teams, but
usl y pro mini ent - w
- Kanban an isi enormo
n 50 years. i
methodology of work dates back more tha af
eri n
ineeri »
In the late 1940s Toyota began opt
i engine
imizing g its the same mode
_
the ir she lve s. ig processes based on
using to sto ck
that supermarkets were - R
ducts to meet consurner d :
— Supermarkets stock just enough pro imiz v
emand, a practice that opt
arket and the consumer.
the flow between the superm i
match consumption petite
Because inventory lev els
Ts , gains significa mY
_
i ency ina inventory management by decreasing the ame . supermarket
effici nun of excess stock it must hold at c
:
given time. Meanwhile, the supermarket e can still ensure th
i at the given
giv. product msumer ne

Scanned by CamScanner
GB) software Engineering (MU - Sem. 6 - Comp) 1-41 — Introduction to Softwara Engineering and Process Models

— When Toyota applied this same system to its factory floors, the goal was to better align their
massive inventory levels with the actual consumption of materials,
- To communicate capacity levels in real-time on the factory floor (and to suppliers), workers would
pass a card, or "kanban", between teams.
- When a bin of materials being used on the production line was emptied, a kanban was passed to
the warehouse describing what material was needed, the exact amount of this material, and go
on.
— The warehouse would have a new bin of this material waiting, which they would then send to the
factory floor, and in turn send their own kanban to the supplier.
- The supplier would also have a bin of this particular material waiting, which it would ship to the
warehouse. While the signaling technology of this process has evolved since the 1940s, this same
"just in time" (or JIT) manufacturing process is still at the heart of it.

1.14.1. Kanban for Software Teams

- Agile software development teams today are able to leverage these same JIT principles by
matching the amount of work in progress (WIP) to the team's capacity. é
- This gives teams more flexible planning options, faster output, clearer focus, and transparency
throughout the development cycle. , ;
- While the core principles of the framework are timeless and applicable to almost any industry,
software development teams have found particular success with the agile practice.
- In part, this is because software teams can begin practicing with little to no overhead once they
understand the basic principles.
— Unlike implementing kanban on a factory floor, which would involve changes to physical
processes and the addition of substantial materials, the only physical things a software teams
need are a board and cards, and even those can be virtual.

1.14.2 Kanban Boards

- The work of all kanban teams revolves around a kanban board, a tool used to visualize work and
optimize the flow of the work among the team.

- While physical boards are popular among some teams, virtual boards are a crucial feature in any
agile software development tool for their traceability, easier collaboration, and accessibility from
multiple locations.
- Regardless of whether a team's board is physical or digital, their function is to ensure the team's
work is visualized, their workflow is standardized, and all blockers and dependencies are
immediately identified and resolved.
- A basic kanban board has a three-step workflow: To Do, In Progress, and Done. However,
depending on a team's size, structure, and objectives, the workflow can be mapped to meet the
unique process of any particular team.

Scanned by CamScanner
 Bs. cttware Engineering ron to Software ENgiNeor ing
i and Process
Model.
SSILIMU- Som.6- Comp)
i ¢ 1-42 no
The kanban methodology relies upon
full transparency of work fo ndsourc
|-time
real-u l communicatj 10n ey Ss
i} eiPAcltY, therefore the kanban board should be seen aa the sine e of truth for the tean,
are Er=
a
: - Kan
| work.
i | Team Kanban Boag — Sizes

QUICK FILTERS: Grincas Partnes

* Kvanta
Only ny partners Recently updated
.
|
| ¥To do Releasy
4 In progress 3 Codo review vex?
i oa
hid
pists ‘
TIS.28 lw TIS-28 115-28
pe Research options @& 18-27 > Engage JetShuttie Mi
“i ix + Engage Jupiter Engage Saturn
"to travel
to Pluto Express for travel SpaceWays for
Resort a3 PTP travel
ijl @ 18-25 j
wit @ 118-27 Ss
{i 4 Add Deimos Tours + Engage Speedy
&s a travel partner SpaceCraft
jl |
:
ve
i
n @ 718-20 : @ Ts-26 a
Engage Saturn g >
* Lines for group tours
4 Reach out to : lL Pla
" Red Titan Hotel

- Ak
TIs24 z
* Sign Contract for y wor
“ SunSpot Tours _
The

Fig. 1.14.1: Kanban Board

- As
1.14.3 Kanban Cards dev
i
- In Japanese, kanban literally translates
to “visual signal." For kanban teams,
represented as a every work itemis > 2. Sh
separate card on the board.
| .
The main purpose of representing
work as a card on the kanban board -— Cyc
| to track the progress of work is to allow team membes
through its workflow in a highly of
. visual manner.
~ Kanban cards feature critical information hi
about that particular work item, 8
full visibility into who is responsible giving the entire team
for that item of work, a brief description
done, how long that piece of work ig estimated of the job being ~ By
to take, and so on.
- Cards on virtual kanban boards will often - Ov
also feature Screenshots and other technical
detail : pe
that are valuable to the assignee,
rey
- Allowing team members to see the
state of every work item at any given
point in time. as well -
all of the associated details, ensures increased focus, Sh
ful] traceability, and fast id Be tion
blockers and dependencies. : St identifica cy
th
1.14.4 Advantages of Kanban
D
- Kanban
oduy is one of the most popular software developmen : - In
. adopted
pment methodologies by agile teat . th

Scanned by CamScanner
 software Engineering (MU - Sem. 6 -Comp) 1-43 Introduction to Softwaro Engineering and Process Models _

- ‘Kanban offers several additional advantages to task planning and throughput for teams of all
sizes :

@ Advantages of Kanban
Advantages of Kanban

1. Planning flexibility

2. Shortened time cycles

3, Fewer bottle necks

4, Visual metrics

5. Continuous delivery

Fig. 1.14.2 : Advantages of Kanban

> 1. Planning flexibility

a
- Akanban team is only focused on the work that's actively in progress. Once the team completes
work item, they pluck the next work item off the top of the backlog.

owner is free to reprioritize work in the backlog without disrupting the team,
— The product
because any changes outside the current work items don't impact the team.
the
— As long as the product owner keeps the most important work items on top of the backlog,
development team is assured that they are delivering maximum value back to the business. So
there's no need for the fixed-length iterations that are found in scrum.

-> 2. Shortened time cycles

a unit
- Cycle time is a key metric for Kanban teams. Cycle time is the amount of time it takes for
moment it
of work to travel through the team’s workflow - from the moment work starts to the
ships. ,

work.
- By optimizing cycle time, the team can confidently forecast the delivery of future
a skill set, that
-— Overlapping skill sets lead to smaller cycle times. When only one person holds
person becomes a bottleneck in the workflow. So teams employ basic best practices like code

review and mentoring help to spread knowledge.

work, which further optimizes
Shared skills mean that team members can take on heterogeneous
team can swarm on it to get
cycle time. It also means that if there is a backup of work, the entire
only done by QA engineers.
the process flowing smoothly again. For instance, testing isn't
Developers pitchin, too
is moving smoothly
In a Kanban framework, it's the entire team's responsibility to ensure work
through the process.

Scanned by CamScanner
 aro Engineering and Process Modes,
=ET sgftware Engineerin
rica g (MU - Sem. 6 Comp) 1-44 _ Introduction to SO
> jon to Sots
3 Fewer bottlenecks RA Ort :

ht at any 6riven time, the more Contes, 7

Multitasking kills efficiency. The more - A cumulative
work items in file?
Switching, which hinders their path to completion. blockages b
That's why a key tenant of Kanban is to limit he amount 0 f work pro
in ces
progress
s due to(WIP), Work. ir, i statesea
such a
tt lac k of focu,
Progress limits highlight bottlenecks and backups 1 t he team's these states |«
People, or skill sets, merged upstr
tes: To Do, In Progress, (44, -
~ For example, a typical software team might have four workflow sta , a 1759
Review, and Done.
. That might seem like a 1, 1500 seTe
- They could choose to set a WIP limit of 2 for the code review state. de,le, rather th:an
‘ ° 4
limit, but there's good reason for it: developers often prefer to write new co Spend 1259
2
time reviewing someone else's work.
3 1000
- ‘
A low limit encourages the team to pay special attention ‘
to issues i the review
in iew sta’ state, and 1, s®

review others work before raising their own code reviews. This ultimately reduces the overay z =
: z
cycle time. 500
> 4. Visual metrics —

— One of the core values is a strong focus on continually improving team efficiency and effectiveness
with every iteration of work. °
_ vant
- Charts provide a visual mechanism for teams to ensure they're continuing to improve. When th:
team can see data, it's easier to spot bottlenecks in the process (and remove them).

- Twocommon reports Kanban teams use are control charts and cumulative flow diagrams.
; > 5. Continu
— Acontrol chart shows the cycle time for each issue as well as a rolling average for the team. ~ .
06 Aug to 14Sept ~ - Mayknow
increment
1w13h17m average 3d median <1m min time 13w 6d 23h max time 240 issue ° Assue F ‘
50 " ——|@ ‘Cluster of issue continuow
: 7 Average .
40 9 6 |? Rolling average - CDis the
40 = > (O O Standard deviation - Kanban:

= ° e time (ant
9 20 0 ®
3 ° ° © — The fast
o 10 @ |
3 the mar
£ > ot
3 0 OS custome
a Oo @ . e Q
2 ° © @o oO
iu ° og Po e © 1.14.5 Compar
Oo .
fo) @ ®@ o e e 0 @ e

@ ° Q.1.14.2 C
° ° 9 °
5 @ @ e ° ‘ Kanbat
. @
0 10 Aug 17 Aug 24 Aug Bt Aig Q ‘| should not
.

7 Sep 14 Sep
Issue transition data
Fig. 1.14.3 : Control Chart

Scanned by CamScanner
 - Accumulative flow
diagram shows the
number

merged upstream,
Number of Issuse

Jan1 Jan16 Feb1 Feb15 Mar1 Mar16 Apri Apri6 May1 May16 Juni Jun16 ul
Time ,
Fig. 1.14.4 : Cumulative Flow Diagram

> 5. Continuous Delivery

We. know that continuous

integration the practice of automatically building and testing code
incrementally throughout the day is essential for maintaining quality. Now it's time to meet
continuous delivery (CD).

CD is the practice of releasing work to customers frequently even daily or hourly.

Kanban and CD beautifully complement each other because both techniques focus on the just-in-
time (and one-at-a-time) delivery of value.

The faster a team can deliver innovation to market, the more competitive their product will be in
the marketplace. And Kanban teams focus on exactly that: optimizing the flow of work out to
customers.

1.14.5 Comparison of Scrum and Kanban

and Kanban Model. (Ref. sec. 1.14.5) (5 Marks)

la. 1.14.2 Differentiate between Scrum
approaches. They
common concepts but have very different
Kanban and scrum share some of the
another.
should not be confused with one

Scanned by CamScanner
 g and Process Mode),
to Software Engineetng SNe,
nrodu ae
er Software Engineering (MU - Sem. 6 - Comp)
a KANBAN |
Parameter SCRUM "
Continuous flow
Tempo Regular fixed length sprints \
(ie. 2 weeks) ° tinuous delivery oF at the team,|
Release At the end of each sprint if approved by the neue \
methodology product owner. .= os les. Some teams enli:
enlist the}
Roles Product owner, scrum master, development
hoon No existing * h \
help of an agile coach. =

| Key metrics Velocity Cycle time -

” | Requirement Elicitat
time. |

|
Change Teams should strive to not make changes to | Change can happen at any Requirement Mode

a
philosophy the sprint forecast during the sprint. Doing
50 compromises learning’s around
estimation.

Scanned by CamScanner
 Requirements Analysis
ry or at the team
8
and Modelling

ome teams enlist th

= e

Requirement Elicitation, Software requirement specification (SRS), Developing Use Cases (UML).
Requirement Model : Scenario-based model, Class-based model, Behavioural model.

—K-
ChapterE;
nds... 2.1 Requirement Engineering
QaQ . => (MU-Dec. 16)

@.2.1.1 What do you mean by requirement? (Ref.sec.2.1)

_ © Requirement
system performance is called as
The information which describes the user’s expectation about the
requirement.
requirement definition has to face
- The requirement mus + be clear and unambiguous. Some
problem of lack of clarity.

# Characteristics of requirements
ts. They are as follows :
There are various characteristic of requiremen

Characteristics of requirement

‘|
4. Requirements should be unambiguous

2. Requirements should be testable (verifiable)

3. Requirements should be clear

(concise, simple, precise)

4, Requirements should be understandable

5. Requirements should be feasible

(realistic, possible)
|
6, Requirements should be Consistent

ts
Fig. 2.1.1: Characteristics of requiremen

Scanned by CamScanner
 SLIMY - Som. 6 -
=
2-2
.
SSS
Requirements Analysig .
Requireme nq
nts should be unambigu
ous
Ambi
Suous meang the single word
Conta in ambigu
:
or statement has more than one meaning. }
it.y then it ig difficult to ful f Teg). Software Eng
fill the re : tly
quirements correc ‘Nip,
Therefore . SSeate Eng
the requiremen . 4

ts
should be unam fusing. ~ It’s ai
Requiremen biguous means
ts Should be te no n confusing
stable (verifia
The requir ble)
ements shou 7 At the
whether th ld be testable mean te
ey are ; s st er sh ou ld be ab le to easily test the Teg):
mplemented successfully i and v
or not. For easy test, the
and unambigu
ous, requirement Shou,My 2-1 A
Activitis
Requirements shou
ld be clear (concise,
simple, precise)
The requirements
should be clear. They The ,
If there is an: sho uld not contain any unnecessary information
Y unnecessary inform
ation then it becomes ‘ype
fulfillm €nt of
the requirement, difficult to achieve the
8D — Thes
Requirements
should be unders
tandab le

It should not happen that Processes

Produce different cutput
different sources. s for same inputs comi so
tf!
Requirement Engineering

them is called as requirement engineering.

i , > 2 F
at

The aim of requirement engineering is to “reate and maint

Specification’ document. ain ‘System Requi

Requirements engineering is the process of un:

ati

: equired and identifying the cons

traints on these
Services :
irement eng ineering Processes ensure
s

vaaing up with high quality software,

en

Scanned by CamScanner
F sottware Engineering (MU - Sem. 6 - Comp) 2-3 Requirements Analysis and Modotling

It’s a critical stage of the software process as errors at this stage will reflect later on in the next
stages, which definitely will cause you higher costs.
At the end of this stage, a requirement document that specifies the requirements will be produced
and validated with the stakeholders.

2.1.1 Activities Involved In Requirements Engineering

Q.2.1.2 What are major tasks of requirement engineering? (Ref, sec. 2.1.1 ) ‘ (5 Marks)

The activities/tasks involved in requirements engineering vary widely, depending on the

type of system being developed and the specific practices of the organization(s) involved.

These may include :

Activitles Involved In requirement engineering

1. Requirements inception

2. Requirements elicitation

3. Requirements analysis and negotiation

4. System modeling

5. Requirements specification

6. Requirements validation

7. Requirements management

Fig. 2.1.2 : Activities involved in requirements engineering

Requirements Inception

Inception is a task where the requirement engineering asks a set of questions to establish a
software process.

In this task, it understands the problem and evaluates with the proper solution.

It collaborates with the relationship between the customer and the developer.

The developer and customer decide the overall scope and the nature of the question.

Requirements Elicitation

In requirements enginedting, requirements elicitation is the practice of researching and

discovering the requirements of a system from users, customers, and other stakeholders. The
practice is also sometimes referred to as "requirement gathering".
We will see more details regarding requirement gathering in section 2.2.

Scanned by CamScanner
 ep
SS Settware Engineoring (MU - som, 6 - Comp) 2-4
Requiromonts Analysis and Modo),

> 3g Requirementg Analysis and Negotiation oer

bapsidve) San Se atnare Enginoorir
is rati conf;
~ Requirements are identified (including
new ones if the Se ee commonly used . .
with stakeholders are solved, Both written and graphical ~ JB require
tools scealitt used as aids, ‘
design phaso but some find them helpful at this stago, too) are suc discovering
Practico ia :
~ Examples of written analysis tools : use cases and user stories. - ‘The terme
~ Examples of graphical tools : UML and LML.
just be coll
> 4. System modelling
‘ ~ Requireme
- Some engineering fields (or specific situations) require the product to 7 pric letely Seen
desi
an fiSane the & u
modeled before its construction or fabrication starts and, therefore, the must
performed in advance. Sire
~ Requireme
- For instance, blueprints for a building must be elaborated before any contract can be appryy, workshops
and signed.
- Before rec
- Many fields might derive models of the system with the Lifecycle Modeling Language, wher, | elicitation
others might use UML,
Note:
usually fo
In many fields, such as software engineering, most modeling
activities are classified as design activ, © There are differen
and not as requirement engineering activities,
(1) Interviews
> 5. Requirements specification
~ Interview
— Requirements are documented in a formal artifact called Requirem
: : 3
ents Specification (RS). f intervi
oF intervi
- Nevertheless, it will become official only after validation. A RS : i °o Stru
can contain both written an ex
graphical (models) information if necessary,
‘
Ki
~ Example : Software Requirements Specification ° on:
(SRS).
deci
> 6. Requirements validation
° Oral
It is the process of checking whether the document
ed requirements and models are consistet!
and meet the needs of the stakeholder. Only Writ
if the final draft passes the validation process,
° RS becomes official. th °o Fae
o Gro
> 7% Requirements management
req
Managing all the activities related to the requirem
ents since inception, Supervising as the
is syste? 2) Surveys
developed and, even until after it is put into use
(e, 8., changes, extensions, etc.)
~ Organi:
_ at Tequire
Syllabus
y! Topic
p : Requi
equirement Elicitation
__ - The ag
2.2
." Requirement
=
Elicitation : becausi
- =
— Survey

> (mu - dec. - Freque

'{Q. 2.2.1_ Mention any four requirement Elicitation Methods. (Ref, sec. 2.2) _ es Survey

Scanned by CamScanner
[FP sottware Engineering (MU « Som. 6- Comp) 2-6 Roquiremonts Analysis and Modelling

- In requirements engineering, requirements elicitation is the practice of researching and

discovering tho requirements of a system from users, customers, and other stakeholders. The
practice is also sometimes referred to as "requirement gathering”.

The term elicitation is used in books and research to raise the fact that good requirements cannot
just be collected from the customer, as would be indicated by the name requirements gathering,

- Requirements elicitation is non-trivial because you can never be sure you get all requirements
from the user and customer by just asking them what the system should do OR NOT do (for
Safety and Reliability).

- Requirements elicitation practices include interviews, questionnaires, useT observation,

workshops, brainstorming, use cases, role playing and prototyping.

~- Before requirements can be analyzed, modeled, or specified they must be gathered through an
elicitation process. Requirements elicitation is a part of the requirements engineering process,
usually followed by analysis and specification of the requirements.

There are different ways to identify customer requirement :

(1) Interviews

— Interviews are important way for gathering requirements. Organization may take various kinds
of interviews such as : ;
o Structured or closed interviews in which information to be collected from customer is decided
in advance.

co Non-structured or open interviews in which details needs to be collected from customer are
decided in advance.
o Oral interviews.
o Written interviews.

o Face-to-face interviews which are held among two people across the table.

o Groups of persons are participating in group interviews. They support to cover any missing
requirement as number of people participates in this process.

(2) Surveys

- Organization may perform surveys of different stakeholders by questioning them about their
requirements and expectation from the proposed software system.
- The advantage of this technique is that, collecting requirements is economically beneficial

because it collects requirements from a large number of persons at same time.

- Surveys are less effective method of data discovery.
- Frequently, a survey's main finding is that other questions should have been asked instead.
Surveys are most useful for capturing clear factual information.

Scanned by CamScanner
 oN

that js}, oH
bu ilt set of objectives
ETN

4
Questionnaires ns ype
ATE

toh contal
.
nt Way whicl
Questionnaires are a docume stions whi ich are bat,
n

-
F s.
‘ option answer of those ques iS
:
questions and their
ah

give ar
to all stakeholders ”
a

This document is given

ONE

n in the question:
- a ation is not give Th,
’
and compiled. ome 9
S

angismunais,tteifn answer for ® |

Output of this ememach
e

bene,
~ n ded.
jrements economically jg
a

be r inin requ
issue may
as ene

lectin8 ,
is that, col s o n s 4 t game time.
ni e r
— ‘The advantage of this tech h u ge amou
nt 0 fp
ts
emen 7 f r o m
because it collects requir a t a discove
ry:
od o f d
effective meth
- Questionnaires are less
: ‘
ma y ide nti fy the fing,
(4) Task analysis and engineers
twar? developer®
_ In this technique, team of sof te m isé needed to develop.
ations then it- is analyzed by tha,
cattio i the new sys
i ns for which e
specififi
ica :
sof twa re to do the particular op
some
— Ifthe customer has
for proposed system.
to find out requirements

(5) Domain Analysis

some domain category: general and s.
~ Each software put into gr ea t support to study
ri en ce d pe rs on s in that domain can be a
_ The ex pe
requirements.

Brainstorming ggestion:
(6) ff er en t st ak eh olders and all their su
bate he Jd betw ee n di
Brainstorming is an informal deent analysis.
r requirem
documented for furthe

Prototyping t. including &

whi ch, we cre ate user interface . withou
Prototyping is a
technique in
— software product.
lit y for use r to int erpret features of desired
functiona
.
ails about requirements
It supports providing det p a prottl
own req uir e: men ts, in suc h case the developer develo
If the client does not kn ow its
ed at initial stage.
based on requirements provid
m client.
ype is dis pla yed to the clie nt and the feedback is collected fro
_- The protot
requirement gathering.
The client feedback is used as an input for

(8) Observation
of client
ts the organization or workplace
_— Teamof experienced persons visi
system’s work.
_ They observe existing
probl dealt. The
w execution
obs erv e the flo w of con trol at client’s end and ho ents expe i ee att
_ They form requirem y
clusions which aid to m the so:
itself draws some con

|
ai
Scanned by CamScanner
 (EP sonware Engineering (MU - Som. 6 -Comp) 2-7 Requirements Analysis and Modolling

2.3 Requirement Analysis

Q.2.3.1 Write note on Requirements analysis. (Ref, sec, 2.3) (5 Marks)

Requirements analysis is vital phase of requirement engineering process after Elicitation.

In this activity, we understand and refine the collected requirements to make them consistent
and non-confusing.
This activity reviews each and every requirement and may also give graphical view of the overall
system.

After the analysis, it is supposed that the understanding of requirments of project are increased
significantly.

In this activity, developer can communicate with customer to clear confusing points and to
understand which requirments are more vital than others.
— The significant factors in the requirement analysis activity are :
1. Identify and solve confusion among requirements at the same level and among different
levels.
2. Identify the boundaries of the proposed software system and the way in which it
communicate with environment.
3. Evaluate customer requirements for overall system requirements and then break down them
into individual component level.
The objective of the Requirement Analysis is generating a solution to implement the
requirements. ,
- Process of the Requirements Analysis includes following steps :
1. Analysis of the requirements
2. Description of the solution

3. Cost estimate and prioritization.

Here are some examples of how we can consider problems occurred in requirement analysis.
- Stakeholders don’t recognize what they really required.
- Stakeholders state the requirements in their own words.
- Various stakeholders may have different and confusing requireménts.
- Organizational and political factors may affect the software needs.
- The requirements are modified at the time of requirement analysis process.
- New stockholders may be included and the business environment may change.

2.4 Types of Requirements

Q.2.4.1 Explain the types of requirements. (Ref. sec. 2.4) (10 Marks)

Scanned by CamScanner
 Se SUUIUONING [MU + SOM, 0+ woreys 29,
a med, - are divided into throe i
— The requirements, which aro in general : “Ateg, \
and domain requirement, Ting
functional requirements, no: n-functional requirements,

2. Comp)

Fie 11 Stompta
nemeric data
:— ent
Piste i2 only
acenpts dates
f ™ th Re cur
before
Sereen 1 ea ‘i
“aN print on-serne
° on data to the
Business Requir
Fig. 2.4.1: Types of requirements ements

~ Data my
Must be enteredf
Teted before
a Pint,
rec,
2.4.1 Functional Requirements Clicking the Ap
prove te: ton terres the
> ow, 4 -
All person: nel using the
system will be
Q. 2.4.2 Functional ‘Ref. sec. 2.4.1 ReguiatoryComettancs Raquirements

regarding the Operations .

~ -The Functional requirements specification create document The database will
havea functional
»
out.
activities which a system must be able to carry
The system wil} limi
t access to suther
define a function regarg: ; The spreadsheet
— In software engineering, a functional requirement is used to o
can secure ¢ ata with

or its component, in which a function is described as a specification of behavior betwen, Security Requirements
and inputs. Members of the Data
Eatry group ea:
— In the functional requirements there may be elements such as calculations, technical dy. Members of the Managers
group can
manipulation and processing, and other specific functionality which define what m™ ~- Members cf the Administrators
grow
supposed to implement. 24.2 Non Functional Requirements
(NFT
- As defined in requirements engineering, functional requirements is used to mentions
results of a system. locas Expiain Non-Functoral Requrem

— This should be contrasted with non-functional requirements that mention overall chanz: — These are basically the quality con
like as cost and reliability. contract. ©
= Tenet vo ®
- Functional requirements drive the application architecture of a system, while nonfat
requirements drive the technical architecture of a system. a tbiny

- Fnonctional Requirements should include : 5 eae

o Descriptions of data to be entered into the system. o Maintainability

co Descriptions of operations performed by each screen. o Reliability

o Descriptions of work-flows performed by the system. o Scalability

o Descriptions of system reports or other outputs. ° ——

o Persons who can enter the data into the system. ° a
o Way the system meets applicable regulatory requirements. _ -_ are classified into follow

ia Examples of Functional Requirements o Interface constraints

© Performance constraints : 1
Functional requirements must contain functions performed by specific screens, outlines agt

performed by the system, and other business or compliance requirements the system ®

Scanned by CamScanner
(ae? Software Enginoering (MU - Sem. 6 - Comp) 2-9 Requiremonts Analysis and Modalling

7 Interface requirements

- Field 1 accepts numeric data entry.

> FYeld 2 only accepts dates before the current date.

Screen 1 can print on-screen data to the printer.

@ Business Requirements

— Data must be entered before a request can be approved.

Clicking the Approve button moves the request to the Approval Workflow.
- All personnel using the system will be trained.

eo Regulatory/Compliance Requirements

— The database will have a functional audit trail.

- The system will limit access to authorized users.
— The spreadsheet can secure data with electronic signatures.

@ Security Requirements

- Members of the Data Entry group can enter requests but cannot approve or delete requests.

- Members of the Managers group can enter or approve a request but cannot delete requests:

— Members of the Administrators group cannot enter or approve requests but can delete requests,

2.4.2 Non Functlonal Requirements (NFR)

=> (MU - Dec. 16)
@.2.4.3 _ Explain Non-Functional Requirements with types. (Ref.sec.2.4.2)
- These are basically the quality constraints that the system must satisfy according to the project
contract. ©
- The priority or extent to which these factors are implemented varies from one project to other.
They are also called non-behavioral requirements. They basically deal with issues like:
o Portability
o Security

o © Maintainability
° Reliability °
o Scalability
o Performance
o Reusability
o Flexibility
- NFRs are classified into following types :
o = Interface constraints
o Performance constraints : response time, security, storage space, etc.

Scanned by CamScanner
 7"
a
i.
yay

‘
+
Requirements Analysis ang M
Software Engineer we,
— gineering (MU - Sem. 6 - Comp) 2-10
© Operating constraints BT sot vara Engineering (MU
- Sern. 6 -
: te. ett:
© Life eycle constraints : maintainability, portability, The outeome of the req
° Economic constraints ¢ knowledge of the functiona} Requirements Specific
: ds th és Lh
The process of specifying non-functional requirements bans hich the system will operate, " SRS is also called as req
the system, and also the knowledge of the context within w0
SRS is base for software
project are gathered and
2.4.2(A) Types of Non-Functional Requirements
It is generally signed at

Following are 6 requirer

1. SRS document sho

| External 2. SRS document sho

Product pears ~ Requirements
iH, Requirements Requirements 3. It should be easily
t
Fig. 2.4.2 : Types of non-functional requirements 4. It should act as re!

- Product requirements : Requirements which mention that the delivered product should hay 5. SRS document rec

behavior in a specific way, e.g. execution speed, reliability ete. 7 6. It must include ac

- Organizational requirements : Requirements that are a result of organizational policies, 2.5.1 Advantages of SRS
well as procedures, such as process standards which has been used, implementation necessii,
etc. lo. 25.2 What ara advanta:
= External requirements : Requirements which are generated from the factors that are exten, (1) SRS contains the bas:
to the system and its development process, e.g. interoperability requirements, legislaty, as per expectations.
requirement. '
(2) ASRS gives a base fo

{ 2.4.3 Domain Requirements (3) Using high-quality S

- Domain requirements are used to describe system characteristics as well as features whid
(4) Ahigh-quality SRS ¢
impact the domain. Those may be new functional requirements, constraints on presi 2.5.2 Characteristics of SF
requirements or may define particular computations.
Q.2.5.3 Explain any five
- Ifdomain requirements are not satisfied, the system may be unworkable.
A good software req
- Example: Library system

Syllabus Topic :Software Requirement Specification (SRS)

2.5 Software Requirement Specification (SRS)

> (au
- May
[a.25.1 _ Whatis SRS document ? (Ret. sec. 2.5) a Ney, eds

- SRS is a special kind of docu

SRS stands for Software/System Requirement Specification. properties and constraints that ™
which contains user requirements for a system which states traint
be satisfied by a software system.

IEEE defines software requirements Specification as, 'a document that clearly and precis el
describes each of the essential requirements (functions,
performance, desi
ce, design cons traints ©
quality attributes) of the software and the external inte rfaces,

Scanned by CamScanner
[ay Software Engineering (MU - Sem. 6 - Comp) 2-14 Requirements Anatysis and Modalling
LPS =

- The outcome of tho requirements gathering and analysis phase of the SDLC is Software

Requirements Specification (SRS).

— SRS is also called as requirements document.
- SRS is base for software engincering actions and is generated when all requirements of software
project are gathered and analyzed.
- Itis generally signed at the end of requirements engineering phase.
- Following are 6 requirements stated by Heninger, which SRS document should follow :

1 SRS document should specify external system behaviour.

2 SRS document should specify implementation constraints.

3 It should be easily changeable if any changes occur.

4, It should act as reference tool for maintaining the system.
5. SRS document record forethought about the lifecycle of the system i.e. predicts changes.
6 It must include acceptable response to undesired events.

2.5.1 Advantages of SRS

Q.2.5.2 What are advantages

of SRS? (Ref. sec. 2.5.1) , cea : (4 Marks)

(1) SRS contains the base for agreement among the client and the company who develop the product
as per expectations.

(2) ASRS gives a base for verification of the completely developed product.
(3) Using high-quality SRS, we can develop high-quality software product.
(4) A high-quality SRS decreases the cost of development.

2.5.2 Characteristics of SRS

Q. 2.5.3 Explain any five characteristics of SRS. (Ref. sec.2.5.2) i ___(10 Marks)

A good software requirement specification must satisfy following characteristics.

Characteristics of SRS

1. Correct |
$eerged

2. Unambiguous

3. Complete |

4. Ranked for importance/stability |

5. Modifiable

6. Traceable

==>} 7. Verifiable

Fig. 2.5.1 : Characteristics of SRS

Scanned by CamScanner
 Requirements Analysis and ty
BF sotware Enginoering (MU - Som. 6 - Comp) 2:12
> ee
1. Correct
SRS is correct when all requirements of user jbed in the re quirement document, wer SoftwareEngineering |
are described in
Th 3
The listed requirements must be matched : . . a @ requirem
with desired system
ar
This depict that every requirement is analyzed to give assurance it (SRS . “ Remember r thtt
requirements. that it (SR ) containg
. 2.5.3 Format of SR
tness of SRS,
Remember that there is no specific tool or process to ensure the correctn forse
PERLE ewan
ORR
Correctness gives assurance that all stated requir;
ements are worked as exp ected.
Structure o
Unambiguous

SRS does not contain any confusion when each specified requirement has single interpretation,
This characteristic state that every requirement is individually interpreted.
In situation, where one term has number of meanings, then its meaning must be specified in
th,
SRS so that it will be non-confusing and simple to understand.
Complete
SRS is complete when the requirements undoubtedly specified that
which work the softy,
product is required to perform.

This contains each and every requirement associated to performa

nce, design and functionality,
Ranked for importance/stability

Each and every requirement has not same impor

tance, so every requirement is recognized ty
make differentiation between requirements.

For this purpose, it is needed to undoubtedly recog

nize every requirement.
Stability refers to the probability of further modif
ications in the requirement.
Modifiable
The requirements given by user are changeable, so
requirement document must be generated in
such a way that those modifications can be includ
ed easily in SRS by preserving consistently the
structure and style of the SRS.

Traceable

SRS is observable when the source of every requirement is unamb:

iguous and facilitates the
description of every requirement in future.

Forward tracing and backward tracing methods are used for this purpose.
Forward tracing state that every requirement must be referencing to design and code of
components.

Backward tracing state every requirement explicitly addressing its source.

7. Verifiable
SRS is testable when the stated requirements can be tested with a cost-effective Procedure
to |
ements.
rify whe the r the fina l software fulfills those requir
ve

Scanned by CamScanner
er Software Engineering (MU - Sem. 6 - Comp) 2-13 Requirements Analysis and Madaliing

- The requirements are tested through reviews.

— Remember that clear requirement is needed for verifiability.

2.5.3 Format of SRS

@.2.5.4 Explain general format of Software Requirement Spocitication (SAS). (Ref. soc. 2.5.5) (10 Marka)
Structure of SRS document includes following sections with various subsections in it :

Format of SRS

1. Introduction

LT (i) Purpose |
| (ii) Scope |
|_| (ii) Definition, Acronyms, and
Abbreviations

(iv) References

(v) Overview

2. The overall Description

+ (i) Product perspective : |

(ii) Product function

(iii) User characteristics

'—4 (iv) Constraint |

(v) Assumption and dependencies]

(vi) Apportioning of requirements }

a>) 3. Specific Requirements

— (i) Interfaces

(ii) Database

| (iii) Performance

| (iv) Software system attributes

ep| 4. Change Management Process

5. Document Approvals
4

i>} 6. Supporting Information

Fig. 2.5.2 : Format of SRS

Scanned by CamScanner
 Pete YY * OOM, 6 - Comp
)

1, Introduction
, This part is further divided intg fa
Introduction contains brief information about the SRS. This Pp "i, 1
Subsections :

GW Purpose
. ont, with its intended audience4,
This section specifies the main purpose of SRS document W oT hy,
SRS is constructed.

(ii) Scope
‘ SRS isig built.
i section specifies scope of the system for which bu
- _ This
- Scope pe defi of software product but a
defines not only benefits, » objeobj ctives and behaviour oftware.
limitations of software so as to understand the boundary of s

(iii) Definition, Acronyms, and Abbreviations

ion, abbreviatio, ws
To avoid ambiguity of terms specified in requirements, SRS provides definit
acronyms about these terms.

(iv) References

It contains list of all documents which are referred by this document.

r

* (v) Overview

It gives’overview of the document including its goals and objectives of the system.
2. The overall Description

It provides overall information about the requirements. Customers/users of the system are concen:
about this section. It contains following subsections :
(i) Product perspective

This section contains the information which states the benefits of current product over tt:
existing products.

(ii) Product function

— The functionality of software product summarizes in this section of SRS document.
— It is possible to use diagrams to summarize the software functionality and log
relationship among variables present in the system. This information is provided in si?
way so that users of the system can understand.

(iii) User characteristics

To use any system, it is mandatory that users of system should have some basic knowledg¢ ie!
least the educational qualification or basic knowledge related to the field. This section prov
the criteria about the users of the system.

Scanned by CamScanner
(ap Software Engineering (MU - Sem. 6 - Comp) 2-15 Requirements Analysis and Modelling

(iv) Constraint

It includes limitations of components used in the aystem for example, hardware limitations.

(v) Assumption and dependencies

It contains the list of factors on which SRS is depending. That is if the factor changes it leads to
change in the SRS too.

(vi) Apportioning of requirements

It states the order in which the specified requirements are fulfilled.

> 3. Specific Requirements

This section of SRS actually specifies the Requirements briefly by taking help of information stated in
above section. This section is divided into following subsections :

(i) Interfaces

- This section of SRS contain the information about various interfaces that are needed for
product, like hardware/software interface, system interface, user interfaces, and
communication interfaces.

— It means that each and every input device, output device and the communication medium
used by system is introduced in this section of SRS document.

(ii) Database

To store data required and generated by system, database is required. Information about the
database used in the system is given in this section.

(iii) Performance

It describes the system performance which includes the required speed, task completion time,
response time and throughput of the system.

(iv) Software system attributes

- System attributes are : reliability, security, maintainability.

- This section of SRS provides the assurance that all system attributes will be provided by
product and the way in which terms these attributes are satisfied/ fulfilled.

“> 4. Change Management Process

~ Due to additional user requirements, changes in the system are occurred. This section providesa
way that will help to handle such kind of changes.
- As the system make any changes according to user requirements, SRS document should be
changed accordingly.

“> 5. Document Approvals

-~ The SRS document should be accepted by both the parties, including the customers for whom the
system is developing and the developer who develop the system.

Scanned by CamScanner
 FP sottware Gem. ; 0- 2-16 pe time and sign of both the parties,
~ Document Approvals section ineludo the approval = ——
1 Introducty
> «6. Supporting Information Rs, reference’, ete. on

~ Itincludes guidelines about how to tise SHS, index nary me

2.5.4 SRS Document for Online Student Feedback om This doe:
em > (MU.y, feediacck
: e ' he utilize

1.2 Scope
This syst
| feedback
|
cttained

13 Overvic

This sys
related |

1.3 Overview

2. General Description

2.1 User Manual

3. Functional Requirements
3.1 Deseription

fo 4. Interface Requirements
4.1 GUI . sea
| 42 Hardware Interface ea
| ; - = lota of p
| 43 Software Interface and stu:

| 5. Performance Requirements Spe, Anethe

| { it.
i 6. Design Constraints e'
; 2.1 User¥
{ 7. Other non-functional Attributes
: The sy:
i 7.1 Security hard c
1 A
7.2 Reliability 3. Functional

7.8 Availability 3.1 Deser

14 Maintainability - Fe
|
cc

{ 8, Operational Scenarios re
9, Preliminary Schedule

va : Fr

Scanned by CamScanner
(EFT sonware Engineering (MU - Sem. 6 - Com 2-17 Requiroments Analysis and Modolli

1. Introduction

1.1 Purpose
for online student
This document gives detailed functional and non-functional requirements
it should
feedback system. The purpose of this document is that the requirements mentioned in
.
be utilized by software developers to implement the system

1.2 Scope
hy collage staff. The
This system allows the students to provide quick feedback which is provided
view grade and grade
feedback report is generated and which is checked by HOD’s. He can
obtained to the lecturers.

1.8 Overview
students for maintaining feedback
This system provides an easy solution to collage staff and
related to collage staff and infrastructure, facility.

Submit Feedback
. \Feedback Report
dent}——>
ues
[Stu - Online Student.
Feedback System
Send Feedback Form

E-mail To Student

Fig. 2.5.3 : Online student feedback system

2. General Description
em by which
ces the traditional, manual feedback syst
-— This online student feedback system repla
rding facility
teachers are able to provide feedback rega
lots of paper work will be reduced. The
m.
easily. This is primary feature of this syste
and students are able to provide feedback
for filling
re is that feed back form can be prov ided to student and staff by emailing
- Another featu
it. ©

2.1 User Manual

Also
should provide Help option in which how to operate system should be explained.
The system
be given to user in booklet form.
hard copy of this document should
3. Functional Requirement

8.1 Description
r names for that
- For identity of staff, system should display staff photograph along with thei

corresponding subject and skills.

individual’s report whenever
- Statistical report accordingly subject or skill should display
required.

Scanned by CamScanner
 ey Software Engineering (MU - Sem. 6 - Comp) Requirements Analysis and Modelling

7.3 Availability

The system should be available during college hours.

7.4 Maintainability
There should be facility to add and delete feedback form for different purpose,

7.5 Reusability

The same system will be used in each semester.

8. Operational Scenarios

- There should be student database and teacher database. The student database should contain
name and feedback information.

- The teacher database should contain name, subject, skills, and other details.

9. Preliminary Schedule

The system should be designed within 6 months.

2.5.5 SRS for Hospital Management System

> (MU- May 17, May 18)
Q.2.5.6 Develop a software requirement specification (SRS) for developing a software for Hospital Management
System.

Create an SRS that contains following:

1. Objective and scope

2. Product Perspective

3. Functional Requirement ‘
4. Non Functional Requirement (Ref. sec. 2.5.5)

Title

System Requirement Specification Document for Hospital Management System.

Objective

To get with preparing requirement document, which will be used to capture and document all the
requirements at the start of project. In the assignment we mainly focus on functional requirements.

1. Introduction

1.1 Purpose

The main purpose of our system is to make hospital task easy and is to develop software that
replaces the manual hospital system into automated hospital management system. This
document serves as the unambiguous guide for the developers of this software system.

Scanned by CamScanner
1.2 Document Conventions

HMS - Hospital Management System

GUI - Graphical User Interface
Number
PHID - Patient Hospital Identification

1.3 Scope of the Project

the
The purpose of this specification is to document requirements for a system to manage
hospital.
do. .
The specification identifies what such a system is required to
requiring different
The Hospital Management System will manage a waiting list of patients
,
treatments.
the next appropriate
The availability of beds will be determined and if beds are available
patient on the list will be notified.
Nurses will be allocated to wards depending on ward sizes, what type of nursing is needed,
operating schedules, etc.
is time consuming and
The current manual method of managing patients, nurses, and beds
this process.
error prone. It is also difficult to manage the large paper flow involved in
relevant
The Hospital Management System will allow hospital administrative staff to access
information efficiently and effectively.
The goal of HMS is to manage nurses, patients, beds, and patients’ medical information in an
cost-effective manner.
All of these sub-systems (managing nurses, beds, patient medical information) need to be
designed and implemented so that HMS can run effectively

Overall Description
2.1 Product Perspective

The HMS is designed to help the hospital administrator to handle patient, nurse and bed
information. The current design goal is to build an internal system to achieve the functionality
outlined in this specification.

22 Product Functions

The HMS will allow the user to manage information about patients, nurses, and beds.
Patient management will include the checking-in and checking-out of patients to and from
the hospital.
The HMS will also support the automatic backup and protection of data.

2.8 Operating Environment

Following are the requirements for running the software successfully :

Processor — Pentium III or Higher.

Scanned by CamScanner
[37" sottware Engineering (MU - Sem. 6 - Comp) 2-21 Roquirements Analysis and Morselling

~ Ram -612 MB or Higher.

- Disk Space - 10 GB or Higher.
- OS-— Windows XP or Above.
24 Design and Implementation Constraint
- GUlonly in English.
- Login and password is used for identification of user and there is no facility for guest.

2.5 Assumption and Dependencies

~ It is assumed that one hundred compatible computers will be available before the system is
installed and tested.

~ It is assumed that Hospital will have enough trained staff to take care of the system.
3. External Interface Requirements

3.1 User Interface

Input from the user will be via keyboard and mouse. The user will navigate through the software
by clicking on icons and links. The icons will give appropriate responses to the given input.

3.2 Hardware Interface

These are the minimum hardware interfaces :

- Processor : Pentium III or Higher.
- Ram:512 MB or Higher.
- Disk Space : 10 GB or Higher.

3.3 Software Interface

These are the minimum software interfaces :

- Technologies : C# .Net 2.0

- Database : SQL server (standard edition).

- Operating system : Windows XP or above.

4. System Features
4.1 System Features

- Work Scheduling : Assigning nurses to doctors and doctors to patients.

Admissions : Admitting patients, assigning the patients to appropriate wards.

Patient Care : Monitoring patients while they are in the hospital.

Surgery Management : Planning and organizing the work that surgeons and nurses
perform in the operating rooms.
Ward Management : Planning and coordinating the management of wards and rooms.

Scanned by CamScanner
 Requirements Analysis ang Mod ie
li
(ae sonore Soe
: | E i
waiting for availabj, be, i
bef sag

EP sonware Engingering (MU - Sem. 6 - Comp) 22 patients

if there are any ble ‘i — Ause
— Waiting list : Monitoring to sce ese become availanle- j
‘ rv Compon
assigning them to doctors and beds once t
t
5. Other Non-functlonal Requirements | - Useci
. Jarly are done: ||
6.1 Performance Requirements
« a t i t s best when the following 7e8™
- is at its
The performance of our software
|
— Password Management

— Regular Database Archiving

Virus Protection i
-

5.2 Safety Requirements ve of common errors should be limited. eg y, | +» W Use

but the negative oi and be asked to confirm their intent , "| | _ Use
Humans are error-prone,
that a given command will delete data,
should realize
_ Ale
have the option to undo.

5.3 Security Requirements - Toi

— Each member is required to enter an individual Username and password when accessing i, | prol
mo. Tt is
software. Administrators have the option of increasing the level of password security the |
members use. : | - Ex:
Protection.
- The data in the database is secured through multiple layers of
Security of you|
: . . y

— One of those security layers involves member passwords. For maximum

software, each member must protect their password.

5.4 Software Quality Attributes j

| > ii) Ac
The Quality of the system is maintained in such a way that it can be very user-friendly. The|
software quality attributes are assumed as follows : | - A
- Accurate and hence reliable. ~ At
- Secured. | -— Te
|

- Fast Speed. de
aa
- Compatibility.
t
A.
of}
Syllabus Topic : Developing Use Cases (My) —

2.6 Developing Use Cases (UML) . |

|@.2.6.1 Explain the development of use cases. (Ref. sec, 2.6) at)
- Use case is a term used in system ; (5 Ma
: analysis to de > Gi
requirements termine clarify and integrate all syst#* “ang
- describes h how user interacts with the system to
It describes a ‘
- Use case consists of three basic elements as act
Tr, System and Boal.

Scanned by CamScanner
 Ry vated RET

e done ‘ - vu 5
Se case dia :
gram consists of following three mai
n componnent
ent s,
Components of Use Cage

(iii) System boundary

Fig. 2.6.1: Components
of use case
> i) Usecase
— Use case of a use case diagr
i am represents various business
activities performed in a system.
- All discrete business activities of 4 syste
m can be modeled using use case.
- To identify use cases of a system one
should list all discrete business activities of system in
problem statement.
-— Itis represented by an elliptical shape labeled with
use_case name.
- Example,

Security of you _ Update account 2)

Fig. 2.6.2 : Use case

> (ii) Actor

ser-friendly. The |
An actor is any entity or real world object which performs different functions in the given system.

An actor in use case diagram interacts with use case of use casediagram.

To identify actors of system one should search in problem statement of system for the term
describing various roles in system.
An actor is represented by stick figure outside the system boundary.

a
eo
j
Actor_name

ae Fig. 2.6.3 : Actor

5 mat) “> (iii) System boundary

ote” — System boundary defines the scope of system or limits of system:
te 4 1 sy8 m statement.
ire system as described in proble
- Itis representation of ent
olid line rectangular box.
presented by si
- System boundary isre

Scanned by CamScanner
 Se :

i a, Mores
Requirements Analysis ind
et Software Engineering (MU - Sem. 6 - Comp) 2-24
bo
wa where as a ctor is outside of the system Uday
— Use cases are drawn within system boundary
er Software Er
ea
|
- Her
= -— System boundary
(iii) Genera
Actor
— oe
kis
Fig. 2.6.4 : System boundary
| :
~
ti
Iti
:*
Relationships In use case diagram xamp| D
them
is in general a dependency among
°

- Arelationship between two use cases

following :
i — Use case relationships can be one of the
|
| (i) Include
case diagram, «
=e use of functionality of another use
Wit [4i = When a use case is represented as making
include relationship.
Hi tii , relationship between use cases is called
inting
i arrow head pointing towards derives.,
towards derive,
arrow with
ii | — An include relationship is denoted by dotted
| case.
Ee
— Stereotype <<include>> is labeled on arrow.
_,
Example,
d
- 7
I
i
ee

Fig. 2.6.5 2.7 Re

|
| i. (ii) Extend
Q. 2.
(Gaz
adds new features to ens?ist
||| - The relationship between two use cases in which child use case
-
| functionality of parent use case is called extend relationship.
|
i|a - Itis represented by dotted arrow with arrow head pointing towards parent use case.
i - Stereotype <<extend>> is labeled on arrow.
Hi . :
{ Example,

mor

(a) - The

Scanned by CamScanner
 [GFP sottware Eng
ineering (MU - Sem
. 6 Co

a eles
- mp)
2-25
| Requirements Analysis and Modelling
Here Percentage
helps to decide class
of stud

to
Gii) Generalization
I ™

(~~ Store customer >

J ecords (comp.:file)

@ The Use Case Model

- A Use Case Model describes the proposed functionality of a new system. A Use Case re
discrete unit of interaction between a user, called an Actor, (human or machine) and the sys'

' - This interaction is a single unit of meaningful work, such as Create Account or View Acco
Details. Each Use Case describes the functionality to be built in the proposed system, which can
include another Use Case’s functionality or extend another Use Case with its own behavior.
=

Syllabus Topic : Requirement Model

2.7. Requirement Model _

Se Q es S ee fi (10 Marks)

0.27.1. Explain requirement model. (Ref. sec: 2.7)

constraints have been
eli ng is imp lem ent ed after the requirements and
Requirement mod
lysed.
collected and further ana ncy as well as
con sid ered as vita l acti vity to make sure the consiste |
ng is |
Requirement modeli
e requiri emen ts.
completeness of th X tr ib
nd ¢
utes and constraints. Se
lection of
ti on al , qu al it y at
to model func
different options nizational standards.
of system and the orga
- .
g up on th e ty pe
depe nd in ts can be modelled; some of the most common requirement
vesuititabablele aapp’ roach is requiremen
ways
There are many
e aS follows :
models which ar
.
Dom jodel ~
fe) The Domeln all the respective things (Domain Concepts) the product or system
- The Domain Model capturs and manipulates from a business perspective.
gents

Scanned by CamScanner
 et AMT)
j cas ften properties and the;
~ The information captured for a Domain Concept is a description and 0 at
relationship to each other.
“ao of f the the stat
statiic aspe
~ The purpose of the Domain Model is to establish a
common undeertant"e ms
the business domain among all the stakeholders.
by establishing a commo,
~ The Domain Model supports the redu creation of quality requirements
vocabulary across all stakeholders cing ambiguity and redundancy.
¢
- As aresult, the following guidelines should be considered :
o The contents should be written in the business language one domain and Sve
actions, which some
implementation specific or technical aspects (such as operations oF
presentations do not rule out): Use good business names!
o Stakeholders should be comfortable with the chosen representation of the Domain Model in
_ model may be
order to be able to provide feedback. As a result, multiple views on the
necessary for different stakeholders.
details are enriched over time,
o The domain model is developed in iterations where necessary
in
- An obvious way to identify Domain Concepts is to identify nouns and phrases
Concepts can come from e
descriptions of a domain. The information about the Domain
industry standard documents for a specific domain, and output from
documentation,
requirements elicitation. .
nt
~- The Domain Model can be represented in different ways. The representation is depende
methodology and the formality employed in the project as well as the experience of J

stakeholders exposed to the Domain Model. It can stretch from a Word document, an Excel table
and diagrammatic representations to a fully detailed model representation using a UML class
diagram.
The Domain Driven Design approach is an extension of the Domain Model to produce an
implementation which is linked to an evolving model of the domain, it is appropriate for a highly
complex domain and produces a highly maintainable system, and the implementation can be done
by Domain Specific Language.

(b) The Use Case Model

A Use Case Model describes the proposed functionality of a new system.
A Use Case represents a discrete unit of interaction between a user, called an Actor, (human of
machine) and the system.
This interaction is a single unit of meaningful work, such as Create Account or View Account
Details.

Each Use Case describes the functionality to be built in the proposed system, which can include
another Use Case’s functionality or extend another Use Case with its own behavior.

Scanned by CamScanner
 aq the
F Of tha Stag Ys
Ae
hey|
“Stablishin y
a
“my, |

he domain

§
Ry Life © Cycles are often
referred to ag State
f the Do... Machines or State
Charts.
Business Proces
+ domain Mode} | ly s models

May h, The use of Busine

ss Process Modell
ing (BPM) to represent
alternative approa the functionality of the enterprise
is an
ch for develo ping softw
re enriched over ¢ are as fundamental concept. It
in a tool which can be t is to develop the model
then use d to produce an execu
table model.
id. Phrases in tty Each element has KPIs (Key
performance indicators) attached
to it so that it can be frequently
used as part ofa perf ormance improvement proce
in come from exists, ss.
7
ind User Stories
output from
In agile projects user stories are used to capture requir
ements, these are short descriptions of how
a particular user wants to interact with a system, in the
form “As I want to, so that”.
n is dependent onth.
The user story includes a set of acceptance triteria which describe
the boundary of the story and
1@ experience of th defines when it is done.
ument, an Excel tath:
Traceability Matrix .
n using a UML cus)
To fulfill the need for traceability a traceability matrix can be produced.
This can be as-simple as a table which cross references the tequirempnts to the software
fodel to produce #! component that fulfils it, however this can become very hardto maintain, so it is more common to

sropriate for a hit use a requirements management tool when this level of formality is required.

entation can bed

2.8 Analysis Modelling —

Write importance of analysis modeling. rks

(Ref. sec. 2.8)
Q. 2.8.1 {6 Ma |

After the Requirement An alysis, as output gets the specification regarding software’s operational
's interface wi th other system elements and set up constraints
char. acteristics, designates software
. ftware must need.
which the spétifie a alysis modeling the primary focus of software engi.neer is: on what and
All the way through an 1S

how.
; «s helps the software engineer
i to:
;
Ani sion of basic requirements which are set in earlier requirement
a iled informa
o Get detailed
engineering tasks.

Scanned by CamScanner
 2-28 Requirements Analysis and Modatting :
FF software Engineering (MU - Sem. 6 - Comp)

co Establish models which describe user scenarios, functional activities, problem classes
with eB Eng
sortwaro
i © Th
the data flow ag it is transformed.
their relationships, system and class behavior, and
- Ensure
~ There are three primary objectives of analysis model :
' ° Es
1. Describe customer needs
' - Keep
2. Establish a basis for the software design generation, and o D
ted after creation of software. :
3. Define a set of requirements which can be valida
° In
- The analysis model fills the gap between a system-level description which elaborates overay
ng software, hardware, data, human,
functionality as it is accomplished by the process of applyi tion
which elaborates the software applica
and other system elements and a software design
architecture. i fo.202
— 4. Scenario:
_- That means Analysis model plays a role of link in between the ‘system description’ and th,
’
‘design model’.

Fig. 2.8.1 : Analysis Model

is defined and all of the

- In this model, information, functions as well as behaviour of the system 4. Flow c
e and component level
elements of ‘design modeling’ are translated into the architecture, interfac
- |r
design.

2.8.1 Analysis Rules of Thumb

or business
- The model must concentrate on requirements which are visible within the problem
domain. The abstraction level must be comparatively high.
understanding
— Each and every element regarding the analysis model must be added to an overall
behavior
of software requirements and supply insight into the information domain, function and
of the system.
until design.
Delay consideration of infrastructure and remaining non-functional models
ent it, the
o For example, there may be need of a database, but the classes required to implem
functions necessary to access it, and the behavior which will be exhibited after its use must
be considered after the completion of problem domain analysis.

Minimize coupling throughout the system.

saa
me

. ‘
~

Scanned by CamScanner
 2-29 Requirements Analysis and Modellin:
er software Engineering (MU - Sem. 6 - Comp)
o The level of interconnectedness among classes and functions must be minimized.
stakeholders.
Ensure that the analysis model offers value to all the relevant
o Each constituency has its own use for the model.
Keep the possible simplest form of the model.
° Do not introduce extra diagrams if they do not provide any new information.
o Implement only those modeling elements which have values.

2.8.2 Elements of Analysis Model

(5 Marks)
Q.2.8.2 Explain the various elements of analysis modoling in dotall. (Ref. sec. 2.8.2)
1. Scenario. based element

— Scenario based elements represent the system user point of view.

Examples: Use case diagram, user stories.

Class based elements

The object of class based elements is manipulated by the system.

It defines the object, attributes and relationship.

The collaboration is happening among the classes.

Examples : Class diagram, collaboration diagram.

3. Behavioral elements
m and how external events affect it.
- These types of elements represent state of the syste
- Examples : Sequence diagram, state diagram.

4. Flow oriented elements

system.
Information is transferred via a computer-based
flow between the different system functions.
It shows way of transforming data objects whe n they
Example : Data flow diagram, control flow diagram.

Scenario-based elements’ '- Class-based elements —

* Use-case diagrams .¢ Glass diagrams

« User stories ¢ Collaboration diagrams —

Analysis Model
bh \ ey

Behavioral based elements Flow-oriented elements

‘Sequence diagrams «Data flow diagrams
» State stories ers Control flow diagrams

Fig. 2.8.2 : Elements of Analysis Model

Scanned by CamScanner
 BE some cram a
conn 30 Requirements Analysis ang f
— gineering(MU - Sem.
6- Comp Mody,
= Model _ SS t (As
—_ Syllabus Topic : Scenarlo-bas os
2.9 Scenarlo-based Model {i
f
j

la. 2.9.1__ Write note on Scenario basod model. {10 :

(Ref. 9c. 2.9)
‘
Use-cases are simply an aid to defining what exists outside the sys tem (actors ) and what i
thoy i
d
be performed by the system (use-cases),” Ivar Jacobson i
: i scenario in straj
The concept is relatively easy to understand- describe a specific usage TBD Lory |
language from the point of view of a defined actor.

2.9.1 Writing Use-Cases |

f

.
We have already seen how to develop use cases. The impor ts are:
tant aspec }

(1) What should we write about?

'
Inception and elicitation provide us the information we need to begin writing use cases, i
(2) How much should we write about it?
(3) How detailed should we make our description?
(4) How should we organize the description?
;
Use Cases :
— Ascenario that describes a “thread of usage” for a system.

Actors represent roles played by people or devices as the

system functions.
Users can play a number of different roles for a given
scenario. i
2.9.2 Developing an Activity Diagram
|

2.9.3

*i8- 29:1: Developing Activity pj

t are the main tasks or functions

What '. that are Performed by the actor?

Scanned by CamScanner
 ep Software Engineer
29 (MU - Sem, -6. Com )
Wh: .
at System Informatio

Valid Passwo
rds/ Ip
aan words/ ID

May also be
Selected

ee ei Prompt for ~ |
| another view

Exit this function

Fig. 2.9.2 : Developing Activity Diagram

2.9.3 Swimlane Diagrams

diagram and allows representing

The UML swimlane diagram.is a useful variation of the activity
use-case and at the same time indicates which actor or
of activities des cribed by the
the flow
sibility for the action described by an activity rectangle.
analysis class has respon

Scanned by CamScanner
 ce e
are Engineering (my.

ee
a,
uirements Analysis ‘

| ae ftw.aro ;
Sem. 6 Core)
2 ;
nts that divide the diagram vertically, Wika
; 40.1 Identifying
2.
Analys
i [ _ eneincorng (Mu
° The problem state
i ~ Responsibilities are represented 98 parallel senm°
{ » lanes in a swimming pool. Interface For isolation of po

_ Identify each and

Home owner
- Identify operatio,
~ There are numbe
. |
o External ,
cond ea
information
rds AD Invalid o Things sy,
( Select major function) " _ Valid Bgjsswords ID | passwords /ID
4,
informatior
I — o Occurren,
Input tr °
Other functions
i main $
regarding 1

| wesc”
o Roles suc
( Select surveillance with the s
j - Nq Input tries
remain
| o Organiz:
applicati
i o Placess
i respectin
| oo Struct
( Promptior . | objects
. another view — Be One can ex

See another problem.

camera -
| — After the p
The list ge
{ .
function \ considered

Fig. 2.9.3 | - Bachand

een { — To detern
ee er NE
Syllabus Topic : Class-based Model measured
a
o Reta
2.10 Class-based Model is only

«iowa °. Nee
[a.2.10.4. Write nota on class based model. (Ref.sec. 2.10) hav
j'
: . F | eo
_ —. This section describes the process of developing an Object-Oriented Analysis (OOA) model.
als
identifying potential analysis clasts
— The generic process described starts with guidelines for
of the Clas rey
suggestions for defining attributes and operations for those classes, and a discussion 6 Ce
Responsibility-Collaborator (CRC) model.
th
- The CRC card is used as the basis for developing a inebowosk of objects that comprise the aie
relationship model. =

Scanned by CamScanner
47 sonwaro Engineering (MU
- Sem. 6 - Com: 2.33 Requirements Analysis and Modetin
2.10.1 Identifying Analysis Classes

- The problem statement should be examined to identify analysis classes,

For isolation of potential classes a “gr
ammatical parse” can be used,
Identify each and every attribute of
all the classes
Identify operations which lead to manipulation of
the attributes,
There are number of ways
by which Analyaie Classes
manifest themselves :
o External entities
. : such ag several system
s, devices and people that generate or use
information to be referred
by a computer. based system.
o ;
Thin gs such as Teports, dis plays, lett
ers and signals which are
information domain for considered as part of the
the respective problem,
© Occurrences or events
such as a
regarding robot moveme property transfer or the finishing point of a series
nts that take
Place within the context of system operation.
© Roles such as manager, engineer and salesperson played by
individuals who need to interact
with the system.
© Organizational units such as division, group, and team which are
application.
basically relevant to an
o Places such as manufacturing floor or
loading dock that establish the context
regarding the
respective problem and the overall
function of the system.
o Structures such as sensors, four-wheeled vehicles,
or computers which define a class of
objects or related classes of objects.

- One can extract the nouns by performing a “grammatical parse”

on a processing narrative for a
problem.
- After the process of identification of the nouns, several potential classes
are proposed in a list.
The list gets increased until all of the nouns present in the Processing narratives
have been
considered.
- Each and every entry in the list is considered as a potential object.
- To determine whether a potential class can become an analysis class following characteristics
are
measured :

co Retained Information : The potential class is considered as helpful in the process of analysis
only
if information regarding it, must be remembered for the functioning of so the system.
o Needed Services : The potential class should posses a set of identifiable operations which
have ability to change the value of its attributes in some way.
o Multiple attributes : During R.A., the centre of attention must be “major” information; it is
also possible that a class having single attribute may be useful in design, but it’s better to
represent it as an attribute of another class during the analysis activity.
© Common attributes : It is possible to define a set of attributes for the potential class,
and
these defined attributes can be applied to all instances of the class.

Scanned by CamScanner
 ee
~

:
a.
wee

the Potentiay
f operations for
define n net 0 eal Sottwaro Enginoering
yaaiblo to the class.
c en of .
. is pe l instan
o Common operations san It cat 1 be applied to ol ! n the
: blem spac,iy, on .“
pro e c t ‘ e
r sp
on ch appea lution' for the re
those dofined operations tities tiwonhi of any po
ti

» Rate A Len!
‘
Extern!
oo Bxsential Requirements: opera el
y to t ment mod
or use informat
ion necossay, roquire
sae) aa it a tho
!

be defined as cla t
nearly always '

2.10.2 Specifying Attributes |

class within the Conteny ha
ic h co mp ! etely dofine the \
wh
of data ot yjoots ,
- Attributes aro set .
sp! e.
problem spac tes for an analysis clasa, q —
attribu'
gful set of
ro
eloping & mean in Ce
For the pur pos e of dev
belong to the class,
—
which *peasonably”
re

and cho ose suc h thi ngs types

can revise a use-case items fully define
th, 7 ID

for eac h 1 cla ss : what data leeation

should be concerned fisted Viery,
‘A vital aspect that panAngt
at hand. ZoomSe
the context of the problem ee
Seterrni

Class name Gisplay!

Attributes inplay!
Gisplay;
systemID
:
systemStatus
delayTime
joneNumber
masterPassword
temporaryPassword

"program ()
display reset ( )
-— Operations

x
}
2.10.3 Defining Operations
Fig. 2.10.1 : Specifying Attributes

Operations which define the behavior of an object are divided into 4 broad categories :
1 Operations which manipulate data (adding, deleting, selecting, reformatting.)
| 2.11 Behavi

lo.2a14

events or
The|

Followin;
| 2. Operations which carry a computation.
3. Operations which inquire regarding the state of an object. 1. Eval
qiI, syst
| 4, Operas which monitor an object for the occurrence of a controlling event.
2, Ider
‘

Bpe

3. Ger
4. De
,

Scanned by CamScanner
at gottware Engineering (MU - Sem. 6 - Com 2-35 Requirements Ana als and Modell
\.

Floorptan

typo
namo
outsideDimensions
delermine Type ()
positionFloormplan
scale ()
change color ()

is placed within»

A
i9 part of

Camera
type
ID ; “- Wall
location
; type
fieldView wallDimensions
panAngle
ZoomSstting determineType ()
determineType () computeDimensions ()
translateLocation ()
displayID ()
displayView () is used to build >> <4 is used to build
displayZoom () A is used to build

WallSegment Window Door

type type type
startCoordinates startCoordinates startCoordinates
stopCoordinates stopCoordinates stopCoordinates
nextWallSegment nextWindow nextDoor

determineType () determineType () determineType ()

draw () draw () draw ()

Fig. 2.10.2 : Class Diagram

Syllabus Topic : Behavioural Model

2.11 Behavioural Model

Q.2.11.1 Explain behavioral based model. (Ref. sec. 2.11) — (10 Marks)

The behavioral model describes the way by which software will respond to any kind of external
events or stimuli.

Following steps are necessary to create the model :

1 Evaluate all available use-cases to completely recognize the series of interactions within the
system.
Identify events which force the interaction sequence and recognize how these events relate to
specific objects.

Generate a sequence for all of the use-cases.

Develop a state diagram for the system.

Scanned by CamScanner
 sone _
ate mr
ag OSE
.

ait
Requirements Analysis an (N
Morn, a goitware Engineering
2-06 i . Spe
. 6 Comp) wweitl ng the Software
EP sonware Engineering (MU- Sem cura
model to verify 4
5. Review tho bebavioural
s of states mn
ant characterization
vw
there are two import
hin ora l mode Ling, e
In the context of behavi
i
d
-
performs jt s function an
should be considered: the sy stem
carry out its function,
ad fr om the ov tside as the system
Thes tate
esta —identifie
a system
tes ofofthe 1 a s active char
acteristics.
co.© Th e
sive a8 we ject.
-— Thestate ofa class
considers both pas
al l th e at’ tr ibutes of an ob
of
rrent status
g but the cu . as it unde j
th in tive object
t
iv e st at e is no sta tus
of the respec
A pa ss res'en ts the
cu ltent
of an objJ ect repres ,
The active state mer. lockedTime
ation or processing. 6
a continuing transform
'
'
ft

|
timer > lockedTime | a Specification C
i

— Layered fo
password = incorr
ect
smaxTres
\
and numberOfT!ries i - Consistent
f
numberOfTries>maxTries ‘
— Allacrony
comparing
l
- Compulso
em. reading
rd
Fe toned do:validatePassword - Style sho
fe |
password=correct
{

|
activation successful

Fig. 2.11.1 : State Representation

t
- The States of a System \
syste™ a
is a set of visi ble circ umst ance s whi ch characterizes the ‘behavior of a
o It
State :time.
given
\
o State transition : It is the movement from one state to another.

°o Event: It is an occurrence that causes the system to exhibit some predictable iro
behaviour. . t
\

° Action : It is a process that occurs as a consequence of making a transition.

Scanned by CamScanner
 et Software Engineering (MU - Sem. 6-¢ ‘omp) _ ihay
writing the Software Spe Requirements Analysis and Modelling
cification

Everyone knew ex
a ctl
what had to be done
until ’
eo wrote it
down

30eg

& Specification Guidelines

Layered format must be used which can provide increasing

detail as layer deepen.
Consistent graphical notation must be used and textual terms should be applied.
i
All acronyms should be clearly defined.
Compulsory include table of content; ideally include an index and glossary.
Style should be simple and unambiguous.

Chapter Ends...

Qoo00
=
eS
See

Scanned by CamScanner
 a

EET sonware E: i ing (MU - Sem.

6 -C

project Sc neduling and Tracking easing atc, or

of their software developm:
aN - Enterprises which attain |
Probability of carrying effi
| > 2 The Product
— Product is nothing but
development of produc
consideration of subst
- A trics.

ct and process)
Process and Project
:
me
MO II Model,
.
Specializeq
1t \
.
:
constraints must be do
Management Spectrum, SPs (people, Prod vicat Estimation Models * coco Estat ' — If there is lack of th
Software Project Estimation : Loc, FP, Empi \ estimates of the cost,
. king the S
Techniques. . Software Project, Timeline charts, Tracking chedule, Eamay t' *
controllable project s

Project scheduling : Definin: g a Task Set for the +> 3. The Process
Value Analysis.
— A-software process
\ complete plan for »
| ct and Process) \
— There are differen
3.1. Management Spectrum, 3Ps (People, Produ -
; 5 ‘ assurance points ‘
= |
||
i
O.34.1 Explain P's in software project spectrum.e $00 3.1 ) ee
(Rel.o with the function
software project or how toTak |
ent spectrum describes the management of a
! team.
- Th e managem _ At last, umbrell
project successful.
of the project hay, any one framex
Its focus is on the three P's; People, Product and Process. Here, the manager the goal. ‘
and to reach
control all these P’s to have a smooth flow in the project progress
2 oe
m in detail. 4
— We will see all of those three P’s of management spectru
' | 3.2 Process and
Management
spectrum
sctrum 33 P’ P’s . {} — It is possible
' F on a regula
- Measurem
\ quality cor

y — Atthe ent
t .
Fig. 3.1.1 : Management spectrum 3 Ps \ the a
> 1. The People
| - _
In the |
- People of a project includes from manager to developer,
from customer to end user. ' concern
~ But mainly people of a project highlight the developers.
3.2.1 Metrics |
— _ Itis so significant to -have highly skilled as
well as motivated devel:
Management Capability Maturity Model) is developed by thepiri ai i iney * - Thee
odscnen
enhance theth readin. ess of software ent . are Engineering Insti
time.
erprises to handle more and more
robust applications1
a

Scanned by CamScanner
iCking = menngineering (MU - Se mM. S-Com
B= p) ‘a
assisting to
attract, grow, * Motivate, deploy,
Projnes Se heduth
_ ing and Tracking
of their software develop and retain th e talent nece
8A) Ty for the improvement
ment capability,
Enterpri. ses whicichh attain hi
Probability of carrying a igh levels of maturity in the «
a of
. ring Practicee: s,
cient soft ‘ware enginee People management have a great
> 2. The Product

lized Estimati,
n

hedule » Eam,
eq

A.software Process is used to *

it i
Provide the framework from whicheS ak ‘ i
complete plan fi ‘or software . development.
ee echhe ty PaeaeT
There are differe; t e

—Gterg
assurance pointe w ae such as different tasks, milestones, work products, as well as quality

the ework regarding activities to be made compatible

with the functionalities2 recs s mabe :
pective software project and the related necessities of the project
v to make a
team. :

At
any last,
one um ve Sa iviti handle the process model. Umbrella activities are not dependent on
“oject has to 7 . .
work activity and are carried out throughout the whole process.

Syllabus Topic : Process and Project Metrics

3.2 Process and Project Metrics

of improving it
It is possible to apply measurement to any of the software process for the purpose
on a regular basis.
,
of a software project to help in estimation
Measurement is very useful throughout the lifecycle
as well as in project control.
quality control, productivity assessment
for the purpose of assessing
is done by the software engineers
At the end, the use of meas urement decision m: aking process aS
the
products and to help in strategic
the quality of respective w ork
inues.
project development cont ’ the project, the prime
and the so ftw are process conductedby
ects
In the persp ective of proj quality metrics.
sof tw are tea m is prod uctivity as w ell as
concern of
Domain
ess and P roject
3.2.1 Metrics In the Proc and for a long period of
ne thr oug h all the related projects
The collection of
process metrics is do
eople —
ste to time.

ngs by

Scanned by CamScanner
 Project Scheduting ray
Comp 3-3
Soft dicators which Fesulta in tog
Sem S0 ,
LP sotware Engineering (al
is to provide a series of process inc
— The basic idea behind " mets 2
software process improvement. i ee Sottware En
r to:
a software project manage
- Project metrics enable
ject
of an ongoing pro a
co Assess the status |

o Track potential risks

before they g° “critical mai
o Uncover problem areas é Sen
°o Adjust work flow or tasks -
quality of software work products,
6 ee the project team’s ability to control
9
rovement
and Software Process Imp
3.2.1(A) Process Metrics
Pp

Ban) 8
. a—,
(Ref. sec. 3.2.1(A))
lo.s.24 Write note on Process Metrics. 1
ent in any process is the measure ofPann
‘The unique efficient method to make improvem
:
_ a,
process, establish a set of sign
ificant metrics depending upon these
attributes of the result in the stratg .
provide indicators which will
further use the metrics to
and by
/ :
improvement.
factors i,
— The important factor is that process is considered as only one of several controllable
performance. % _
practice of improving software quality as well as organizational
center of a triangle in which three factor, :
Fig. 3.2.1 shows that the process best fits at the
mance
connected which have deep impact on software quality as well as organizational perfor
— The skill and motivation of the stakeholders is considered as the single most significant far,,
quality and performance. : ‘
— There is significant impact of complexity of the product on quality and performance of the tean

- Also one important factor which has significant impact is the technology (methods and ta,
regarding software engineering).

_ Product

Adaitionan Fig. 3.2.1 : Determinants for software quality and organizational effectiveness f a
onally, there is a circle of enviro we . Re
=

contains following: ns around the process triangle whl

; © Development environment - integrated software tools

Scanned by CamScanner
 deri
- ak from the respective process
sults ,
software,
. wee det
cae“comes
wv contains
measures
en of
delivered to “fa 2 n found before releasing the
rod » de : ts which have bee: i . Fret have bee
echedul e been delivered i en
© conformance, and oth ee en een ct drain npn
User is also able to d , other measures, == as ‘A
parti : sie erive
, process metrics by the
regarding
> way of measuring the characteristics
For examplple, are engineering tasks.
g theuserumb might a ort and time whi been
implementin, tite i
Grady (Graay > rella activities as well nn
cock ie ax ~ as the
t generic solvers dhetnneering
i a activities.
=
os that there ore SuenAmerican software engineer, best known for developing the UML)
Bevsce i is very at and public” uses for different types of process data. ™
snplzies palate én ee
oO VIO
onat pndividual software engineers might be susceptible in using the
: se

. oe
individual
n ese data isi expected to be private to the respective
indie: = for 7that
and work as an indicator individual only
e examples of private metrics, i
i we can consider defect
m rates (by individual),
i defect rates (by
component), and bugs found in development process.

The. “pr “priva' te process data” ” viewpoint

vi int isi well compatible with the Personal Software Process
approach.
process improvem nt must be at individual level.
It is recognized that the beginning of software
aspect in improving the software engineering
Private process data is considered as an important :
approach.
public to all the
process metrics are private to the
software project team put might be
Some
remaining team members. .
in technical
reported
s foun d rega rdin g main software functionalities, defects
For examples, error or function.
nes of Cod e) or FP (Fu nct ion Points) per compon ent
reviews and LOC (Li formance.
tea m to get ind ica tor s to improve team per
by the
These data are reviewed private to individua
ls as well as for
originally was
ll y pub lic met ric s incorporate data which
Usua
n are ga! thered and
teams.
on , an d ass ociated informatio
, dura ti ional process
project level, effort improve 0 rganizat
Defect rates at ting indicato rs wh ic h can
d fo r ‘t he purpose of get
evalua te
s matcuri l fiw are
t
er al l le ve l of pr oc es uri ty, Som Wwe
of its ov
sauaeaial ncement
rise works for the enha
I

Scanned by CamScanner
 Project Scheduling ane»
3-6 f software roceay |
& j Software Engineering (MU > Sem, 6
= Comp)
possibility of misuse ° Proce an ne“Mig gotware a(
like like jon s,
all other metric of more is ' th
there proble than they solve- itable for both managerg te —
- However,
wel 4 - As there ist
which mnay lances —— jquette” which is su
Grady suggests a “software metrics ee elit program : done for the
.
well a8 organiza’ tional sensitivity in the process of mer ; ach co
appro.
- tion rs as they organize so@ as
ne itione
practi —
Make . use of comm on sen does the collection of Measures ; a
° Fekae who
metrics data.
;
my ched: ~
‘
individuals a
o Give usu al feedback to the
— Second, }
individuals.
— :
eas use metrics for the purpose of appraisal mar clear objectives and metric, Whig a.needed, 1
pract ition ers and teams to estal oe
°: Ca mMmMUuncaicate with
inateidunla oste
will be helpful to achieve them. _ .
wld not oa a
of threatening
o Don't refer metrics for the purpose
em area - take: Negative; Ty seceaaa[_''
Metrics information which specifies 4 problimprovement. es
ator for process
° information is just an indic . . a cot
twr
t me
i e me' tric to the exclusion of other importan
° Don’t obsess on a singl
7 tible
ore compa ring
with the gathe and use of process metrics,
- As the enterprise becomes m . to a more precise approach know, .uf
| as
provides means
origin of simple indicators :
Me
ent (SSPD.
Statistical Software Process Improvem we
ering det,
. ofrathgatheri
purp jose
- i re analysisi for the
Essentially, SSPI takes reference of software failu
developed and useg _ +
cation, system, orproduct is
regarding all bugs and defects found as an appli
:
- &b
3.2.1(B) Project Metrics

[a.322. Write note on Project Metrics. (Ref. sec. 3.2.1(B)

- Dissimilar to software process metrics which are helpful in strategic purposes, software projeg, P :
measures are considered as tactical. .
- It means, project metrics as well as the indicators derived from those project metrics are used
by
a project manager and the respective software team for the aim of adapting project workflow and
technical activities,
- In most of the projects, the first application of project metrics takes place in. the process of
re estimation.
- Metrics which have been gathered from previous projects are used as a basis for new project.
Those metrics are useful for estimation of effort and time for current software
work.
~ As the project proceeds, comparison of measures of effort and
time spent is done with origina
estimates.
~ The data is used by the project manager to monit
or and control progress.
As there is beginning of technical work, other
project metrics started to have importan
ce.
- The measurement of production rates whic
. ; h have been represented
in terms of models generatel,
review hours, FPs, and delivered source lines is done.

Scanned by CamScanner
 i : [ET sottwaro Engineering
(MU - Sem. 6 Comp}
ers ag _
- Additionally, errors
found rund
ii in all ; of the ~
- As there isi transition of ro
software f; . rere men are tracked.
done for the Purpose of ossess eering me “a 7
f interp, ing d. ex SiEN
7 Pauir “SI8N, gathering of technical metrics| is
ements to desi
qualit
tin,
Tet; 7 approach
pproach ii
considered to code generati ity ¥ a
sea . and to Provide indicators w
. . | on and testing. . 83 which w will impact theeo
- The ne
ci aim of proj
proj ect metrics
; ics
i twofold. Fir. st,
is
; e these Metrics
y the way of making are hy 1 i 4
th, j ustments which are j elpful in reducing the development
possible problems as well
88 risks, ead Mportant to avoid delays and lessen
- Second, project metrics are hel
etrics wh:
hic, eed
needed, make ch quality
product quality
‘anges ini the technical approacha to& enhance i on regular basis and, + whenwhe
- As there is improvement in quality,
. the amount
a i
of rework which may ¥,be necessa:
Gefects dre — and as there is reduction in defect count, :
tive . resul reduction of overall project cost ry in the project also get decreased. This ultimately

_ Syllabus Topic : Software Project Estimation

tries, ty 3.3 _ Software Project Estimation

nown éQ. 3.3.1

2 ie ~

ag } Explain
fai Software
fe Project Estimation
i in detail. (Ref. sec. 3.3) (so marks)|
. - Measurements in the physical
i . ‘ :
tte dag eaditchajumictendven world can be divided into two categories : direct measures (e.g., the
i used ine. indirect measures (e.g., the “quality” of product).
. - € same manner, it is possible to categorize software metrics. :
4 hh _-
the direct measures of the software process the elements involved are cost and efforts applied.

Whereas in the direct measures of the preduct, the elements involved are LOC (lines of code)
arks) | / | ~ generated, speed of execution, memory size, and bugs recorded over
some particular time span.

roje — indi
In the indirect measures of the product the elements involved are functionality, quality,
project
ility, and several other capabilities.
complexity, efficiency, reliability, maintainab
op software, the number of lines
of code generated, and
sed by - The cost and effort neces sary to devel
for
as particular conventions
ively simple to g' ather, as long
v and other direct measures are comparat
measurement are set in advance.
measuring directly the quality as well as
ss of — However there is difficulty in assessing and
or its efficiency or maintainability.
functionality of software im
y ct metrics, then
produ
is par tit ion ed into process, project 4, and
rics domain are usually integrate
ject. When the software met are pri vate to an individual
met ric s whi ch
it is ob served that product tive software team.
met ric s whi ch are public to the respec
develop p roject metrics which are public to the
nal met ric s is don e to generate process
of Proj ect . .
The consolidation
different ”
software firm
as & whole.
mb in e me tr ic s which are coming from
to co
an organization
But what wil l be the way for
ts ?
individuals or projec

Scanned by CamScanner
 Project Scheduling andy, || | nee
pan he ean .
—
3-7
ae se tivideals on 1
- Sem. 6 2 separate proj :
EP sottware Engineering (MU ivi : ea :
—— gi
a
ext! h are ene ountered during the software p, ng
nd this ele chic
a simp
: we willil take com
Toca,
A
— To unde rsta ess,
the scaibinodita iin deat OenG
and make categorization of all re . | me
"the seated HOE :
nn
— Those individual measures can "arin
38 before -
ane
erro!
- Team X encounters hundred
be i
in oa in,
- Bein
em evernitne do a
g en wot tar knowhledg
have whic e
team ofis whor
efficient
size eor complexity . cannot mb a°
> -
i o

process? Since w ° , i

wer to this question. “os habls to gecierite ities 7

meas ures
l , it 18
agespro
. |
— However, ifi we do do normalization of . the “sationa aver Netri., ;
vo
le comp aris on to broa der organiza
which enab
——
Metrics for Size Estimation
—e

3.3.1
> (MU-May 15, Dee. 16, ay
Baas aS DEES RA, ae)
- Size oriented software metrics are in general derived by the process of ae quality Andy

productivity measures by assuming the software size which has been produced.
_ If a software organization maintains simple records, a table of size-oriented measures wil] be
a
shown in Table 3.3.1.
- In Table 3.3.1, the details shown about all the software projects are developed in last five years,
- Project alpha : 12,100 lines is the total size of code with 24 person-months of effort at a Priceof
$168,000.

Table 3.3.1 -

[ alpha 12,100] 24 | 168 | 365 | 184 | 29 3

[beta 27200! 62 | 440 ‘124 321 | 96 5 —-
[ garam 20,200] 43 | 314 | 1050 | 256 | 64
6 a
It is important that the effort and cost
recorded in the table does not repr
esent only coding, but it
also represents various software engineering activiti
es such as analysis, design and
testing.
The further information show
s that the size of documenta
tion is of 365 p ages.
Before the release of softwa
re the count of

Scanned by CamScanner
 ° Defects pe
r KLOc,
oO $Per KLOc
‘
©. Pages of do
cumentatio n Per KLoc
- iThe Si1Z
. €-Orie
i nted metrics are '
hot cons idered 48 th
e best Solu
sol tion for meas |
~ uring the softwa
re ||1
Syllabus To
pic : Line of
Code (Loc)
3.3.2 Line of Code (Loc)

I Q. 3.3.3. .
Write note on LOC. (Ref. sec. 3.3.2) - =
= LOC is.the si _(5 Marks)
popular
. beca: ‘use itneis the
among all ‘metrics
simplest to use. available to estimate Project
project siz Thisi metricic isi very
size.
- Using this metric the .
* project size i i 5 . a
the developed program. _ estimated by counting the number of source instructions in

- While counting the number o f source instructions,

i lines’ . :
header lines should be ignored. ons, eg used for commenting the code and the
- Dersemiiniihiy the LOC count at the end of a project is a very simple job. However, accurate

estimation of the LOC count at the beginning of a project is very difficult.

- Inorder to estimate the LOC count at the beginning of a project, project managers usually divide
the problem into modules, and each module into sub-modules and so on, until the sizes of the
different leaf-level modules can be approximately predicted.
To be able to do this, past experience in developing similar products is helpful. By using the
estimation of the lowest level modules, project managers arrive at the total size estimation.
—
eeee —EaSSS—
EeEeeeeaeaeEeEeECoOCweee

Syllabus Topic : Function Points (FP)

—ooooooooOoOoOoOoOoeeeEe

3.3.3 Function Points (FP) .

. > (MU- May 17)
eS

en Te ee See Technique in detail, (Ref. sec. 3.3.3) :

.ag4 in Function Point Estimation : ; os
is given by the application is
Se tion value, a measure of the functionality which
—
As a normalization valuy, .
: . software metrics. .
taken by the Function-oriented . Hence
using other’ direct measures, it is
ti on al it y di re ct ly
the func
Itis not possib ibllee to measure
.
- sroetly
necessary to ve it indirectly.
derive r i metrics —_ propos ed initially by Albrecht. A measure called the
1 rien!

Scanned by CamScanner
 Project Schad,

Som. 6 = Comp) 2 empirical relationship a Se |t

EP sonware Engineering MU ‘Jerived with tbe help of am Den
* points are bast i cally de
abi the informatio n domaini of softwa, re Aang eiing
Be somnare engineering
countable (direct) measures re6® ta
“a »,* 8. Isthe upd:
complexity assesements. teristics are determined and counts are provideg. Therg 1 9. Is :
; c there
- Five information domain jenere
a 10. Is there i
qfons: i
Number of user inputs : Eat user
: Each 4a
input 4,arvot
should bemessages,
—_— etc.
7{ 11.12. Can the.
ts

e Number of user outps “— bss i/p which results on on-line o/p. ‘ 13. Is the
ane file is counted. | 14. Is the ¢
© Number of files : Each logical master file | oiih = Hedin
‘umber of external interfaces : Data files on storage media.
0M ° mplexity value is associated with each ~ The const
— Once these data have been collected, a comp! iteria for determini
Organizati function point methods develop cri Tmining
het
Whett., i appliedt
tions that use
particular entry is simple, average, or complex. Nonetheless,
None a the determination of oor, Playo - As soon
somewhat subjective. _ Weighting factae | E ;

function points
| Measurement parameter Count Simle Average Complex 1i L —_—___—_——

Number of inputs CJ x 3 4 6 =C) ' —— ee

Number of user outputs C] x 4 5 7 = CL) i 3.4 Empiric

Number of user inquiries Cc) x 3 4

j —_
6 -= ] ; joann
Number of files CJ x 7 10 15 = LC) | — The

Number
of extemalinterfaces [~] x. § 7 =C] j the
Count total 7} ~ ifs

Fig. 3.3.1
- Ev
~ To compute function points (FP), the following relationship is used :
n
FP = count total [0.65 + 0.01 5(Fi)]
~ ‘
(where count total is the sum of all FP entries)
= The Fi (i= 1 to 14) are “comp| . . . r Experirt
:
given fourteen
; questings plexity
exit;
adjustment values" depending
$
upon responses to the following -
1. Does there is need of reli
Te. : .
2. Is there any
liable backup and recovery to the system?
requirement ofcomm
unications?
3. Are there distributed
Processing functions?
4. Is performance critic
al?

system in current gre

6. Does there is-_ need of on-line data entry to syst”em?at]: Y utilized 0 ti
perational environment 9 -
a Does there is need of th i
€ input transacti i
screens or operations? on to on-line data entry so as to build ove . 7i
r multigl

Scanned by CamScanner
 Syllabu S Topic
7: Empirical Estima
tion Models
3.4 _ Empirical Esti
mation Models
lo.3.4.1 i Se

Peatestination techniques. (Ret. see. 3.4)

The Empirical estim ation (5 Marka) |
techni
the project parameters. ques are usually founded on making a studied guess regarding
If simi
similar products are developed previously
then that experience is always helpful.
Even tho ugh th the base of empirical
iri estimation techniques is common sense, several activities
Involved in estimation have been formalized over the years

There are tw o frequently used empirical

iri estimation techniques namely : Expert judgment
technique and Delphi cost estimation.
@ Expert judgment technique
and makes guess
- In Expert Judgment Technique, an expert analyzes the problem in detail
regarding the problem size.
the cost regardingthe different components (such as
Usually, the expert makes an estimation of the overall
ve systemand then integrates th em to find out
modules or subsystems) of the respecti
estimate.
expert may miss
exposed to human errors. Additionally, it is likely that the
Yet, this technique is
few factors accidentally. knowledge
expert who is making the es lack of experience a8 well as
timate may
Additionally, an
of all aspects of a project. and user interf ace components but may )
with the database
may be familiar uter
For examp e,
J e , he/sh e icatiion part.
communicat
not be conversant regarding the come

Scanned by CamScanner
 Z isrware Engineering (|
Project Scheduling and Tracy,
3-11 . . i Table 3.4.1 st
. . 6 - Comp) re refined form of expert Judgmeny
ey Software Engineering a
tai of ‘amas mo!
can be considered . iff The multiplhis
group of experts iliarity with a spectiie a8pect "Borda
— — Estimation made by
like individual oversig"" |
— It minimizes factors
project Complex
the project, etc.
‘ ch are
ert judgment approaeie tried to resolve
eran
Delphi cost estimation s cooiti
in gs of the een
exp
me of the shortcom
In this approach so
In this approach a team which seiyblyes a group irements Specification (SRS) document ty ay
: 1 f
,
ding their cost estimates
0
The coordinator gives a copy
cular formafor
a the pose of recor
purpo
a parti a or.
the estimators and to the coordinat
of the es' ti ma to rs and submitted
i ates are completed by y all |
ing the
characteristic regard
ividual estim
tors” point out any unusu al
Ina individual estimates, the estima
on the estimation.
product which has great impact
idering all the
s of the responses by cons
The coordinator then makes and hand outs the summary of the estimators,
rationale that may be noted by any
estimators, and incorporates any unusual
This method is repeated for
By considering this summary, all of the estimators re-estimate.
several rounds.
ding the estimates. The reason jg
However, estimators cannot communicate with each othe r regar
that the estimate of more experienced or senior estimator may influence other estimators.
After several iterations of estimations are done, the coordinator compiles the results and prepares
the final estimate.

Syllabus Topic : COCOMO II Model

3.4.1 COCOMO II Mcdel

D> (MU - May 15, Dec.16)

[Q.3.4.2 Explain COCOMO Model. (Ref. sec. 3.4.1) S May.15, Dec.16, 10 Marks

The COCOMO (Constructive Cost) model is an empirical model that was derived with the help of
gathering data from a large number of software projects.
These data were analyzed to determine formulae that are the best fit
to the observations.
These formulae link the size of the system and product,
project and team factors to the effort to
develop the system.

We cant select to use the COCOMO model for number of reason

s :
1. It is well documented, accessible
in the public domain and su
pported by public domain and
_ commercial tools.
2.It has been widely used and evaluate
d in several organizations,
COCOMO 81, first version of
the COCOMO model was a thre
e-level model.
The first level presents an orig
inal rough estimate,
The second level modifies
this using a several projec
t and process multipliers;
detailed level creates estima
tes for different stages of and the most
the project.

Scanned by CamScanner
 - Table 3.4.1 shows the 5
ALi.
- The multiplier Mm fete © COcg,
cts te
r tad

Complex projects
where the softwa
element of re is
a strongly couple
d.

COCOMO II helps in develo

pm.ent i
create the whole estimates, of a spiral model and embeds number of sub-models that

i Development effort.
based.on system design

model
Fig. 3.4.1 : The COCOMO II

1, The applicatio n-composition

pos modelar generated from reusable components, scripting
sams ys or database
- It supposes that sys

programming. '

eet

Scanned by CamScanner
 Project Schedulin and t,
eer fn are Engineering (MU _ Sem. - Comp) a ent. Shy : wo software Engineering |
ae f prototype developm:to COCOMO oe
otis ed to create estimates © II to maintain the estima PM =9
lished in tion ere,
-— he Seaton forcomposition
Thea model
pro totyping
was estab
projects. . . also called as object points SeParatey
M =

- Itdeeee onan estimate ofeeweighted application —

tivity. ; » 3. “The reuse model
a standard estimate of app vane, a ne ccmphacit? of development of every object poing,
- The estimate is thenchanged be ed on the experience and capability as well as the CApabitit,
— Reuse mod
os. is Is Fi
- that are ar
~ En teceadl besupport development. . 7 ee wet
of the f, * roductivity.
le 3.4.2 shows the levels of object-point P black-be
— Table staehows Table 3.4.2: Object point productivity _ Code th
——— ee | l Low Nominal high Very high develop:
—_ - work at
ae experience and

[CASE amaturity meand capability

oe | Veryiow | tow7 | Nominal | high | Very 50.high ; ae
[PROD (NOP/month)
4. 13 25
.

_ Therefore, the concluding formula for effort calculation for system prototypes is :
Where,
AT - Perc
PM = (NAPx (1x %reuse/100)) / PROD ; ATPROD
Where, . .
For example
PM - effort estimate in person-months.
ante
NAP - total number of application points in the delivered system. eal
reuse - estimate of the amount of reused code in the development. ge
PROD - object-point productivity

2. The early design model

-
- This model is used at the time of early stages of the r
system design after the requirements have E
been established. . j

- Estimates are depending on function points,

—_
which are then changed to number of lines
of source
code,
~ Estimates can be completed after the
user requirements have been agreed.
~ Depend on standard formula
for algorithmic models.
E
wt

Effort = Ax SizeBxM
i:
~ The multiplier M in COCOMO II is depends on
Process’ characteristics that influence
a simplified collection of seven projects and
the estimate. These can icrease
needed. These ch or decrease the effort
:
complexity (ROPX),
fae 1 , some
reuse required (RUSE), platform difficulty rye crits SHY design model are product reliability and | c

ERS), personn Sxperrence (PREX), schedule (SCED) (PDIF), Personnel capability

and support es
f lities (FCIL) 3
- This results in an effort computation
as follows : . . LE

Scanned by CamScanner
 pM = 2.94% SizeB x M

wher
M <= PERS x RCPX x RUSE x PDIF PREX x FCIL x SCED

The reuse model

4. ogrars cods
Reuse model is - to calculate the effort needed to integrate reusable soflware oF PT
that are automatically created by design or program translation tools.
be reused
For COCOMO II, reused code is of 2 types. First is the black-box code which ca” opment for
devel
without having mndwiicige of code or making changes in it. The effort regarding
plack-box code is taken to be zero,
pox code. Some
Code that has to be adapted to combine with new code is called white-
before it can
developm ent effort is needed to reuse this because it has to be known and changed
work accurately in the system.
The formula for effort estimation is :

pMAuto = (ASLOC x AT/100)/ ATPROD

Where,
AT - Percentage of adapted code that is automatically created
ATPROD - Productivity of engineers in integrating such code.

For example
of this is
If there is a total of 10,000 lines of white-box reused code in a syste
m and 40%
tegrate this
automatically generated, and ATPROD is 2400 then the effort required to in
generated code is :
(10,000 x 40/100)/2400 = 1.67 person months
some
when a system contains some new code and
The other component of the reuse model is used
reused white-box components that have to be integrated.
estimate might be 6,000.
Therefore, if 30,000 lines of code is to be reused, the new équal size
ent to writing 6,000 lines of new
Essentially, reusing 30,000 lines of code is engaged to be equival
code.
COMO
e to be developed in the CO
This computed form is added to the number of lines of new cod
II model.
that have to be adapted;
o ASLOC: Number of lines of code in the components

o ESLOC:Equivalent number of lines of new source code.

number of equal lines of source code :
The below formula is used to compute the
ESLOC = ASLOC x (1x AT/100) x AAM
Where,
Multiplier.
AAM is nothing but Adaptation Adjustment

Scanned by CamScanner
 2-15
MU - Sem. 6 - —
EE” someare Engmonring Corp) Estimation Techniques
A, ''
Syllabus opic : Spec!
|
\
3.5 Specialized Estimation Techniques
ie
soe. 25)
eposntied
nero Esiration Tectriques, (fet.
fos apn project.
- [ae
In the join —_ ition techniques can be used for any software
hort period of time for project completion (weeks instead of
§
estimation in particular Pie ue |
~ However. when there is very )
nuing series of changes,
ich
which isis probable to have a conti oul
abbreviated.
Here we will see two specialized estimation techniques :

3.5.1 for Agiletio

Estima n
Developm ent

— Since the requirements regarding an agile project are set by user scenarios, an esti,_.

— en
approach can be developed which is informal, reasonably disciplined, and meaningfy} in ,
i
environment of project planning for each software increment.
— Approach of Decomposition is used in the estimation for agile projects which encompasses the '
following steps :

1. Each and every user scenario is considered independently for estimation purposes.
2. The scenario is divided into
a group of software engineering tasks which will be Necessary +,
develop it.
3a. The estimation of effort needed for each task is done separately.

[Note The important elements for estimation can be historical data, an empirical model,| or “experience.”
sag
3b. On the other hand, the estimation of “volum
e” of the scenario can be done in LOC (Line
. Code), FP (Function of
Point), or in any other volume-oriented
measure (e.g., use-case count).
da Estimates of all the tasks are
combined to set an estimate for
the scenario. .
4b. Alternatively, historical data
is used to translate the volume
estimate for the scenario into
effort.

(2) To set a basis for

assigning effort as
the increment is de
veloped.
3.5.2 Estimation for WebA
pp Projects

WebApp projects usually like

to refer the sigile
develop an estimate for the WebApp. Process model. An updated FP me helps t

Scanned by CamScanner
 - Following approach ig wa ‘

o Inputs are nothing ed w

en ada:
screen, each tab (if
but the input Pting rp for
used), Nor f; WebApp estimation .
‘orm ¢
° ther Dae Static Web DP meh 8 CO or Java), every maintenance
i "page, .
o every
logicalandtable
Tables are everyScript), “TY dynamic Wey pe
in th Re script (such as ASP, PHP, of

interface such as Di ublished

M external ¥
~ - Function points Ps) or COM external references ¥ or take help of a message-criented
are conside: 3 . 7
— It is possible to dete Ted as logical indicator of yo} nies None
ebApp.

length, reused code length . ation), and functional characteristics (such a3 code a3

- These measures hel

: P to establish empiri
i . Pirical estimati
media authoring effort, and Scripting effort estimation models for whole project effort, page and
—_—
Syllabus Topic : Pro
ject Scheduling

3.6 Project Scheduling

~
| of - Project echetiuling is a technique
that decides the sequence of tasks to be done and
assigns
organizational resources to complete those
tasks in predefined timeframe.

- A project is nothing but a group of many tasks, and each task has start and end dates.
- A project scheduling is a kind of document that summarizes the work required to deliver the
project on time. :
It also distributes the estimated efforts across the planned project period.
In simple words we can say that the project scheduling establishes the “Road Map” for the project
manager.
ct
Syllabus Topic : Defining A Task Set for Software Proje

ect
3.6.1 Defining A Task Set for Software Proj
hr
cils. fe0c:: 3.6.1).
(lee __@N
Explain the krk ngBreBi ak
Woridi Down= etSIUC rinudeta
lo. 3.6.1 f div compl ex projects to simpler and manageable work items 18 called Work
|
The process of divi
Breakdown Structure (WBS).

Scanned by CamScanner
 Project Schoen
B17 ene
: js creating a data Sty
EP somware enginoering (MU SON. : Task. Example of work item "8 ; aabang tab, ‘
al Jed as a Tash
= = ,
item isia also ca jmplification of project execution, In Wrg ; v sofware
. jata. . for sim ite , j
poison The
- Project managers use this Se able items and later these items are Casily wy
in cents
are broken down to smaller mana
estimated. ico field. This methodology can be used for any ‘ Desigr

- WBS is not limited to a specific ot i - Decon

management. \ prese:

3.6.2 Reasons for creating a WBS In A Project ; o

comn

vering ¥ table example. = oe

2. 3.6.2 Explain the importance of WBS
in sofware engineering wil Sul
(Ref. sec. 3.6.2) ee
~ Following are the reasons for creating the WBS in.project : \

o Do accurate project organization. 7

o Assign accurate task of responsibilities to the project team.

© Doaccurate estimation of the cost, time and risk involved in the project.
o Illustrate the project scope.

© Plan the project according to availability of resources.

= WBS Construction .
: - aim ' poi
foStarting e the
point of WBS is to identify oo .
main deliverables of a project. Items can b
erent levels. One can break down one task to ten items wher ® bro don. q 7
same in 20 items. reas other can break
- . OW yt

Project Name

pe
Lark Package 1.7.1
Ork Package 1.1.2
| Work Packace 737]
ckage 1.2.1 or
Work Package 1.2.2 Ban
Pp 1.
Work Packa
98 2.1.4 2

Fig. 3.66.1 : ie Package 212 |

The effectiveness ofa Work bre was Structure 3
or, akd .

- The WBS provides

. the b Own structure can decid :
res ase for al] € the succe:
3.7
ee
ource allocat; ect m.anagement work lik
$8 of a: projject.
on, and Sched
. e 1 ms

Ng, Cost, effort estimation. |

Scanned by CamScanner
 Sofware Snginecring (MU - Sem, 8 - Co
- The Fig, 3.6.2 shows
created by bre. exam
. aking down the
Design etc, wath .
. of new toy, ut
- Decompositj ™Position)
Nn is Such ag Mart each level ig
the Process of es Recs
present at the low
akin arch, Product
commer. cials are aj} Wo
. level is called
rk pa~ ckages so
enewn Intheth items into sm, Mer
1
er items, The element j
~ Therefore, creating © example be <
low, brochure which
Wag j, Sritical step
ISKs.
s, advertisin
in th © Process of project ma
g and

7. nageme nt,
. New Toy
i For 5-9 year Olds

Te sarhar Broad ; Fron : i 2 15

aoa 16
poion — Developmen
7.1.1 t Pl
e anning
T
Focus | i 3
Groups] | | |.] | -
e 1.33..1
ign = "Bill of 1.4.4
=| Pro ductio 151
| . Design n: Marketi ;
ie Materials —
1.1.2 . Strategy
_ Surveys 1 1.3.2
“Initial Lao * ay 4.5.2
Production”
Prototype | | |. Testin Marketing
g | Plan
1.1.3
. Research 1.3.3 “ee
Analysis » Prototype 1.5.3 a
3 Testing Marketing
| Collateral
1.1.4
Market “| | p29]
}4 Concept - | sa- Prrod oe
Research » “Models + uction ° ai
< Findings Devel - | Brochures:
—
ae
> Sign-off.-
W230 0° |
«55 Sad | W5
.
32 0
Advertising
~~ Dasign
:
: ;
| Commercials
Fig. 3.6.2 : Example of WBS

f Benefits of WBS

1. Project budget and schedule can be easily calculated.

a darenhe impose
2 . : * . te

2. Helps for identifying the project risk in a given prejee

ject
3. | If project isi falling,
i the e wo: work breakdown structure can find out the major

3.7 Scheduling Technique —

of the field.
ws | project
ivities for - proje ini ct
any
the critical activities
Scheduling is generally one of £ distributes estimated effort across the
that distribu! —_
ing }is nothing but action
ect scheduling
- Software proj to specifiifc si oftware engineering tasks.
the effort
terval by allocating
planned project time

Scanned by CamScanner
 Project
3-19
EET somwara Enginoering (MU SO”. 6 - Comp) va ovol¥ os over time. .
stig

= Itis very importan t to note that, the sched relim: i nary stages of Project plang,
ic schedulo is developed h ‘ : Th | ee :
- ae always identifies all mainyap ll activities involved in the project, ‘y
macroscopic achedule is develo
schedule w: a, each task peg i _
on the feasted identified and schedu
— As the project procee leg, ty,
nits actions and tas
schedule, Here, specific 80! i n soft
ing techniques available in 60 ware engineering- \
. — There are two primary scheduling
1, CPM: Critical Path Method sawr Techniqtie.
2, PERT: Program Evaluation Review
3.7.1 Critical Path Method
with example, (Ff. sec. 3.7.1) i
[2.27.2 White meaning of CPM? Explain
i ie
- Ina project, various activiti
es are execu
ted in parallel by different teams,
a ot atart before another task
thers and hence cann ig - Followin;
{
7 For example, team A cannot
Rane aoliites are dependent itstaes connectivity unless team B updates the Same dy ; There ar
test‘ da
-
. . doc
01 umented, ? one can
When all the activities alo i
ng with dependencies are determin, & J _
that would consume the longest te a
duration. . - WorkB
, and her
~ Considering this longest duration, all other activiti
es can be executed in Paralle] With this ~ E -~
(An activity which takes longest duration to While;
complete). Critical Path is longest
activiti es in a project plan which must be completed metho¢
on time for the project to Complete é
date, mainte
~ Based on which logic has been use 2. Activity seq
d in the Project, some project
Some can have many critical can have one Critical path
paths, ~ Thee
~ Ifthe delay occurs in any - Follo
of the activity involving
the critical path then
the delay in the Project it will ultimately Joa
deliverables. If such o
condition occurs then
the project deadlines can be ach Te-sequencing ig done
s
ieved, °
- Critical path 18-
‘ con :
sidered as a method °
which is based on
used for the Purpose of. sch mathematica] calcul 3. Network¢
eduling Project activities, ations that
~ Critical path method was Once th
Corporati first j .
rporation and DuPont Corfirst introduced in 1950s as a joi_nt
poration, venture between Remingtonls|®_ 4. Estimate

~ Initially critical path method This is

Ww; ‘a8 used for Managing
plant maintenance Projec
- The original cri c ts
Identific
used‘ed In any project where :
interdependent activirs oe On project. Now the CPM
~ Inthe critical path method Vit ies are Inv olv ed 1
nD

Scanned by CamScanner
 - : ol
« Vit, |oP * Activity specification ved the Cpyy,
j - Work Break Do
a wn structure (WRg) ;
4 and hence it ig the main. S) is used ot ' :
PUt Of the =
to find out which activitj
] '
:
a
ity - While specifying the CPM. vities are involved in the project ,
.

ie activity,
method. If the detailed activits gene .
maintain, Fally the higher-level activities
€S are used, the CPM may h .
are selected for critical path
Q
“y Become more complex to understand and
2, Activity Sequence reorganization
The correct acti
vity sequence is reco
gnized
;Followin 8 are the
steps to recognize
the sequence of the
CPM :
|j Identitify .
the task that takes place before the
critical task happens,
o Identify the tasks that
should be completed at the
same time.
o Identify the tasks that should
happen immediately after critical
task.
3. Network diagram .

Once the activity sequence is identified, the network diagram can be

drawn. |
4, Estimates for each activity

This is the direct input from the WBS based estimation sheet.

5. Identification of the critical path

activity of the network.
- For this, + there is need of determining 4 parameters of each
d, one can start
1. Earliest start time (ES) — When the earlier dependent activities are complete

the earliest time of an activity.

+ activity time.
2. Earliest finish time (EF) - ES

Scanned by CamScanner
 3-21
n activity can be comp},
Bs. Engineering (M
u -
sem. 6 - Comp)

e (LF)- The ™
pat recent time of . “ted wit H P
Late st fin ish tim \ Software Ei AS)
3. ; 3 '
ect.
delay in the proj ratio
- activity du
sta rt time (LS) - LF cre
La te st et, ae
4. out paving delay in the Pr
5, Float Time -ES-LS cavity ean Dedelayed with
ork dingean te,
h of the respective netw
During the float time, an activity
ered as the longest pat the deadline
a 7
- The critical path is consid Iv cd in the cri
tical path on
ge, ‘
es invo ‘ect wil {Il also be delayed,
— There is impact of the activiti favotved
tivities
there is delay in an activity of this path, then the pro) j activt volved in the eg
. ds to gear UP the project,
ment nee! .
- If the project manage
should be reduced. — Numbered;
= Advantages of Critical Path Method — Directional
ect activities
_ Visual representation of the proj
- Diverging;
Tocalculate Project deadlines. ;
_ - Dotted lin
To track the critical activities.
)
3.7.2 Program Evaluation and Review Technique (PERT The Poss:
There ar
la.373 Explain PERT. (Ref. sec. 3.7.2)
PERT is related to management probabilities.

— PERT methods is included in many simple statistical methods. A PERT is a Project

technique used to plan, organize, and coordinate tasks during the project.

PERT is for Program Evaluation Review Technique, which was developed by the US, y
SS NAY
1950s for the purpose of managing the Polaris submarine missile program.
A PERT chart is a graphical re presentation
i of project network di i
numbered nodes, ~ “en - a 7
sa
These nod- represent events. The projectjact isi linked by the directional line which represents _.
isk in the Proje
project. The direction
irecti of the arrow on theé diagram represents the sequence ence offi .***™ ,
task. Th
re
4,8
2 T

are known as dummy activities,

For example, the e dashed

arrow between
nodes 5 and
4 is te Tmed as
dumm: yacti ty.
ivi

Scanned by CamScanner
 Estimates in
volved in PERT

semen; , 1. Optimistic Time Estimate (TOPT)

,
2. Most Likely Time Estimate TLKEDY |
mm the
3. Pessimistic Time Estimate (TRESS) -
; E ; Fig. 3.7.3 : Estimates involved in PERT

St of : - In this way, a range of time is given for each activity with the most probable value, TLIKELY.
g Following are further details on each estimate : °
the | $1, TOPT
: , : oe :
ms This is the fastest time during which activity can be finished. The assumption is made that all the
required resources are available and all the previous activities are completed as planned.

;: +» 2 TLIKELY
. ‘ ‘ 2 sas : iod. In
2 * Generally project managers are asked to present one estimate during the Init peal Pe,
that case, this is the estimate which goes to the upper management.

| * 3. TPESS ‘
44 to compleA telotan of activit
This is the maximum time ve-ed wrong, y. It is assumed that many thing
rework will need to do and resource
3 . ivit' go ‘ 2 Be tenes
related to project ar hen such estimation 1s derived.
unavailability is considered

a TTT

Scanned by CamScanner
 Project Schedutin,
3-23 Fite Sndy,
- Comp) 'e schedu
ea, |
a. software Engineering (N
[EP sotware Engineering (MU - Som_6Syllabus Top ic : Trac’
king th ON
Timeline chart

1. Planned tim
3.8 Tracking the Schedule
Actual time is
”
-
Tracking Schedule
Explain the term g. Forecasted t
(Ref. sec. 3.8)
h defines the tasks and milestones that are t, he he - Project
a road map ©
hic! 2.
hy |
The project schedule is signific
j
and controlled as the project procee! Ss.
:
- ‘With ¢
ber of difi feren t ways:
Tracking can be done in a num member repo ||
deadli
Ww!hich .
eac h team
li ally in
periodic i
i g pro; ‘ect
j status meetings
By callin
1. - Thee
i Pp rocess. and|
i ering
engine
the software
i agthe review s durin zs
by the scheduleq
: dat - Usu;
ve project
Setting th e ten tative deadlines that vi
have been. completed
3.

every project.
1.
start date for
the real start date to the intended
4 Compar in,ig
t 2.
5.
mt
Meeting can be taken informally with resources to obtain —_ ne on the
i

assessment. 3.
'

~ hni
Allofthese tracking techniques i
are used by experienced d proj
project managers.
= 4 | — With th
— If things are going well (i.e., the project is on schedule and within allocated budget, retin | show hc
progress is also going well and milestones are being reached), control is normal. — Its pos
But if the problems occur, project manager has to control them as quickly
as possible. After 3. Timel
problem has been identifi the
ed, additional resources may be focused on the proble
m areas, staff
be redeployed or the project schedule can be
changed.
my - Theti
— If the project manager ig facing with highh
deadline pressure, experienced
have to take the project managers someti |
decision about the project scheduli deliv:
ng and this control technique can
time-boxing. be called q

- Ifan
The time-boxing approa
ch identifies that the
whole product m ay not
predefined target. Henc
e, an incremental be deliverable by tk
schedule is preceded for soft ware Process is taken in
each incremental delivery, to consideration, andt

Syllabus Topic :
TimeLine Charts
3.8.1 TimeLine Charts

Q. 3.8.2 What are the Timeline char

ts? (Ref. seo. 3.8.1)
Timelines are very im
portant in
activities, organizati
on of task,

Scanned by CamScanner
 OO
pp sos Engineerin (MU Som. 8 - Comp)
3.24
Timeline chart helps to Visualize three Project Scheduling and Trackin
Main tj
1 Planned time Meframes ;

Actual time in-progress that shows ho 1

W long th

2 Forecasted time B Nhe tasks have heen in progress

-

. and e3 .
deadlines, charts, it is Possible to avoid low-quality releases as well as

The diagrams : add th e transpar, .

and plan the future, Parency and give a chance to analyze what happened in the past
Usually, managers
use timeline charts
for : )
1. Projects and tasks planning :
2. Road mapping

3. Task management

With the help P ofof timeline

timeli charts, users can plan many targets to be achieved on one screen
and
show how they can be connected with each other.

- Ite possible = compare planned and actual end dates and get forecasts.
3, TimeLine Components

- The time line components are the diagrammatic representations of the tasks. Timelines may be
highly detailed or simple. They can contain hundreds of tasks and subtasks or have only a few
deliverables. a

- Ifanyone want to build a timeline to their goals, they have to pay the attention on following :

1, The set of tasks and objectivesto be completed;

Approved dates and deadlines,

BK

Dependencies between tasks,

-S&S

Expected duration of tasks.

Chart.
- Timelines are in many forms, but the most popular and powerful option is Gantt
n of tasks. It really provides an
- Gantt Chart includes horizontal bars which represent the duratio
easy visual depiction of the project.

© Purpose for the TimeLine Charts

ure everything is planned properly and runs according to given
- The main purpose is to so make 5
schedule.

Scanned by CamScanner
 Project ;

¢-cone} 3-25 7 people. It doesn’t ; S24, a software Engineering |

. - Sem. 6- . ving mam Insigg
EEF sotmare engineering (MU projects ha Toe i Key Elements of E
_ Timeline charts these both di 9

time or much effort to form 2 O°" of the Gantt charts *© “hy 1. Pisnnealy
— Online project timelines are same 2° \ The allocat
ne events. " Scheduled|
| concerned with time and “Earned Value ‘Analysis i
{ Syllabus TOPIC: oo ‘\ 2g. EarnedV
i The budg
3.8.2 Eamed Value Analysis = eae Work Per
in
0.3.8.3 Whatis Eamed Value ” 1 in Project Management. 3. Actual
— Earned Value Value Analysis (EVA) is the key techmave sect isi progressing.
understand how the project ‘ The e acti
‘The purpose of Earned Value Analysis is to and ge . , of Work
earnings or money
=
of a pro jec t ba se d on
— EVA used to estimate the progress @ Tools and te

f ss’ to evaluate ‘Percentage ofComp There are :

calculated on the basis ofEVA
measure 0 ‘Progre:
is a ue leteney 1. Schee
— Insimple words Earned Val

3.8.2(A) Features of EVA a i 2. Pilani

— Earned Value Analysis’s objective is to measure project performance 1n terms of scope, Cet | 3. Risk

jo 4 time. : FE 4. Win
f 5. Pri
_ EVA is used to evaluate project health and project performance. o@ Earned |
— Earned Value Analysis is also used for monitoring the progress of a software project / team wij,
involves tasks allocated to the Project Schedule. - Ce
— Total time required to complete the project is calculated and each task is given an Earned Val ei
based on its estimated (%) out of the total. _ .
: fi c
3.8.2(B) Need for EVA :

- EVA provides the measures of project process of different tasks associated with project, so itiss Stey
single way of measuring each and every point in the project. Fro
- It also provides a signal for corrective action in the project. The types of signals can be the 1.
following :
. . 2
1. Time to recover 3

If the project is not going as per plan and it is found that there is some delay in the projet: 4
Then at this time, situation is needed to be taken care
by finding out the reasons that at
causing delay and by taking the required
corrective actions.
2. Request for additional funds/resources

While there is i time to recover, the need for extr

a resources or money can be calculat
. an early warning. ed wit

Scanned by CamScanner
 .
f, i ineerin, My. Som
S log
"Key ts
Elemenof Eva a
e,
7 1. PL anned Value
The allocat
ed cost
Scheduled (BCWs) for Project
whi
ch ig ®Pproy,
3. Earned Val ue
Sa. Tt wong known,
The bu ak fa Dudgeted Cost of Work
dgeted value of
Work Perf
OFMANCe at a y © “ompleted weil
gs. Actual Cost (Ac)
ted poi
Point (BOWpPack,
, ». 8 It used
to be known as Budgeted Cost of
_ of

The actual cost involveg dus

of Work Perf uri; :
(A ng the ex
“Sution of project worl. 1 t was
ormed
S
are a Tools and techniques CWP). previ .
ously called Actual Cost
Rss? There are several software packa
1. Schedule maker Ses available which are li
listed are as follows :
2. Planisware OPx2

nd 3. RiskTrak
4, Winsight
5. “Primavera
= Earned Value Analysis — Exampl
e

- Consider
:
you are han dling as oftware development project. The pro} , :
eight months with costin project deadline of the project is
g of $10,000 per month

- After two months

work is thirty peromt connie Te
» you get
the neproject
costing of $40,000, Now ew) ve need to detetermi whether the status of project will be on-time
and on-budget after two months,

Step 1: Calculate the Planned Value (PV) and Earned Value (EV)

From the scenario,

00 * 8 = $80,000
1. Budget at Completion (BAC) = $10,0

2. Actual Cost (AC) = $40,000 xy

= 25%
3. Planned Completion = 2/8
30%
4 Actual Completion =
Therefore, * $ 80,000 = $ 20,000
C om pl et io n (%) * BAC = 25%
Planned = $ 24,000
Planned Value BA C = 30% * $ 80,000
on (% ) *
= Actual Completi dex (SPD)
" Earned Value d Sc he du le Performance In
(CPI) an
Performance Index 000 = 0.6
Step 2: Compute the Cost = $24,000/ $40,
$20,000 =12
= $24,000 /

Scanned by CamScanner
 Project
3-27 andy
/ EEF sotware Enginorng (Muy
- Sem. 6 = COMP) (CPD is less than one, this mean, the
f f <« erformance Index
veenet te pace ann we are getting 60 cents’ worth of Peremanse, “Pig,
_ Because SPI (Schedule Performance Index) is more than one, the Pre *S considered ..
a
| schedule. i
at the
budget. If work is continue
| — However, this gets achieved at a cost of cro ssing the budge, as
but it will be over
rate, the project will be definitely delivered before deadline
H f is need of corrective measures.

ii — Besides computing the CPI and SPI, it is possible to caloulate the earned value cost ang
variance. Additionally, earned value forecasting formula. ss —$_

Scanned by CamScanner
 Design Princi
ples, Design
Concepts Ef
Component-leve} des; fect;
ign, User Interface Design.iva Modular Design - Cohesion
and Coupling, Architectural Design

4.1 Software Design

vare Desi LS
- Once the requirements
document regarding the
(5 Marks)|
of software design software to be developed
gets started. is presented, the phase
- Th

In the design phase, all the

relevant entities such as the custo
mer, business requirements and
technical consideratio ns collaborate to formulate a
Pp roduct or a system.
In design process there are several
elements such as set of principles, conc
epts and practices,
which help a software engineer to mode
l the system or product which is to be
built.
The design model is assessed for quali
ty and reviewed before generation of code and
execution of
tests.

The design model gives detailed information

regarding software data structures, architecture,
interfaces and components which are necessary
to employ the system.
7 Basic of Software Design

- Software design is considered as a phase in software engineering

which develops a blueprint that
will be a base for constructing the software system.
- IEEE defines software design as ‘both a process of defining the architecture, compone
nts,
interfaces, and other characteristics of a system or component and the result of that process.'

- In the design phase, important and strategic decisions are made to get the expected functionality
and quality of the system. .
These decisions are considered to successfully develop the software and handle its maintenance in
a way that the quality of the end product will be improved.

Scanned by CamScanner
 SS,
practi s t},,,
ss -ooiples concepts, and d practice yiP
~ ker - Sem 6= comp)
EE! Sottware Engineering (MU » i
the set of pr Software
{twas Eni A - Sen,
° Software design encompasses ystem orproduct.
— Vv
development of a high-quality § od before the desig? prac
tices are applied. 3 =
rp, ~ A design shoutg Ontain
und ers to entations of the softwa components,
Design concepts must be
res
. — tion of v: rious rep
| s to the crea ty that follows.
Design practice itself lead uction activi
4.
Hl
—
e as a guide for the co ns tr
; 5 “anddesign should lead tg a
ign Practices serv tures, architecture, are drawn, from
- Des
> inter, |
odel provideides
:
data struc
details about software stem. haei 5. A design should 1, ead to
— The design model . ;
+ plement the sy’ design manifest lS
components that are necessary to 1™P nia? in Dea “i| 6. A design should
are
its Kapor, por, the the c creator of Lotus 1-2-5, presented a “softw
. : tead ty
= and with the ex,
\ Tal ey
i | Journal. 7. A design thoula —
design should exhibit :
~ He said :! Good software bugs that inhibit its function. during software requ:

ances
ram shoul d not have any nd,
A. Firmness : A prog ich it was inte 8. Adesign should be rey
j purposes for wh
.
be suit able for the
B. Commodity : A program should
t {

|
rams hould
be pleasurable
one.
AAA of Good pe
Qualities
~| C. Delight : The experience of using the prog
lo. 4A2 Explain
Software design model consists of 4 designs

nen
There are number of gu:
1. Data/class design 2. Architectural design

3. Interface design 4. Component design

f

Component-
it: ” Scenerio-based — Flow-orinted = Level Design
“elements elements
ty
- Use cases - text Data flow diagrams
; Control-flow diagrams
| Use-case diagrams
Activity diagrams Processing narratives
'
Swimlane diagrams

ft Analysis Model.

Class-based) Behavioral
elements elements
| : Class diagrams State diagrams “> (1) Innovative
Analysis packages ° _| Sequence diagrams .
CRC Models — Innovative d
i Collaboration diagrams Design Model
| - New design
product.
Fig. 4.1.1 : Translating Requirement Model into Design Model _
=> (2) Functiona
@ Design Guidelines
Good design |
1. Adesign should exhibit an architecture that : product by of
(a) Has been created using recognizable architectural styles or patterns, > (8) Honest
(b) Is composed of components that exhibit good design characteristics and A good des
(c) Can be implemented in an evolutionary fashion! attempts to

2. A design should be modular; that is, the software should be logically partitioned into elem"
subsystems.

Scanned by CamScanner
 (5) Correctness

Fig. 4.1.2: Qualities of

good software design
> (1) Innovative

Innovative design can be either completely new

design or redesign of existingproduct.
New design gives unseen value to market where as redesign improves the quality
of an existing
product,

> (2) Functional

of a
Good design fulfils all its intended functions to solve user's problem. It focuses on usefulness
product by optimizing its functionality.

“> (3) Honest

honest design expresses the functions and values it offers. It never
A good design is honest. An hon keep.
view with promises it can’t
and User's
attempts to modify Organiser’s

Scanned by CamScanner
 Soy Wang
;;
ed

j > sonware . . (mu - Sem. 6 COMB), i ET sonar inoer

i olution to .
(2 _soteore Sraroerng
: > (4) User - oriented oh * D ded to improve § Probj eT by } - Methods rep
° a its vse-and inte y new technol
i : ~ Good design is developed bas
system which intory
te:rial value to for the Proc
i ! }
{
user.
. ell as ma Ach: :
— User-oriented design gives intellectual 45 ‘tay — However, ¢
: ;
; user’s satisfaction. : the same."

> (5) Correctness ign should correct ly Ahiey :;

ion. A good design
~ Correctness is an important quality of go d desié®
required functionalities as per SRS document. <
c :Design Pr
inci ples _—o\
Syllabus Topi

4.2 Design Principles

b [a.4.2.1_Whatare the design principles ?_ (Ref. sec: 4

t
| Following are important design principles :
‘tunnel ie
1. The design process should not suffer from
2. The design should be traceable to the analysis model.
3. The design should not reinvent the wheel.

it exists in the real world. .

y 5. The design should exhibit uniformity and integration. . 1:
j 6. The design should be structured to accommodate change.
7. The design should be structured to degrade gently, even when unusual data, events, or operat |
conditions are encountered.
8. Design is not coding, coding is not design. ;
9. The design should be assessed for quality as it is being created, not after the creation.
10. The design should be reviewed to minimize conceptual (semantic) errors.

Syllabus Topic : Design Concepts

4.3 Design Concepts

43.1 ngs of
With reference to sofware desian gv the meanings

ct . . , }
- All of the software processes are

practices or methods,
by basie concepts in conjunction
with sot

Scanned by CamScanner
 are aq .
Tin Pplied,
are, | Me methodg no" p,© Id
ich te, chnology i
is replaced by
6 Used to
apply the concepts

——
Fig. 4.3.1; Fundamental :
design concepts
+ (A) Abstraction ee

9-4:3.2 Explain folowing with reterence to design concep eae e

d
(Ret. 800.430)
Abstraction refers to a process by which software designe
rs consider components at an abstract
- level, at the same time as ignoring the implementation details of the components.
.
- IKEE defines abstraction as ‘a view of a problem that extracts the essential information relevant
to a particular purpose and ignores the remainder of the information.'
- There are two ways to use the concept of abstraction; as a process and as an entity. , bi
details and
As a process, abstraction refers to a mechanism of hiding irrelevant extra
an element so that one can concentrate on
representing just the important essential features of |
l th in gs at a tim e.
essentia
ty , ab st ra ct io n ref ers to 2 model or view of an item.
— Asan enti traction.
all the ste ps are ac co mp li shed via several levels of abs |

- Inththee soft w re , process

softwa :

1, ne

Scanned by CamScanner
 LF soma 4-6
engnorng =e ; <e,
Core) ;
~ For example, in the requirem . 0, language i s used to provide a gay.
ents analysis es process, the abstraction levey tion
problem and as ono proceeds during the so tovel. Meda ay some en
source code of the software is gene lowest.
rated at the ftiwaro design are functional a) %
Tn general three abstraction mechanisms used in 80 Petraes - Sof
abstraction and control abstraction. “ty
reg
as b y Startino
design process
These mechanisms help to control am
the complexity ain tashacii
syst
tleeemat1d
ic mann
abstract design model and onding at concrete design m ane er,
at Sy ‘ - Th
1. Functional abstraction de
: This type of abstraction
subprograms, Functional as ‘a set. ofsubprograms
abstract ion can. be created isible or inv -
At
‘eroups'. In these sets, routines
are exist which may be vi isible .
The a F

mom
routines can be done 2.9 ithin other = ~
within the containing e
invisible routines are hidden from other groups eee oe used in the
groups and are
group only,
spina .
Data abstraction : This type of abstraction includes deser
ting ata vey te
object. For example, the data object flower
which describe the flower obje
encompasses a set of atts wn fra
ct clea . In rly. this abstraction mechanism, TSPTESEDtatin |
well as manipulation details are ignore
d.
3. Control abstraction : This type of abstraction states
the desired effect, withoutSaag,
the exact mechanism of control, For example,
in programming language like C, ifeng
statements are abstractions
of machine code ay
implementations
instructions.
containing Condit

> ©) Information Hiding

It is important to specify and design mod
ules in su ch a manner
that the data structures swe
proces sing details of one module sho
uld not be accessible to any
other modules,
Only required informati
on is transferred be tween
the modules. The way of hiding
details is referred to as
inform ation hiding.
unnerssey

8 as ‘the technique of encaps

ulating software design dec
isions: |
ible about the modes:

Advantages of information
hiding
Results in low coupling.
Put emphasis on communication
by controlled interfaces,
Reduces the Possibility of adv
erse effects,
Controls the impacts of changes
in one component to others
Results in higher quality software.

Scanned by CamScanner
 3 a th TOgram/ g. of th
stem, the Attributes ( be,
_
inoO which Conaiate of several
2mMe d . Software {rchitecturg h evera
ky "ey - esign Proficiently , elps the Software o ie “mPonents and the scien s
, ship
2 of a .
Visi,
Ps, " le

S a dat,

i)
tion ag :

Ict;, r
;
While ,
nay

ag i 3

y ;

| - The Pp proces
rete izingi aa desi
amnens design helps : to plan the development in a more
| = changes without difficulty, conduc efficient way,
t testing and debugging effectively
: efficiently, and carry out the maintenanc as well as
e work without adversely affecting
the functionality of
the software,

Example

The ubiquitous television set is an example of a system made up of a number of modules

—
speakers, projection tube, channel buttons, volume buttons, etc.
- Each module has its own defined functionality but when they are put together synergistically, the

complete functionalities of a television are realized.

> (E) Concurrency

- It.isis iimportant to utilize the resources efficiently as much as possible. For this purpose multiple
tasks must be executed concurrently.

Scanned by CamScanner
 Sottrar, |
4-3
are design. 1 .
eS Software Engineering (MU - Sem_6- cone) ; portant concepts of sof ays : Z som
e of the impo hat it should facilitate multip}.Proc, a
ut|
ncy on
This aspect makes concurre sn ouch 8 manner thi
igned
— Every system should be des
execute concurrently. ie =" waiting for some resource, the System tng
- For example, if the currently ¢x' ecuting
the proce
mean \
time. \‘
able to execute any other process 10

> (F) Verification ini

ofthe c onfirmation by examining
‘fi ane d giving
giving ey;
vidas
— Verification is described as a anism cations.
design input spec
there is no mismatch in design output an¢
performance req
ju irement which is used ag the ne,
— Design input can be any phys ical as well as
for the purpose of designing. ;
efforts. The final design Ot,
Design output is considered as the result o f all the design phases’ :
is a basis for device master record.

> (G@ Aesthetics

{
Aesthetics is the philosophical study of beauty and taste. es oth f
'
a
— Software engineering is a largely creative design discipline, where new ns Braphies \f
tt
design models as well as code) are created from scratch. '

Compared to art, there are many targets (e.g. desired functionality) and ee a (e.g. deg,
quality attributes) that the software engineer must adhere to, but these s leave alms
infinitely many ways to create a model that fulfills all those requiremen
ts. 44
~ In addition, for essentially the same model, there are many
ways to represent it. Since Model |
and code must also serve to communicate ideas to other people (or
to the same people months ¢
years later), the chosen structure and representation are
key attributes for the success of the |
product. ; | '
~ It's a well-accepted hypothesis that the
aesthetics of the artifacts produced
development are an indication of 'the quality during softwar j
’: it is very common to.comment on
‘beautiful’ or “elegant”. designs as being |

~ Such &|
a qualification is used to indicate
the apparent quality of the design.
an intuitive connection between Apparently, we make |
aesthetics and quality.
;

4.4 _ Effective Modular Design

laaas x Write note on effective modular design,

(Ref. sec. 4.4)
(10 | :
~ Modularity can be defined as dividin
& the software into distin: -_
components, which are also called as modules to distinctively Tamed and addressab et
- Acomplex system (large Program) is divide
d
module can be developed independent of otherinto a set of distinct Modul L
modules es in such a way that ea? 3|
y
ET

Scanned by CamScanner
j
! 1. Maintaining smaller
components is very
easy

e b ed.
As per the requirement, the
ad

level of abstraction can be carr

ied out in the program.
4. Components with high cohesion can be
re-used again.
Concurrent execution can be made possible.

6. Security can be achieved.

Modularity has become an accepted approach in all engineering disciplines. A modular design
reduces complexity, facilitates change (a critical aspect of software maintainability), and results
in easier implementation by encouraging parallel development of different parts of a system.

4.4.2 Functional Independence

. sec. 4.4.2) Se AS Marks)

e on fun cti on ind epe nde nce . (Ref
lo 44.2 : Write not
sid as a direct outcome of the modularity and
e concept of functi
Thhe
‘t onal independence is con ered
n hiding.
as well as informatio
the concepts of abstraction

Scanned by CamScanner
 | LEP sottwa re Engineering
ngineering (MI U - Sem. 6 - COMP) aby che process loping
of developing mod 08 wawith
modules « PAT software’
Ca

— Functional independence is implemen . with other modules, "in,

an “a version” with ¢ r eme communication
Sah
minded” function and at each module, is Concerned
we nee d to design software in order : =~
In other wor ds, interface when seen from
s and pos ses 0 ly one
ent
| particular sub-function of re quirem
;
parts of the program structure.
I. t. Software having effic
ient 1m, rt,
— Qne good question is tha t why independence is impo;rtan tings ,
ce function may be compartmenta
i
staat i s si develop sin
#i that is, independent modules, is simple to .
ramifications when
any
, team nda,
4 simplification of interfaces is done (consider the process of ca! a
+
y
; development). .
: : there is limitation jn
| — It is simple to maintain independent modules (and test) since
i effects which are generated by design or code modification. Als o there is reduction ;
In ep
;

propagation, and possible to reuse modules. => (i) |

a - Asa result functional independence is a key to good design, and in turn the respective design i -
the key to good quality of the software.

i — There are two qualitative criteria to measure independence : cohesion and coupling.
, => (ii)
Cohesion is used to measure the relative functional strength of a module where as coupling i
ij used to measure the relative interdependence in between modules.

: Syllabus Topic : Cohesion 2 -

a, 4.5 Cohesion Oo : > «

> (MU - May 15, May 16, Dec. 16, May 17, Dec. 17,
May1i}
ee ; What is cohesion? Exp 4.diffe Bs =

(Ret. sec AB} go 2

>

Q.4.5.2 Explain diferent types of cohesion. > qwv-Deo8

(Oe a ae Ee L

'
#

Scanned by CamScanner
 * (iii) Temporal cohesion

= T em po: ral cohesion

occurs WwW hen component 0} fa sy stem perft orms
rm: more than one function and

- Itis generally found in initiation and termination activities,

% (iv) Procedural cohesion

When components of system are related to each other only by sequence then there exists
procedural cohesion. .

cohesion.
i - Loop in programming language is good example of procedural
+
(v) Communication cohesion
.
2
: >
accepts same input and
rm different functions but each function
- elements of module perfo
When _ ational cohesive.
module is sai d; to be communic
ame output then that
—— rnative is easily found.
table if no other alte
It is sometimes accep

Scanned by CamScanner
 er Software Engineering (MU - Sem. 6 - Comp) 4-12
>
(vi) Sequential cohesion
A mi module is said to b sequentially cohesive ifans its func tions are re lated in a way such t
© 18 sai ‘hat
ie
r function. “hy
of one function acts as an input
data to othe
This type of cohesion is easil7 y intainable
maintaina .
> (vii) Functional cohesion
Ifel :
_~ elemen
ts of
of mo
module are grouped together since
e
they contri ibute to a single function the n
module is functionally cohesive module. a
afal execution of function.
All elements of such a module
are necessary for succes
.
4.5.2 Advantages of Cohe
sion
(i) High cohesion among system comp .
onents results in Better progr ‘am design.
Gi) High cohesion components can be easil
y reused.
(iti) High cohesion components are
more reliable.
4.5, 3 Disadvantages of Cohe
sion
(i) Low cohesion components are diffi
cult to maintain
(ii) Low cohesion components
cannot be reused.
(iii) Low cohesion components are
difficult to understand.
(iv) Low cohesion ‘components
are less reliable.
‘()
Syllabus Topic :Coupling , =
4.6 Coupling _
> (MU - May 15, May 16, Dec, 16, May
17, Dec. 17, May19
fi 4.6.1 What is coupling? Explain different forms of it, :
‘L_____ (Ref. sec, 4,6) Bis eames:
lattes

— Highly coupled compon

ents are more depend
ent on each other wh
are less dependent
or almost indepe
ereas low - coupled comp
onents (ii
ndent on each o
ther,
Good design always ha
ve low coupling betw
een components of sy
Example, stem,
© |

Scanned by CamScanner
 .
Te high} her Modulg Ot doesdepeng
n, . om 8ny other eninge,
other modul y
n such a es or com i ect Modules M2 and ent for their fonctions,
my.
One of the Solutions Pon,
ei
— Ingeneral, in system a luce Coupling be
€velo .
4.6.1 Types of Coupling Pinent coupling j ™Ponents is a functional design,

Coupling types Dec. 15.5 Marks

Data
Coupling
Coupling Stamp
Coupling Coupling
. Control Concent
Coupling coupling Message
| Coupling
Fig. 4.6.2: Coupling
types
(i) Data coupling

Data
a’ coupli
. ng e occurs phan 2 two components
of system when they pass data to each other
parameters using argument list and by
each element in argument list is used.
- Acomponent becomes difficult to maintain if too many parameters
are passed.
18) (ii) Control coupling

- When data are passed between two components and that affects internal logic of a component
then there exists control coupling between those two components.

- It passes the control flags between system components.

|
(ill) Common coupling
ling components of system
al coupling since in these coup
Common coupling is also called as glob .

.
h other by using global area
.

communicates with eac

°

- .

d.
data in global area is change
difficult to track when
- Common coupling becomes |
(lv) Content coupling | e two components |
te rn al s 0! f th e ot her component then thos
to the in
i
onent refers a
When one comp
ent coupled. not be used in
designing,
; i ng it sh ou ld
of coupli
e eco upa: li ng is Wo’ rst type
- Asco ntent

f
ee
TE
TTT
epee

Scanned by CamScanner
 Software Engineering (MU - Sem. 6 - Comp)
EP sotware En,
414 Software
(Vv) External coupling TS
5
If two components of system share an externally imposed at, communication
device interface then they are said to data format, Protocg} or
be externally coupled.
- External co upling refers
to communication between system components d external
devices, an tools o
(vl) Message coupling

Message coupling occurs be tween

two components of systeni when those component,
communicate with each other via messa
ge passing.
In this coupling components are independ
ent of each other; thus it is low type coupling.
(vii) Stamp coupling
Stamp coupling
occurs between
two co: mponents of system when
arguments using data between them are Passed by
a data structure con taining elements
Stamp coupling which may or may not be used.
is also low type
cou pling,
4.6.2 Advantages of Co
upling

Scanned by CamScanner
 : ing the archi : :
which software can be:develope tectural design which acts as an initial blueprint’ from

IEEE described archite ctur: i

components and their inte design as a process of defining a set of hardware and software
7 m. This fr : aces to set up the framework for the development of a computer
— S iramework is established by observing the software requirements document and
designing a model for providing implementation details.
These details are used to state the components of the system together with their inputs, outputs,
functions, and the interaction between them.

Architectural design can be represented with the help of following models :

an ordered collection of program
1. Structural model : Demonstrate architecture as
components. ~-
architecture
mode l: This mode l illu stra tes the behavioural aspect of the software
2. Dynamic changes
str uct ure or sys tem configuration changes |as the function| |
and sh ow s ho w the |
thel extern
in de
geis mo al environment.
beca use.of thodeelch:anTh concentrates on the design of the business or technical process,
:
3. Process model: sy st em . |
plemented in the
which must be im e fu nc ti on al hierarchy of a syst
em.
signifie s th
n c t i o n a l m odel el:: This model
4. F u

Scanned by CamScanner
 EET sormare Engroning Sates
san. 6- Com 4-16
table architectural design
5. Framework model : This model . recogni
a

a : wil results in increase in the levey

which are found in same types of applica’ tions. ¢
abstraction.

4.8.1 Functions of Architectural Design

. a
1. It describe an abstraction level at which the functional an Performan,,
designers can state the fun’
behavior of the system. °
2. It estimates all top-level designs.
. of th
3. It acts as a guideline for improving the syst P : ose features e system tha,
em by illustrating those feat
can be changed easily while maintaining the system integrity. _

4. It develops and documents top-level design for the external and internal interfaces.
5. It develops initial versions of user documentat
ion.
4.8.2 Architectural Design Document

The result of architectural design process is Architectural Design

Document (ADD).
This
document contains a number of
graphical representations that encompasses software models
along with related descriptive text.
- The software models consist of stati
c model, interface model , relationship
model, and dynamic
process model which illustrates how the
system is arranged into a process during
run-time.
Architectural design document
provides the dev elopers a solution to
the problem defined in the
Software Requirements Specificatio
n (SRS).
In addition to ADD, other outputs
of the architectura l design are given below :
1. A range of reports including
audit report, progres: S report,
and configuration status accoun
report. ts
.
2. Different plans for detailed des
ign phase, which consist of fol
lowing: ©
(i) Software verification and validatio
n plan,
(ii) Software configuration
management plan,
mc) Software quality assura
nce plan,
(iv) Software project manage
ment plan.
4.8.3 Architectural Style s

- Architectural ‘styles descri

be a set of Systems
which are internall 3 . ;
share structural and semantic properties y linked with each other and

Scanned by CamScanner
 : ,
‘able archit, different style-spe
: = cific analysis
a Sty], sant ig “
- Every . =
e Style lee
fines a syste Part of this Syst: em) ) di ©monstrates one of the
1 . ComSeh
putite
at; onal co several

system function m™,Ponents like ™m

type that;
clients at includes the following .
2.

Fig. 4.8.1 : Architectural styles

> 1. Data-flow Architecture

into the required
is to accept some inputs and transforms it
- The purpose of data-flow architecture
uence of transformations.
outputs by applying a seq transformed data to other
e
ed as fil ter tra nsf orms the data and sends this
- Each component call help of the co nnector
called as pipe.
pro ce ss in g wi th the
filters for additional th at is, it is n ot focused
on the filter which is
de nt ent ity ,
ates a5 an ind epen
- Every filter oper .
nsuming the data to the other end.
generating or co tr an sf er s the data re ceived on one end
annel w! hich .
r e ctional ch the filter on the receiver end
- Apipei s a u n i d i it just delivers the data to
in anyway;
no t ch an ge the data
It does

Scanned by CamScanner
 (a) Pipes and fitter

CFinor)-+(Fiter))-+FoCitor
Fitor))
(b) Batch sequential

Fig. 4.8.2 : Data flow architecture

~ Most of the times, the data-flow architecture reproduce
a batch sequential tial system.
sy :
j - In this system, a batch of data is acce
pted as: input and then a sequence
i:
applied to transform this of sequential filters ate
data.
Example of this architecture is UNIX shell programs.
In these programs, UNIX processes act as filters and
communicates act as pipes.
the file system by which UNIX Process

iiHe | * Advantages of data-flow archit

ecture
Het . 1. It Supports maintainabil
ity, reusability and mod
; j ifiability,
2. Concurrent execution ig sup
ported by this style.
ii 7 Disadvantages of
t :
data-flow architecture
/

3. Tt 18 Not easy to
coordinate two dif ow architecture.
> ferent but related
2, Object-orienteg streams
Architecture
- In this architectural
Style, the componen
which are used ts of a System
to change the data wrap data and operatio
, ns into single
— In this style co unit,
» mponents ‘are
reprec. Presented as obj i
through methods (conne ects. and th
ctors), i
wr
Characteristics of obje WY SOmmunieate with
i
.
ct-oriented archit ecture each oe
1. Objects Preserve
}

the integrity of
-

the system.
2. An object is not aware of other
objectg’representation

= 3

Scanned by CamScanner
oR
S Lltway
a)

Software En, !Noorin Mey

5 0
Tr Advantages °F object
0; rl
1, It allowg design

NE a wel] d
efined
here ey, ry layer ig builtset of operations
one ime

it,
A data-centered architecture has two
unique components :
1. Central data structure
2. Collection of client software
A central data structure is also known as data store.
The data store such as database or a file demonstrates the current state of the data where as the
etc. on the data which is
client software performs various operations such as add, delete, update,
stored in the data store.
of any
Sometimes the data store permits the client software to access the data independent
tware.
ons of other client sof
changes or the acti

Scanned by CamScanner
 LE sonware Engineering (aU «Sem. 6 Come) 4-20
ted to clients can be addeg

y
~ In this architectural style, new components
nents can
can be changed
a change in other clients, a
components easily which does
thoutnotdepending other com Ponents,
upon any
~ This is because client components work wi ‘
ystem in which the data store jg tra ry
A variation of this architectural style is okt the data ia modified,
-
into a blackboard that informs the client ftware
so! :
Additionally,
nally, the the inform
information can be transferred between the clients with the help of y,
components.
- 2 Advantages of the data-centered architecture
1. Data repository is not dependant of the clients
.
2. Clients work independent of each
other.
3. Adding new clients can be
easy.
.
4... Modification can be very easy.
5. It accomplishes data integration in compo Bp R
nent-based development with the help of
blackboarg

Fig. 4.8.4 : Data-centered architecture

> 5. Call and Return
Architec ture
— Acall and and return
arrchi chitecture allows
modification ig ea software designer
sy, s to get such a
Program structur
e wher
This architecture
style containg foll
owing two sub-styl
eg,
A. Main Program/subprogram architec
ture

Scanned by CamScanner
 In this style,
componen:ts of the Main
petwork acros S$ num
ber of Computers which
eqogr
c £an he accessbpr — am.archi are distributed over a

designs are completed.

- The software is
desi bo revi TEP resented by the component-level design in such a manner which lets the
gner to review it for correctness as well as consistency prior to its built.

- The work product generated is considered as a design for all of the software components. It is
represented with the help of graphical, tabular, or text-based notation. :
transformation or control
- Design walkthroughs are carried out to observe accuracy of the data
the components in the earlier design steps.
transformation which has been allocated to all of

® Component Definitions
encapsulates
a mod ula r, dep loy abl e, replaceable part of a system which
- A component is
poses @ set of interfaces.
implementation and ex labor ating classes
vi ew @ co m po ne nt contains a set of col
ted
— As per object-orien du le ) re si de s in the software an
d serves one of three,
a component (or mo
- eetraditional view,
As per
roles as follows :

Scanned by CamScanner
 4-22
keep Software Engineering (MU - Sem. 6 = Comp)
vate coordinate invocation of all other problem domain componens as
G) Canine e functionality needed to the custome,
mponents implement th
required to bog
implement the functionality
7 vchaucamuen anaes
ain application.
processing needed in a dom

+
ding system 3 out of existing components which
- Process-Related view focus on buil
from a catalog of reusable compon
ents as a way 0 f populating the architecture. me a “they
oe
* Object-Oriented Component Design
— Put emphasis on describing the domain oriented analysis classes as well as the deta
«
infrastructure classes.
— Comprehensive information of class attributes, operations, and interfaces ig Mecessary
activities. bel, L
beginning construction

= Principles for Designing Class-based Components

j — Open-Closed Principle (OCP) : Extensions should be allowed in the class but not Modification
— Liskov Substitution Principle (LSP) : It should be possible to substitute subclasses for the;
classes. or bay L
~ Dependency Inversion Principle (DIP) : Depend on abstractions, do not dep
end on concretions
Interface Segregation Principle (ISP) : Multiple client
oriented interfaces are considered ag
i compared to one general purpose interface.
; ms
Release Reuse Equivalency Principle
(REP) : The granule of reuse is the
granule ofrelease | .
Common Closure Principle (CCP)
: Classes that change together belo
ng together. .
en
Common
n Reuse Principlele (CRP) ) : Cla
sses that can't! be used togeth
er should not be Grouped :
ee
Component-Leve! Design
Guidelines
-
1. Components
,

For the Purpos

ouienr ie e of consi istency, th
‘
© flow of interfaces should be from
ae the left-h and d sidsidee ofof th the

Scanned by CamScanner
 to Tef],
Combineg jt SPetic be havior oF state,
- Sequentigi
- ‘ i
ton : ut Pass; 4 gro UB to let °
Cohesion . Qo tions hn Ssing data, ne be called immediately er
e

Content coupling : This coupling takes place

once one component secretly makes changes in |
internal data of another component.
- Routine call coupling : This coupling takes place once one operator is invoked by another
component.
- ype use coupling : This coupling takes place when a data type defined in one component is used
by another component. .
3 . ‘ng : This coupling takes place when one component imports a package
- Inclusion or import coupling : 1018 ¢ |
or uses the content of another component.

Scanned by CamScanner
 EEF sonware enginoaring (MU = Som 6- C20) 4-24
8
*" Conducting Component Level Design hich are corresponding to the problem domain,
serra SeeSe,
- Program Design Lang,
1. Identify all of the respective a ee classes
classes whic!
which AT ae
to the infrastry details,
2. Identify all of the respective des ae
g reusable co
mponents ; a | program Design
ar Pr Language
3. meee
Elaborate all of the design classes which are nen
not there
acquired & ion n of of classes
is collaboratio clas or Components » Predetermine= oni
a. Specify details regarding the mess: age W! constructs, dex|
nts.
b. Identify suitable interfaces for all the comP? ne tructures which are necessary » 7 Resemasof nat
e Elaborate rate ai attributes ‘s and define data types and data $ % the, - Data declarationf
implementation. : F 7 Subprogram defin;
d. Describe processing flow of all the op erations thoroughly. :
tabases and d files
fil and r A
4. Make the Identification of persistent data sources such as dat : ecognize the
on Modularity = Net
classes which are necessary to manage them.
‘the classes‘or components. -
7 e — Overall simplici
| 2 SeSiaalea . rs a implementation d e
dditional — Ease of editing:
6. Elaborate deployment diagrams for the purpose of providing a! | . ‘al, — Machine reada
representations and consider alternatives, oe
7.AL levi diagram
Factor all of the com; ponen t-level agr / — Maintainobili
= Object Constraint Laniguage (ocL) procedural de
— Complements UML by permitting a developer to use formal grammar ass well as Syntax for the — Structure en}
Purpose of constructing unambiguous statements regarding design model element. — Automatic p
— Parts of OCL language statements: ‘
, = Data repre:
1. A context which indicates the restricted situation in which the statement is considered a, » =. Logic verif
valid. :
— Easily con
2. A property which represents few characteristics of the context. a
3. An operation which manipulates or qualifies aproperty. ; =
4. Keywords which are used for the purpose of specifying conditional expressions. 4.10 User Inte
Conventional or Structured Component Design

- Each block of code has a single entry at the top.

- Each block of code has a single exit at the bottom.
- Only three control structures are required
: Sequence, condition (if-then-else), and repetition
(looping).
Reduces program complexity by enhancin
g readability, testability, and maintainability.
# Design Notation

the rules for processing inputs and events,

Scanned by CamScanner
 , program De
sign Languag
e Characterist
ics
- Predetermined syntax with k
€ywordg
constructs, data declarations 88 We Provided for the
Purpose of representing all structured
Free syntax ll as Mod
ule def; nitions,
of natural la
=-
ng uage forthe Purpos
Data declaration e of describing proc
essing features.
- facilities for Simp
le ag well comp
| =
Subprogram
definition aS
lex data stru ctures,
Well as invoe.
ation facilities,
|p pesign Notation Assessment Cri
teria
Modularityi : Nota
= te ti
t}on Providi e
support for develo
pment of modular
- Overall simplicity
: Easy to learn, fa software. |
Ease of editing : sy to use , easy to write
-
Rasy to make ch
anges j
|
Maintainability
: Maintenance of
procedural design re
presentation .
Structure enforcement :
Enforces the use of struct
ured programming constr
Automatic processing : Allows the designer to verif ucts.
y the correctness and quality of the design.
Data representation : Ability to represen
t local as well as global data directly.
. Logic verification : Automatic
logic verification improves testing
competence.
Easily converted to Program sour
ce code (makes code generation
quicker),
Syllabus Topic : User Interface
Design

410 User Interface Design

‘> (MU - Dec. 16, May 18)

0.4.10.1 Whatis user interface design process? (Ref. sec. 4.10)
Q.4.10.2 Write short note on User interface Design. (Ref, sec. 4.10)
User interface is considered as a front-end application view which
is interacted by the user so as
to use the software.
User is able to manipulate as well as control the softwa
re and hardware with the help of user
interface,
Now-a-day, ‘user interface appears in each and every place where there is existence of digital
technology, right from desktops, smart phones, cars, music players, airplanes, ships etc.
User interface is an integral component of software and is designed in such a manner that it
should be able to provide the user insight of the software.
UI offers a fundamental platform for the communication of user and computer. y

Fd
Scanned by CamScanner
 Softwar,
4-26 re
.,.video based. It is. usually depe
end Z soft
FP sotware Engineering (MU - Sem. 6 - Comp) s
nds Don oer
— ¥
The form of UI can be graphical, b:ased, audio- .
= are combination). ty
(
underlying platform (hardware and softw;
— The popularity of software depends,upon foll
owing “ .
° Attractive -
:
°o =©Simple to use
o Responsive in short time
o Clear to understand
o Consistent on all interfacing screens
~ Ulis broadly divided into two categories :
1. Command Line Interface .
_
2. Graphical User Interface

4.10.1 Command Line Interface (CLI)

CLI was considered as a great tool of communicoatio

t ys .
n with computers inin p previous days,
y
Now-a-days also CLI is the first choice of number of
technical users as well as programmers, cy
is considered as minimum interface which software can provide to its users.
A command prompt is provided by the CLI which is a place where the user writes instruction,
4.10.2
and feeds to the system.
Here there is need for the user to rememb
er the syntax of command and its use. In previoug days
CLI were not programmed to handle the user errors effect
ively.
A command is considered as a text-based reference to set of instructions, which Should be
executed by the respective system. |.

~ There are several methods such as macros

, scripts which make it simple for the user
to operate,
Very less amount of computer resource
is used by the CLI in comparison with
{Pinacarish gerald ta
GUI.
CLI Elements qf tetal 12266
wal
; J tevaroarsxd 2) qopal- scat?
aewar-ared 34 gopa atars M4 vol 2 2013,
{veWrPerre? lL gopall staf f
476 Ort 24 O9120 ..
526 Gu 2 2413 annotations- utput:
;
{Hwrsesee api. jax ‘ :
nd S gopal ssage S432 Jal 2 put
pUPererreeS D gepal atadf 690315 val
2013 catalina-snt.ja
¢ . E
;
Glesrerc? 2 2033 Cat
Yasesersee"3
fo gepal msste 257833 tar 2 3913 eatalaliina xha. jar
na-tribes.jar
gopal $ sca te $582332 ur 20 2013 Cat
V°heP red Sf gop al ‘
puter? arate 260636 dur 2 2013 ef}ali ng. jar
QcPeresresd
loopal atatt acs -4.2.2-5ar
yal 2 ek eb-aps.jar : i
Glpervee-?
F gopal stage $2324) Jul i c
Egopal esat 2
e 59928 42 3 2013 jasper 2029 jasper-e) jar
a
gifts? Lospsl staff .jar ‘
gag90 gar rE
Trevsee-B E qopal scaff | 177598 Jur >> 2223
2023 jep~epi jer
ES
NY Wetesee 8 2 gupal stars servies-api.jar i:
Q~SreenF of geral $873 Jak 2 2913 tomcat~aps. jer
SP NwerereF
stage reesg7 ai 2 2013 Semcat-coyete. :,
GoRe tems of gopal stage 23543) Wal jar =
Lgopal state 2 2013 tomas ~disep,
Qorteeresse-$ 5 gopal
77459 a > 2233 tomcar~itfaejar
s
=
Pinescec} fee male 4965
sel euate sie 3 ouJui >2 “202 3 f-istacfe nee
4
“fwrmene--$ lL gopal
Ncswre scare 324006 vai
at vensst-iRa-jascas ; .:
vree® f gopal 2 20:3 LOmeat = fdbe
stare 23202 2a3 ar a
y Rinacas lip x 20 2023 temeat~s :
Las
t

Scanned by CamScanner
 % “ Pu Engineering (Mu . Sem
(3s(y here are followin
g clement, :
Command m, A804 5
“Gy king. § PEt Tt i texty,
18 Working. oftware “many
Not
Software
. ;
. I *
_- Cursor : It Iw aq 8m,
Benerat,
ce
iors 8 it,
represent POSition of ch displays aa WEEE tac oe
"Zonta} i
moves when user
hi
yr:
Cter at th ine Or gq Vertical x ma
Command ; 4 co “28 or Teletes tox,© tj -_ “AlCurag
of tying bar with the height of line. It10s
is ten fo
parameters to it. Out in, Tis usefully found in blinking state, It
command Prompt is set
t of co 8 but AN exag
to the Next a 'Splaye, * 11
40.2 lin, e, inl ine on thetion, Th eTe may
Screen. After disbeplaon © or more
4,10- Graphical User Intertace (sun ying output,

- GraphicacolrtibUs
iziaeres Interfac
can be e offers Btaphical
ation of both m, ®ans to the . .
software. hardware and use for in teracting wiFth
software. Usin the sys tem. GUI
g GUL, user
is able to inte
rpret the
latest advanced technologyred as more resource Consuming as
compared to CLI. With the help of
the Programmers
designs W.hich , and d
Perform with esigners: are ympl
better efficiency, able to create comp ex GUI
accura cy and
d.

4,10-2(A) GUI Elements

GUI provides several components 5

for for’the purpose of interac
; ‘ with
ting ; software or hardware.
All of these graphical components give ways to interac
t with the system.
Following are some important elements of GUI:

Seal

; displayed. -
scon Jication are or lists.
in W. ich contents °F? be disp laye d in the form of ico s
s the area a”
t
tents cam
dow: : It is the - dow con
e Win "
for use
°™ file struc” ° . sationis very e25Y
- Torepresent th e navige!

Scanned by CamScanner
 ‘ J : .
i 2 ig } Sottwa
g j Seen ENgineering O4U - San. 6 - Comp} 4-28 " : Bla ex ttes Wary zB software En
; i — Windows
j Pras prvride — ility to minimi: resize or maximiz e. It is poss
or eid another window (child window) of the ® Bame
them any ; nn
appl ey - deve
i inside it,
° Tabs ication tes more than one instances of itself, then those;
“My
: When an applica execu
appear on the screen as separate windows. a 4
© Tabbed Document Interface provides the facility to open nore tl ; n one d Nt ig
indow. This interface is
used to view preference panel in application, Nowadays
fai feature is used by almost all web-browsers.
o Menu : Menu is considered as an array of standard commands, combined
4
located at a prominent place (mostly top) inside the application window.
It is also Possitg
Program the menu to appear or hide on mouse clicks.
Jeon : An icon is small picture which is used to represent an application.
j These icon, on
clicked or double clicked to open the application window.
j j Fite ca 8 GUT cursors are used to represent interacting devices like
mouse, touch.

jf = In almost real-time, the instructions given by hardwar@ are follow

ie,

ed by the cursor. Cursors y;

are also called as pointers are used toselect menus, windows and other application features,
me Ng,

4.10.2(B) Application Specific GUI Components

.

A GUI of an application contains following

elements :
- Application Window : Most of the application windows
use the constructs Provided by
underlying OS but some have their own
applicati customized windows to contain the contents af

Dialogue Box : Dialog bor is a child window which

has mess age for the user and request for
some action to be taken. For Example:
A dial og box is displayed by an application to get
conf irmation from user to delete a file.
Text-Box : Used to accept input from user
in text format.
- Buttons : Used to submit inputs to
the application. :
Radio-button : Displays list of options for selec
tion. Only single radio button can be selected
among all offered.
- Check-box: Its functionality is same as of the
radio button but it allows multi selection.
List-box : Provides list of available items using singl
e control. Multiple items can be selected.
.
4.10.2(C) User Interface Design Activities
ds

— Several activities are carried out for designing user interface. The process of
GUI design and
implementation is as of the SDLC (Software Development Life Cycle).
— For GUI implementation there are number of models available such
as Waterfall, Iterative of
Spiral Model. -

Scanned by CamScanner
 ;
__. Testing GuI
Task Analysis

Paq ”
GUI
-». Design and-
Implementation
hich

Fig. 4.10.1 : GUI Steps

. -
‘co «6s GUT. Requireme mt Gathering : The designers need the list of list of all functional as well as
non-functional require ;
oo. requirements regarding GUI. These requirements are accepted from users and
their existing software solution. : i . \ |
; . ; “
o User Analysis : The designer do the study regarding who will actually use the software GUI.
The target audience is an important aspect since the design details change according to the el

knowledge as well as competency level of the end user. a

GUI can be developed.

If user looks to be techno savvy then advanced and complex
is included regarding how-to of software.
For a new user, more informative data
the task which is to
: Desig ners have an impor tant responsib lity to analyze
o Task Analysis
.
software solution.
be done by the respective
resent the task in
ant how it will be done. It is possible to rep
is not import
Here in case of GUI, it ther into smaller|
maj or tas k at the top and dividing it fur
considering one
hierarchical manner

sub-tasks.
. vided by the tasks.
goals are Pro .
For GUI p resentation, nts is decided by the flow of information among sub-tasks.
|

t ting co
mplete
inf
ation regarding
after ge
n :De signers ,
mentatio im plem
1 z. mple G and
ective
GUI D the resp
Oo design
. t,
en
environm
.
n' ,
req wireme

Scanned by CamScanner
 : =a |
6 - Comp)
IBF sotware Engineering wy. + Sem. 4-30

BS Y Software i, Cc
rc caret working ow
set te
by the developers.
round. Then self-testing is implemented
° Testing: There are several ways to.implement the GUI testing. Organization ha,
Such as in-house inspection, straight involvement of end users and prior releagg
ion
version. Important aspects verified in testing are usability, compatibility, user
oF bet
Rte,
4.10.2(D) Gul Implementation Tools

There are number of tools available for designers to create entire GUI on a single mouse click,

Out
of them some tools can be easily integrated into the software environment. ©

~ Abuge set of GUI controls is Provided by GUI implementation tools.

The code is modified by the designed for software customization.-
There are diverse segments of GUI tools in accordance with their use and platform. E
Example

Mobile GUI, Computer GUI, Touch-Sereen GUI ete.

Following are some tools which are used to build GUI: : E
o FLUID .
© Applnventor (Android) . .
© LucidChart
° Wavemaker

© Visual Studio .
4.10.2(E) User Interface Golden Rules

- Dec an i ee ey and finding piste : .

- Tesearch and carefully planned testing. ee — involves in-depth

Scanned by CamScanner
-
Comp)
o6m- . 4-31
En ineeri ing (MU - S

User Interface golden rules

' 1. Strive for Consistency

2. Visibility of system status or Offer ctor

feedback
TryTyTT 3, Match between system and the real world
of
acl
Design dialog to yield closure
or Permit & asy
4, User control and freedom
reversal of actions
Error Handing }
5. Error Prevention and Simple
load or
6. Reduce short-term memory
Recognition rather than reca ll

7. Enable frequent users to usé shi ——|

——— :
design
=p 8. Aesthetic and Minimalist
, and
9. Help users recognize, diagnose
r recover from errors
n
bes! 10. Help and documentatio
golden rules
Fig. 4.10.2 : User interface

Strive for Consis

tency ns mean the same
al
ent wo rds, situat
ions, OT actio
er wh et he r dif fer
ve to wond
Users should not ha d actions consistent.
ur user keep words an
yo
thing. Do not confuse
of Least Surprise”.
Use “The Principle .
ate Control
Example : Car Clim

certain style
lic ati on con sis ten tly. For example a
app
elements across your lly, going deeper
- Inother words, use all tion should function logica
the same thing, or n@ «za
of button should always do
.,
in hierarchy.
- Consistency of:
o Workflow / Processes
o Functionality
Z
Scanned by CamScanner
 er Software Engineering (MU - Sem. 6 - Comp)
ss Soft
_,
are
giseeee
ga—

© Appearance
© Terminology
: one feedback
| * 2 Visibility informative
of system status or Offer infor
;
bout what is going on. Through ap ,
~ The system should always keep user a
s informe guessing tell the user what’s happening, tte
feedback in a reasonable time. Don’
t keep the use
~ Example:
OS Installation status -
Preparing to install. Your computer will restart automatically.

El Capitan

mmmcmmmemummmmm SEO

— The user wants to be in control, and trust that the system behaves as expecte
d. It could be evey
said that users don’t like surprises.

- For frequent and minor actions, the response can be modest

, while for infrequent and major.
actions, the response should be more substantial.
,
Feedback

- Relevant ~
- Fits importance and urgency

~ Comprehensible and meaningful

- Within appropriate context (time and

place)
> 3. Match between system and the
real world or Design dialog to
yield closure
- Again, the less the users have to guess the better. The
system should speak the users’ language a
(use words, phrases and concepts
familiar to the user), rather than
special system terms.
- Example: Payment proceeding (by
Ramakrishna)

Scanned by CamScanner
 - Sequence
of Actions
sh
process is fi
nisheg
middle and end. When a

- Grouping of actions,
- Explicit completion x
of an action
- Well-defined options
for the next step
+ 4, User control and fr
eedom or Permit easy
reversal of actions
- Shneiderman puts it nicely “This feature relieves anxiety, since the user knows that errors can be A. fe
undone; it thus encourages exploration of unfamiliar options.”

- Example: Document History

Scanned by CamScanner
 4-34
- -£§ GBF sonmare eninoning (Som. $C ctionali ty. Clearly . mark an “emergency . ™
* i
- anaes
In applications, this: refers to the undo . and redo through
fun!
an extended dialogue. ta
leave the unwanted state without having to go :

ae — Reversal of actions
© No interference with workflow
°o More freedom for the user
{ © Single-action undo and action history
“> 5. Error Prevention and Simple Error Handling .
g that they themselves have done gs .
Users hate errors, and even more so hate the feelin, heck for them and notify
users about thay
wrong. Either eliminate error-prone conditions or ¢
before they commit to the action.
— Exam
: ple
Password Enter :

[mn
- tw :

i 1 Your password must have:

! j pel @ 8 of mote characters
i ‘@ Upper& lowercase letters
@ Atleast one number
fei | _ = Strength: strong
, ‘
é
Avoid passwords that are easy to guess or used with -
i other websites. hao siete ical
i. _- As much
as possible, design the system so the user
cannot make a serious error.
If an error is made, the system
comprehensive mechanism for hand
should be able to detect the error and offer a simple
ling the error, ~
Error Prevention
b
Error prevention over error correction
Automatic detection of errors
Clear error notifications
- Hints for solving the pr
oblem
> 6. Reduce short-term
memory load or Reco
gnition rather th
an recall
- As Nielsen says, recognizing
‘ . som eth ing is easi than re
easier
memory load by making objects, actions, and option pray - ae
s avail tiie 1. Minimize the user’
The user should not ‘have to Tememb
er infOrma
ormat;
Instructions should be visible. tion from
on ‘Tom one part of the dis; logue to anothet.
- Example: Ring/Silent switch

Scanned by CamScanner
 - Use iconography and

to help the return;

j Reduce memory Joag

App has a clear structure

- “Recognition over recal}”

- Implicit help
- Visual aids

. and Personalize) frequent . .

= ate >
Abbreviations, function keys, hidden actions, _
commands, and macro facilities
are very helpful to an expert
- Example : Click Co
mmands and Shortcuts

New Window = ~~ >_98N-3g

_ New Private Window -<>eN
New Tab tt
Ope nFile..
~ Open
- -¥38L0
Location...
Shortcuts ,

- Keyboard shortcuts ‘
- “Power User” features “ °
‘

- Action automation

Scanned by CamScanner
 EEF" scoware Engineering (MU - gem 6- Comp) —
7S Aesthetic and Minimalist desism : be t valuable : and relevent.
~— Minimalist doesn't mean limited. All information should

Example : Simple Interface.

risk Wdenticate
SCM process.
(FT). Waikthrc

Simplify interfaces by removing unnecessary elements

or content that does not support Deer 5A
tasks. : Risk M
> 9. Help users recognize, diagnose, and recover
from errors
Error messages should be expressed in plain language (don’t
use system language to deseriks
what the system is doing), precisely indicate the problem, and constructively suggest
a solution,
- Example: Plain Message

Message text No title

SSA GRE

Secure Empty Trash permanently erases

the items In the Trash. Are you sure you
: ‘want to permanerase ent ly ©
them?
1 It you
choose Secure Empty Trash, you can't recover
Informative text ————____ tre tems uriess you've backed them up ustiy Tans
-
Machine or another backup program.
.
Bouse ee

’s happening both on the backgroun

Perform an action. d and when they
> 10. Help and documentation

— Evef n though it is better if the inte

rface can be used wit
hout documentation, it may be nece
te provide help and documentation, ssary
- Any help information should be easy
to search, focused on the user’s task, list of con
and not too large. crete steps,

Chapter Ends...
qoo0

Scanned by CamScanner
 Risk, Configuration i
& Quality Assurance .

~~

Risk Identification, Risk Assessment

SCM process, Software Quality Ass
' Software Configuration Management, SCM repositories,
(FTR), Walkthrough.
Metrics, Software Reliability, Formal Technical Review

@.5.1.1 Whats software risk ? maar > (MU - May 15, Dec. 15, Dec. 16, May 18) i
a, 5. 2 Discuss the different categories of risks, May 15, 2 Marks
(Ret. sec. 5.1)
Eee
0.5.1.3 Explain diferent stops in rick management
with suitable diagram, :
(Ref. sec. 5.1) : ;
ag
; Dec. 15, 5 Marks
Q.5.1.4 Write short note on Risk Management. (Ref. sec. 5.1) PESO S
Q. 5.1.8 ___Explain Risk and its types. (Ref. sec. 5.1) . a Se =F si aoe

.
Risk is the possibility of suffering loss. In the project
development, the loss illustrates the impact
to the project which could be in the form of diminished quality of the
end product, increased costs,
delayed completion, or failure.

Scanned by CamScanner
 ss
tallityAt
& Qu ,
i l Me
uration a gm
Ris k, R i s k , Co nf g u a
5-2 Softwi are
FP sotware Engineering (MU - Sem. 6 ~COmP) oct Management are % 8 fo.
Various Kinds of Risks Associated with Software Proj
‘arious Kinds o
_
1. Schedule nning Risks oa .
/ Time-Related / Delivery Related Pla! chedule and are essential time-related risks, Whig,
F . ing behind sche
These risks are related to runD: .
directly impact the delivery of the project.
Some of the reasons for such risks are : rrect project schedule.
- Incorrect Time Estimation, and consequently an os . i
Improper Resource Allocation. ; : _
- Underutilization of Resources. /
Superficial Understanding of Project Complexities.
5 a
- Unexpected Expansion of Project Scope. } t
Incorrect time estimation may occur because a' ctivities may path external
tical have
dependencies . suchete as
activity has a
client approvals, subcontractors etc. and a delay in a critic ne
on the entire project. / Ja .
Resource Allocation may be improper / underutilization of resources may take p
ce.
if:
» ©Specially
resources are shared between projects. : ssolatost
A silo approach of members in various teams ini a project
i 0.
may lead to an isola’ superfici
Perficial
understanding of project complexities which may result in delays in subsequent stages ©.g. when
different development teams work on various aspects of a software project and run into issues
during system/integration testing.
“8
2. Budget / Financial Risks ©

These are the monetary risks which are associated with budget overruns.
Some of the reasons for such risks are :

- Improper Budget Estimation.

Cost Overruns due to underutilization of
resources.
— Expansion of Project Scope.
— Improper Tracking of Finances.
‘

sources are shared between projects

— Farther, unexpected expansion

of project: sco pe (due
to addition of features by clients,
lead to budget overruns as
Such expansions may not etc) may
have been factored into the original

3. Operational / Procedural Risks

These are risks which are associa

ted with the day-to-day operat
ional activities of the
proj .
© project
metiee Z = >

Scanned by CamScanner
 a
Na ee ee ci

acne ftom
s mi tmb vas

Pepa
ony, P *

Effective team =
comm ication 5
| pro,jectsee such as 5 oftware Projects,n thers
is an ¢, .
Ssential part of project manage ; ; ;
' Such as a setup for escalation, , conflict 18 a strong need for an estab Bernent and in people-intensive
1g e face employees need to be trained in ee . Process, established establi cen oh oe Enasi structure,
nical / Fu ig use of these iro me ject priorities and above all, the
4. Tech nctional /Performance a Sses within the organization.
‘ially if . iSks
These are technical y;
Tisks associated
rficiay “_ Pema with the
functionality of the software or with respect to the
- order to com

when
Sues sometimes reduce ve for ality
the function, excessive budget overruns and schedule overruns, companies
of the softw
‘are

which results in insufficient soft

ware testing,
- Furteth er, develo
pers face a constant trade-off betwee . evin
n achi g maximum functionality of the
so are ai ter ms of software features) and , peak per
formance (maximum speed and quick
ponse time by minimizing and eliminating unn
ecessa ry add-ons from the software).
In
order to mainsae
the purit. y of the software development proce
tain
ss, while simultaneously
catering to'the customers’ needs, a mutually agree
d-upon cut-off date should be determined, beyond
which “expected software functionality” would be frozen and any furthe
r requirements would be
handled in subsequent software’s releases.

Other Unavoidable Risks .

All the risks described above are those which can be anticipated to certain extend and planned for:
in advance, However there are certain risks which are unavoidable in nature.

The reasons for such unavoidable risks are described below.

o Changes in government policy,

o Obsolescence (becoming outdated) of software due to new technology from arival company,
customers end.
o Loss of contracts due to changes at

nem

Scanned by CamScanner
 ae u 64 Software Risk,
; : er Software Engineering (MU - Sem. 6 - Comp) " ith es, methods, and tort, : —
fy
a2 - Risk M software en) gineering practice W t for proactive decisi jon-maakins : 71 BE
i ; mana skgingManagement
risks in a pro a t. It provide a n disciplined environmen
is jec
' to: |
5
d assess ment).
; co Assess continuously what can go wrong (risks identification an
at setts (eto prioritization).
© Determine what risks are important to de
tion).
° Implement strategies se risks (risk resolu
to deal 7
k managem ent pl anning, analysis of ris),
Risk Analysis is series of proced
identifying and controlling the risk involved in project.
ivities :
Risk Management Procedure basically includes following activities
1. Risk Assessment

2. Risk Identification
3. Risk Containment

Syllabus Topic : Risk Assessment

5.2 RiskAssessment _ _

P 5.2.1 Describe the following with respectto Risk assessment Tos :

_(i) Risk identification (ii) Risk analysis (Ret. sec, 5.2) _ ie ie (5 Marks)
In Risk Assessment, mainly following elements are there :

Risk Assessment

>| (A) Risk identification

(B) Riskanalysis
(C) Risk prioritization
!

- Fig. 5.2.1: Risk assessment

> (A) Risk Identification

Produces lists of the project-specific risk items likely to compr

omise project's success.
> (B) Risk Analysis ;
Assesses the loss probability and loss magnitude for
each identified ite m, and it assesses compound
risks in risk-item interactions.

+> (C) Risk Prioritization

Produces a ranked ordering of the risk items identified and analyzed.

Scanned by CamScanner
 the other type of
-— The best way of
an; .
essential areas alyzing a proj pl
Project :
an
. *8 by conver ting it to a flowchart and examines 23 al all

=
= - Any
facto:
decision
taken relateed to techn; :

- _ In ‘actors
this should
phase he
of evaluated
Risk m mens
ly. °perational, political, + legal, » social,
social, in! or extern al
internal or

identification gement we have to for risk

; define processes that are important
.

femaReview the past “orefSsess the

practicesthatare | [=| Come upwith — |-
Project history | | - being fotoneait » erative Woesfor
| the present project | | future projects’. :
Fig. 5.2.2 : Risk identification

- soit ceaaea
All the detail es
s of the esuch as S uni
risk unique Id, date on which
which iti was identif
identi ied, description and so on

- There ere are are ini

general two types of risks : generic risks and product-specific risks.
o 7 :
Generic risks are considered . threat to each and every software project.
as a potential

o Product-specific risks can be identified only by those who are having a clear understanding
is to
regarding the technology, the people, and the particular environment in which software
be built.
is need to examine the project plan and the
~ For identification of product-specific risks, there
“Which
er to the given question sh ould be found out:
software statement of scope, and an answ project plan?”
ctive product may threaten the associated
particular characteristics of the respe
list. This list helps in risk
mec han ism to ide nti fy risks is to ge nerate a risk item check
One e risks in the following
on and hig hli ght s som e subset 0 ¢ known as well as predictabl
identificati
s :
given generic subcategorie software which is to be
built or
ove ral l siz e of the
related to the
°o Product size : Risks
customized.

Scanned by CamScanner
 te
ion Mgmt & Qui As
. ge
se
Software Risk, Confi
, 4 key rat aiteg
Software E gineering (MU - Sem. 6 = Comp)
Fe a
i | d tossconstraints which are impo!
imposed by the managem,,
te ; a
° Business e impact
P : Risks relate
the marketplace. phistication of the stakeholdey,
‘ a4
°o
related to the 60 manner. _
Stakehold characteri
er of developeratios | RY vith stakeholders in a timely
the capability to interact w eptent ta
which the software process has bee
© Process definition : Risks ea development organization.
SA

defined and isi followed by by the respective

related to the availability
a as we ll as quality
i o¢ the
Hy Development environment
°o : Risks ct.
existing tools which will be used to develop the produ
© Technology to be built : Risks related to the ee ty of the system which is to be bui,
which 18 P kaged eet ae lh eg
by the system.
and the “newness” of the initiated technology
to the overall tec’
o Staff size and experience Risks related
.
experience of the associated software engineers.
i the risk
isk item
i chee ‘list.
There are different ways available to organize
Questions which are relevant to all the respective. topics can be answered for each and
software project.
The answers to these questions help to calculate the impact of risk.

lan
* 5.2.2 Risk Analysis

[ais3s. Byteman ociue mee

= Qualitative risk analysis

It is a procedure in which assignment of priorities to risk can be done according to their

_ Possibility of occurrence and their effect.
. :
It supports the managers to decrease the uncertainty
level and focuses on risks which have high
Priority.
Create Plan for risk management as early
as possible in the project. It can impact
factors like cost, on different
time, scope, quality and procurement.
The inputs of qualitative risk analysis
involves :
o Risk management plan
© Scope baseline
o Risk register
— Enterprise environmental factors
. ‘
o Organizational process assets
o The output of this stage would
be
© Project document updated

Scanned by CamScanner
 ‘ ’ quantitative risk aNalysig

_ Itis the Process 4 ft

purpose. =

Risk register

- Enterprise environmental a,
TB:
° Oo rganizational
izati Process assets
o And output will be
© Project documents updates
53 _Risk Containment

containment 2 Ret. sec. 5.3) uae ; 7

- Containing risk is th ; Marks) |
] residual risks and anal© process of keeping track of noticed risks,
ing the risk risks, finding
findi i
new risks, iteri
monitoring : f

- The inputs for this phase are : .

“

1. Project management plan _

2. - Risk register

38. Work performance data

4, Work performance reports

- The output for this phase are : .
1. Work performance information
2. Change requests

3. Project management plan updates

4, Project documents updates
s assets updates
5. Organizational proces : —
Projection
Syllabus Topic : Risk
=

54 Risk Projection - (Marks)|

Scanned by CamScanner
 ts to rate each risk :
ttemp'
[4
: = Th ere
by which Risk projection (or estimation)
are tw two ways by w
gi © The probability that the risk is real, in r.
should it occu
¢ problems associated with the risk,
o The consequence of the four risk projection steps.
and techni cal stalf perform
i - The project planner, managers, ation.
a manner that leadsoa to prioritiz
i - The intent of these steps is to consider risks in
re rces where they will have the
can allocate limited
- Be prioritizing risks, the software team
most impact.

= Risk Projection/Estimation Steps

of a risk (e.g., 1- low, 10-high).
1) Establish a scale that reflects the perceived likelihood
2) Delineate the consequences of the risk.

3) Estimate the impact of the risk on the project and product.

dings,
4) Note the overall accuracy of the risk projection so that there will be no misunderstan
‘* Contents of a Risk Table .
- Arisk table provides a project manager with a simple technique for risk projection
- It consists of five columns:
o Risk Summary : Short description of the risk.
o Risk Category : One of seven risk categories.
o Probability : Estimation of risk occurrence based on group input.
° Iepact : (1) catastrophic (2) critical (3) marginal (4) negligible.
o RMMM: Pointer to a paragraph in the Risk Mitigation, iascemiaranicc and Manageme
nt Plan,
| Risk Summary Risk Category ‘Probability. ‘Impact (1-4) |

@ Developing a Risk Table

~ List all risks in the first column (by the help

of the risk item checklists). Mark the cate
each risk, gory of
Cz Estimate the probability of each risk
occurring,
~ ‘Assess the impact of each risk based on an a:
Vveraging of the four ri .
overall impact value. ur risk components to determine an
Sort the rows by probability and impact in descendi
ng order.
- Draw a horizontal cutoff line in the table that indi
indi : : ;
attention. cates the risks that will be given further

Scanned by CamScanner
 goftware Engineering (Mu . s
: em. §
; Asse ssing 9 R Risk Impact —Co
Three factors affect the co
nse
Its nature : Thi, indj
Cate; ences
© pr
that are li
_ Its scope *: Thi, “Ais combin blems th; ‘oes
es
(how much was affectegy 2 '® S°¥erity of i. € risk
Are likely
th if ty, 8 mee
risk occurs,
= Its timin ig :This. Considers wh ‘ow 8erious w.

the en 48 it) with its overall distribution

ghe overall risk exposure formu] a igRE.p
d for how 1 Ong the;
© im
aes
: p =7 the probabili ty of occurren, =e Pact will be felt,
= th 7 ce for i
e © cost to the project Should th e ae
pxample TSK actually occur
P = 80% Probability
C = Total cost of devel,
that 18 oF 60 software en

= 0.80 ping 18 com Ponents will have to be developed

RE is $95 000
-80 x $25,00 0 = $20 fn Ponents

a ,
Syllabus Topic : RMMM

55 RMMM .

—_____ => (MU- May 15)

{Q, 5.5.1 Write note on RMMM. (Ret. en

e e ee
‘ Piss myuntedmanoni in setting up Be eis Or yh z :

The main aim of all of the e ririsk analysis. related activities is to guide the project team in forming a
strategy for dealing with risk.

In an effective strategy there are three important issues : risk avoidance (mitigation), risk
monitoring, and risk management and contingency planning.
considered as always
If proactive approach to risk is accepted by a software team, avoidance is
the best strategy.
for risk mitigation.
This is accomplished by setting a plan
per previous
de: r that high staff turno ver is marked as a project risk ri. As
- For example, consi (70
er is guessed to be 0.70
instinct, the likelihood 11 of high turnov
history and management ct x1 is projec ted as critical.
,
the im pa
percent, rath er high) and and schedule.
igh turnover on project cost
It indicates that there will be critical impact of hi
turnover.
py can be developed to de
crease

To mitigate this risk, a strate

X ibl steps to be taken
are: de reasons for turnover (e.g., poor working conditions,
Among the possible
current staff to deci .
prior to the pro) ect starts.
iob market).

Scanned by CamScanner
 _£ gottnaZe Env,
/ j EP Goftware Musk, NL
sottware Engineering (MU + Sem, 6 -Comp ASS
‘rit ) 5:10 ;
ie occurrence of turnover and dereiag
g - fefn
3f © After comm
techniques ence ment of project, assume there will , rinks
to take care of continuity when peo
ple Jeave. tion :f
° Organize Project teama to widely disperse the inform
regarding each developmen, = Mort
ject Le, a :
netivity, . and.
© Dofine work Product standa
rds and set syatem to assure
that a II the respective modoly ,
|
documenta aro develo
ped in expected tim
e duration.
4
=ea
© Allocate a backup staff for
all the critical technolog
} - The factors are monitored . ista.
siygint ne whet inp a ; 7-
by the project manager Rie
which may give a
becomi ng more or less likely. ak fy E (1)
- In the case when there is high staff
turnover, the common titude of team members q
on
j potential’ ‘proteins i (2)
upon project pressures, communication
compensation as well among team members,
as benefits. th
- Besides monitoring these factors, a project manager (3)
has also responsibility
ibility to moni itor th.
efficiency of risk mitigation soQe«
steps,
.
— For example, a risk mitigation . . definit
step which is pointed here ap5 calle ors the‘eveldefinition . ofPa
—
product standards and mechanisms to assure 5.6 Sot
that there is no time delay in development
Products, 9 work a
. .
- Itis responsibility of the project
manager to monitor all the respective
work products cautiously
to assur
e that each can stand on its own and
that each conveys data that would
newcomer were force be essential if 3
d to join the existing software team in their work
in the middle of the Project,
- Risk management and contingency planning considers
efforts and that the risk
that there is failure in Mitigation
is really occurred.

announce that they will

be leaving.
- If there is implementation
of mitigation strategy, bac
: documented, and knowledge kup is on hand, information
has been dispersed across the js well-
team.
- Additionally, one can for
the time being refocus res
ources (and manage the project schedule
the team is necessary to
“get up to speed.”
- It is essential to unders
tand that risk mitigatio
n, monitoring, and mana
will definitely incur add gement (RMMM) steps
itional Project cost.
: 7
: : .
5.5.1 The RMMM Plan

Scanned by CamScanner
 ar met
to
es database syste,
With the help ene 1
Tmal RMMM document. Inatead, the
and entry, .
P Of Risk Information Sheet (RIS).
> Priority order}
ering,
- After d°cumentation of RMMM , ining analysis :
steps starts, and the proj may be done easily.
- Risk mitiga
tion is consid
1e Tisk ig - Risk
i monitoring is consi ered ag 8 problem a
id ered as A project tr
voidance acti ivity,
objectives :
depends ease
(2) To make whether Predicted risks do, i wking activity having three primary
s sure
S t . n fact, occur;
iS with an hat risk aversion step:
S which are defined for the risk are applied correctly;
(3) To gather the da
‘or the ta that can be yu; sed for future risk analysi
—_= : lysis.
Syllabi us TOpic : Software Con
figurati ion Manageme
Manag nt
P work
f Work 5.6 Software Configuration Management

lo. 5.6.1 Write note on scm: 7

ously qo Marks) |
SOM with benefits and disciplines. (Ref. sec. 5.6)'
lif a Configuration Man . :
items in a syste Bement, (CM) is the process of identifying and defining the configuration
ject, . vs . ™m, controlling the release and change of these items throughout the system
lifecycle, recording and reporting the status of configuration items and change requests, and
ition.
verifying the completeness and correctness of configuration items.

- Configuration Management is practiced in one form or another as part of any software

ers
engineering project where several individuals or organizations have to coordinate their activities.
both hardware and
- While the basic disciplines of Configuration Management are common to
ell- due to the nature of
software engineering projects, there are some differences in emphasis
software products. ,
ule for managing the evolution of software
Software Configuration Management (SCM) is a system
opment and during all stages of maintenance.
products, both during the initial stages of devel
an d
complete set of computer programs, procedures,
- A software product encompasses the
user.
data designated for delivery to end
associated documentation and
of the software produ ct,
soft ware used in deve lopm ent, even though not part
- All suppor unng
orti
d by SCM.
should also be controlle
.
\

Management
5.6.1 Benefits of So ftware Configuration ty.
ss of size, scope, and complexi
benefits to all projects regardle
fits experienced by project teams applying the SCM disciplines
— SCM provides signific an
. . .
\ .

t ne

: ;
most common bene
Ss
. of the
the SCM system.
a ribed here are possible because
desc

Scanned by CamScanner
 Confi
uration Mgmt & Quali Assura
EP sonmare & ineering (MU - Sem. 6 - Comp) §-12 Software Risk, Config uaten=
nce, :
™
SS

;
ine9 ring (M
' re
to help:
Provides a snapshot of dynamical 3
ly changing softwa
o Make decisions based on an inst
antancous view.
© Determine status
at module and sy
° st
em levels.
Make better decisions ab rojjec
ectt..
out the future ofa softwa
Tracks concurrent deve re p f the overall system to :
= lopment of modu les or compon
: ents 0:
' ° Prevent different develope ule at the same time,
rs from making change
if © s to the same mod
{ Allow for the overall system progress to
/ be faster,
4 {
Provide visibility of the entire software project
:
°o
to all develope rs.
Pee = Organizes all concurrently dev
fig eloping code and associ.ated locum tion to :
iia
3a © Save overall project time. d jena
ig . .
id
o Focus
each Phase of the software
product development to be organized and executed in g
documented, prescribed
manner,
| 5.6.2 SCM Disciplines
:
| ~ SCM .
disciplines are used to simultaneously
representations of the software Pro
coordinate
configurations of many
duct (e.g., source code, relocatab different
documentation), le code, executable code, and
.
In practice, the ways in which SC
M disciplines are performed will be
kinds of software being different for the various
develo ped (eg., commercial,
manufacturer). embedded, original equipment
The degree of formal doc :
umentation required wit
hin and across different
phases (e.g, research, lifecycle management
product developm

designs, and implem

entation of code, as well cifications, *neration of spe
baselines defined dur as to the more rigidly
ing development and doc ume nte d and controlled
system maintenance,
The effectiveness of the
SCM system increases
an explicit part of in Proportion to the degr
the normal ‘day-to-da ee that. its disciplines
y activities of those are
and maintenance effort involved in the so
s. ftware developmen
t

Scanned by CamScanner
 a Ne ¥
software Enginoerin, MU. 5 we ro my
— 6 -
em. Tete ae
te 3 am
hs

- The firs: t step * the Scm Comp)

in 8 = Software Ri 1 | &
,
ystem ig isk, Configuration Mamt & Quality Assurance,
» Wo identify the 08 identity
8808, to
th
ctu
Configuration Itema to be controlled and, 2s
Te of the i ntermediate
. or complete software products.

designs, user guides, test suites, test ; <a

_- Baselines are defineg
lifecycle. nd created in accordance wi .
.
ce with the SCM Plan
and the phase of the project's '
ft eg
7
Software ¢ j
Management Faration
8 Pecifies configuration items
2 \
HW4-coODr

Configuration $ me
- Wentification T
A
chem
to be controlled
T
u
Ss Configuration record at a point
in time
_. Definition |
&

A
c
c
O=mM—<mMy

Qo Control of change and libraries

u
N
T
l
No See N_ Criteria and authority as defined in
1 <<: lew: “= G Configuration Management Plan
Reiease? _~

Yes
©

Fig. 5.6.1 : High-Level View of Software Configuration Management

formally r eviewed and agreed upon, that

A baseline is a specification or product that has been
t, and can only be change through formal change
serves as the basis for further developmen
control procedures.
exist at a given
snaps hot of the agg reg ate of software components as they
A baseline is like a
point in time. ed
are completed and accept
the sof twa re lif ecy cle , configuration items that
During each phase of
that phase.
approval authority become the b aseline for subject
by the ne is believed a change, and is
the app rov ed bas eli
on, or deletion to .
Any addition, alterati
control. uration
to change tute the current config
from tho se baselines, consti :
im : cle controls subse quent
aE i
. us ach of ved
the appro the pasel ineses established during @ software lifecy
chang

identification. ; th o
: of a software
‘ g the life
op ment.al vnnfi gurat ion pasel ines that are estab lishe d durin
software devel
The following are ie
project.

Scanned by CamScanner
 a oftware, Engineering (
c uration Mgmt & Quality Assuranes
14 Software Risk, A _ Appendix Cp
[EP sonware Engineering (MU- Sem. 6 - COME) 5 tance oF approval ofthe sofware OF syg disciplines.
== . ce) i o! e
to the completion Softwany This list car
o Functional Baseline # Established‘callyby the sponds
complexity ¢
specification. This baseline tyP! vornee
the software requiremen specification
requirement review.
a
. i ts i i

i approval of ecification review,

ea wo the completion of altheof software ? cal d ocum( entati on that
es Seal the techni
This baseline typically corres.
jon
tion of interfa ces an 5.63 SCM Repos
ished by the ‘approv : cumenta
detailedh design (incl
and : Establis nds +o the time trans

(ose2es
° Se Baseline
tional en vorrespo
e
on ter software) Normally, this baseline
computer
databases for the _. 50. tical design review.
, and the critic
‘ow In the fh
spanning the preliminary design reviow S°° cification follow}
of the PO spe ollowing was don
Baseline : : Establis
Product uct Baseline Es hed by approval +
. Audit (F (FCA).
° : cabinets
Configuration
completion of the last Formal Functionalae .
elined, ;
configuration con trol provid es a
— Once configuration items have been identified and bas “acini - Thisap
propos sat a femilly {ANG
system to initiate, review, approve, and implement Y identified
(1) Ge
report that is initiated against a
- Each engineering change or problem (2) De
its necessity and impact.
configuration item is evaluated to determine (3) B
tly
performed to verify that the change was correc
— Approved changes are implemented, testing is chang e, and the a
effects have occurred as a result of the
implemented and that no unexpected side (4) 1
affected documentation is updated and reviewed.
mation about all configur: ation management
— The discipline of Status Accounting collects infor
- Tod
activities.
ing data on the status and history of any — We
— The status account should be capable of provid
‘ acc
configuration item.
the rebuild of any previous - In
— ‘The information maintained in Status Accounting should enable
de
baseline.
hi
on
— Audits and reviews are conducted to verify that the software product matches the configurati
item descriptions in the specifications and documents, and that the package being reviewed is
complete.
- Any anomalies found during audits should be corrected and the root cause of the problem
identified must be corrected to ensure that the problem does not resurface.
— Generally, there should be a Physical Configuration Audit (PCA) and the Functional
Configuration Audit (FCA) of configuration items prior to the release of a software product
baseline or an updated version of a product baseline.
- The PCA is performed to determine if all items identified as being part of the configuration are
present in the product baseline.

- The audit must also establish that the correct version and revision of each part are included in
the product baseline and that they correspond to information contained in the baseline’s
configuration status report. ,
- The FCA is performed on each software configuration item to determine that it satisfies the
functions defined in the specifications or contracts for which it was developed. .

Scanned by CamScanner
 . eMainten
Uy(y i identig. ~ (yd) 1S Getty
approg .
Problematig ;
file fog ANCE Of sof,
ers oy ring binders = items

“cong tion ; *T Many Teasong Stored in metal ‘

as Correct ; D 7 ‘ermining
(2) .
the ite never |
8, ang the (3) Building @ new ye at Were dated, wh 8S often difficult, r
an “sion of ady “mand by whom Was y tough ;
. ting apn; usuall
"4gement ” Narrating thoroy, or Pplication was time Wasting and ,
irt com error prone, ot
oF any - Today,“rtually not Possible,
SCIs (Software G ”'®* Felationshipg amo ng the respective configuration j ae4
was
. -: We bste.T’s Dictionary nfigurati
aes on Items) are maintained in a Project da: =
& ,
"eVioug accumulation or sto ” © Word Teposito . tabase or repository.

ation

ed is

lem

al

The Role of the Repository

The SCM repository is the group of mechanisms and data structur
es which enable a software
team to deal with modifications in an efficient manner.
It offers the apparent functionality of a modern DBMC (database management system) by the
way of taking care of data integrity, sharing, and integration.
- Additionally, the SCM repository provides a hub for the purpose of integration of different
process, and can implement
able sieve
& vailabl tools. ‘ It helps to manage the flow of the software
related work products,
uniform ‘orm structure as well as format for software engineering

Scanned by CamScanner
 £5 sonware MU
- Som. 6 - 5-16 Software Risk, Configuration Mgmt & Quali Assura
=

ae p j _~ To get these abilities, the repository is described in terms ofa meta: -model.

The meta-model is used to identify the way by which information is kept in the repository, ,
a way by which data can be accessed by tools and seen by software ees how well data
Security as well as integrity can be maintained, and how simply the present model cap
be iF 5.6.4
it . jj a extended to fulfill new requirements.
r Generaj Features
and Content

To understand the features and contents of any repository, we have to see it from two
Perspectives: what are the content which are to be stored in the repository
and what arg the
Precise services which are provided by the repository.
— A comprehensive breakdown of sort of representations,
documents, and supplementary work
products which are kept in the repository
is shown in Fig. 5.6.2.

Source code
Object code
System build instructions

_ } Test cases
Test scripts ;
Test results Be
Quality metrics Be

S
Change requests
Change reports Requirements spec
SQA requirements Design document
Project reports/audit reports Test plan and procedure
Project metrics Support documents
User manual

Scanned by CamScanner
 (MU . Ouallty Aaguranc 8
oftware Engineering
Software Risk, Configuration
(4) Maintain storage of several types of «
ophisticated data objects such 99 text,
audio, ete.

eo
Syllabus Topic : SCM Proces
s I
6A sCM Process
5. OB

The SCM process defines a Sequence of tasks which have 4 most important objectives :
(1) To identify all of the respective items which jointly define the software confi guration,

(2) To manage changes applied to these items,

(3) To ease the building of different Versions of an application, and
.
(4) To make it sure that there is consistency in software quality as the configurati;on — er
time.

-
wae
A process which is able to achieve these objectives need not be technical or heavy, put iti must be
: a lex
characterized int such a way that it should enable a software team to solve all of the .
questions : . .

o What will be the way for the software team to recognize the distinct elements of a software
configuration?

o What will be the way for the organization to manage the several existing versions of am
application that will help to accommodate change efficiently?
o What will be the way for the organization to control changes prior and later the software is
released to a customer?
o Who are individuals responsible for approving as well as ranking requested changes?
o How can we conform that the respective changes have been made correctly?
o What will be the mechanism to apprise others of changes that are made?
- These questions lead to the definition of five SCM tasks :
Identification, ‘
Version control,
OD

Change control,
Configuration auditing,
oF

Reporting

Fig. 5.6.3 : SCM Tasks

Scanned by CamScanner
 . ) 5-18 Software Risk,
Configuration Mgmt & Qu: <<
4 Z software
E
EEF soars Engngorng (Mu - Som. 6 - Comp —— ou
5.6.4(A) Configuration Identification off.
roa * : 5 7 _ In
S s tems to be man ;
= ihe in the
Sett “ step the SCM system
management authority identification
is the responsible Ot om “eed ang thy _ De
for eac - loved
Tor
- This is a critical cal step in the system since the identification scheme is employed
step throughoyy ~ w
lifecycle of the software product. will ; ; al
- The levels of authority assigned responsibility for each configuration item du, depending tm | _g
th je . com plexity of the softwareI product, the size of the development team, and the manage Tens c
style of the responsible organization. —_ :
Configuration identification consists of selecting the configuration items and recording thee |
- oe
functional and physical characteristics isti as set forth
fo in technical documentation Such 4, _
specifications, drawings, and associated lists. _
- The following are examples of items managed in the SCM system.
co Management plans’
o Specifications (requirements, design) .
o User documentation , -
o Test plans, test design, case, and procedure specifications
o Test data and test generation procedures : :
o Support software used in development, even though not part of the delivered software
product 7 _
o Data dictionaries and various cross-references
o Source code (on machine-readable media)
;
o Executable code (the run-time system) F
- o Libraries ;
° Databases (data that are processed and data that are part
of a program) &
° Maintenance documentation (e.g., listings, detail design descriptions)
qq
- Effective management of the development of a software
product requires careful definition of the | 56
configuration items. / = °- WA
- Changes to these items also
= eae

need to be defined since these

baselines specify the evolutio changes, along with the project
n of the software product.
. .
~ SCM includes all of the entities ,
of the software product as wel
documentation, l as the ir various representations in

— The entities are not all subjec

t to the same SCM disciplin
es at the Same time
- Support petrare is the class of software tha
t may or may not be delivered with the soft
produc
the peot,dvesbut is necessary for designing, . enhancing, * or testing the ware |
changes made during
.
the life
ife of f;

Scanned by CamScanner
 Software Risk,
; tt & Quality Assurance:
, eVeloped in.
how:
Se, leased from a vendor, or purchased
tain 'S
ers n “ontrols
d to “Nsure Sary
th at
used to
Manage support software.
' the su
ec, Pport software ia availa le for use for as
b
and support tools alo
ng with
Software tools useq in
develo, ‘
configuration control 5 Pment, espec: .
0 their1 identit; peci ally Sompilers and middleware should be placed under
release. ACS and Vers}
TS1On: +
* are included in the baseline data about each

hierarch Y Consistiting
of configuration items, components, and units.
_Another way of structur;
.
being d the entities ;
tities is i :
4 os and the other software a" of the interrelationships between the software
Support soltware, test software, and the o entities used during development and testing such as
, perating system.
A third method for structur; Penuees
process of building the software a is in terms of the intermediate products generated in the
(e.g., source code, document,
test data); compilation entities ae net such as: modifiable entities
different representations created a Support software); and configuration items (e.g.,
software An impo t € process of producing deliverables).
rtant aspec
”
t aural canwe
of confi: .
identificati on isaT the use of a formal naming convention for
each entity.

s naming convention, which typically uses a combination of mnemonic labels and version
numbers, should be applied to all components of a configuration item. ,
In establishing the naming convention, consideration should be given to system constraints such
as name length or composition. .
of the
Consistency in the application of this identification scheme is critical to accurate tracking
software engineering process.

Control)
5.6.4(B) Change Control (Configuration
of the
=> (MU - Dec. 15, May 17, May 18)
“oject
(Ee See
se cine ie Anancie
Set inc
cont ol
(Ret, sec. :(6)U
5.8.4
s may be
1s in
software lifecycle.
es Design or implementation change
Changes occur at all phas es in the efici sencies are identified in the design or
change, °F when
necessary if requirements
i emen t.
requir
em en ta ti on ap proach to a stable ign and requirements.
impl
defects that -e changes in the code or the des
defe require
of Testing may uncov er

Scanned by CamScanner
 4
Mgmt &
Configuration |
5-20 Software Risk, i
FEF sonware Engingoring (MU - Sem. 6 - Comp) st verify Peto
rmanes 3
the code, testing mu
e to the right version of
— Changes must be mad 5.640) Version Con
remaining software, and all associated dorvmentation mang
change and the integrity of the
updated to be consistent with the final code. . ies, failure
ee . reports,
A mechanism is needed to process change requests (€.8-+ process ang din,
throughout the development
for new features) from a variety of sources

operation and support of the software product. luate, and imp) a

to 4 def ini tio n of a pro cess to track, eva
end
This mechanism should ext |
e of the software.
change requests into a new version and new releas ‘of chan:
, Be Managemen, ang
meet the needs of all levels
Generally, no single procedure can . — Following
approval levels. straightf
include :
ded for processing changes -o Ap
The minimum activities nee change. /
Defining the informa tion needed
for approving the requested .
Av
o o
routing of information.
o Identifying the review process and ony
bj

the change.
.

o Describing the control of the libraries used to process 5 amentation, an4 . ° A: :

a procedure for implementi ng each change 7 the code, the doc
o Developing
the released software product. — Additi
tracki
Baseline Definition
impor
s Modification, improvement ; — Most
h or fix for error
neces
i Identify components tobe

s renee , - Itis.
;
Impact assessment buil
A change by authority as tot
C stated in Configuration ;
C Management Plan
oO = A 8
‘ u
N
. )
T'
;
N Code copied to , @
G development area
-: (
Modula and system test
. - dD
é. _4

Notity users of change ———-5.6.4(D)

| lau
. n

Fig. 5.6.4: Configuration Control Process

s :

Scanned by CamScanner
 m= S2M. 8 Com

a(c) Version Contro}

© be
ports,
S S8ty
=

With toola
ects which a the purpose of managing differ
re Benerated throughout the softwaent
re

ition, and

Additionally, version
> ° Control]
7 as wel]
tracking capal bility which he} as change control systems usually implement an issues/bugs
. rtan :
important issues. relateg With . each
‘PS the te, ‘am to
and every vont in one the status regarding all of the
Most of the version guration object.
necessary to build a ee Systems
Particular version create a change set of all th e
of thesoftware i changes which
respective i are

to the baseline configuration. °

A system modeling approach is used
to accomplish it. The system model cont
ains :
() A template reich contains a component hier
archy and a “puild order” for those components
which gives information regarding how the system must
be constructed,
(2) Construction Tules, arid

(3) Verification rules.

Now-a-days there are several automated approaches have been proposed to version control.

The basic distinction in those approaches is the sophistication of the attributes which helps in
building specific versions.

5.6.4(D) Configuration Audit

change control are the processes

which help user to maintain
Identification, ver sio n con tro l, and
uld otherwise be a confused situation.
sequence in what wo mechanisms only until generation of
even most successful control
~ However change is tracked by
Order).
ECO (Engineering Change

Scanned by CamScanner
 et Software Engineering (MU - Sem. 6 - Comp)
§-22 Software Risk, Configuration Mgmt & Qual Asuracg gg
What will be the way by which a software tea: m make it sure that the change has p.._
appropriately implemented?
The answer has two aspects :
(1) Technical reviews and
:
(2)° The software cee tion isaudit.
on the technical accuracy of the configurat i °
The focus of technica
ion object ini which
.
l revi .
modifications are done.
The e re reviewers assess the SCI (Software Configuration Items) for the purpose of determining
: consistency with other SCIs, omissions, or potential side effects. -
There is need to conduct a technical review for all but the most trivial = 5.7
A software configuration audit in general, complements the feehniee rove by the way of
assessing a configuration object for characteristics which are usually ignored in the procegg of
review.

The audit asks and answers the following questions :

1. -Has the modifications menti ioned in the ECO , ; ape - .
been made? Have any additional modifications
been incorporated?
Is there any process of conducting technical review for asses
sing technical correctness?
Has the software process been followed and
is the app lication of software engineering
standards done properly?
4, Has the change been focused in the SCI?
Have there is specification of change
change author? Do the change is reflected date and
by attributes of the configuration object?
Has there is implementation
of SCM procedures fo r noting
the change, recording it, and
reporting?
i 6.Has there ig Proper updations
in all related SCIs?
- Sometimes, the audit questi
ons are asked as an integr
al part in the process of tec
However, when.SCM is hnical review.
a formal activity, the qua
lity assurance sroup conduc
audit separately. ts the configuration
-

currently built version.

5.6.4(E) Status Reporting

- Configuration Status Reporting

(CSR ) which is also know
that gives answers of fol n as status accounti
lowing questions : ng is an SCM task
1. What happened?

2. Who did it?

3. When did it happen?

reer reenter
Scanned by CamScanner
 of determining _ Additionally, generation of a CS
information regarding important B report is done rogulatly and is intended to give latest
S to management as well as the practitioners.

he process o¢ 0.5.7.1 Writ : = ma

ent (Ref.sec.57) (10 Marks) |
- Software Quali ity Man i ‘
; achieved, ? so thatat the users“gement is a method that guarantees that required level of software is
are Satisfied by its performance
odifications — . The process involves quali .
tien S quality assurance, quality planning, and quality control.
- - i
concep it pauradea a complete understanding of Software Quality Management and illustrates
the various steps involved in the process.
gineerj
Ting : :
- Botimiics Quality Management
will make sure that the necessary level of quality is achieved by
late correcting the improvements to the product development process.

and, - The main motive behind the SQM is to develop an ethnicity within the team and it is seen as
everyone's liability. .
it, and : - Software Quality management should be independent of project management to ensure the self-
determination of cost and schedule adherences.
- Its effect directly impacts the process quality and indirectly affects the product quality.
Ww. : .
ati 5.7.1 Activities of Software Quality Management
ion
4 Activities of Software
Quality Management
ited
the 1. Quality Assurance

2. Quality Planning

3. Quality Control

re Quality Management
Fig. 5.7.1: Activities of softwa

> 1. Quality Assurance

quality at organizational level.
t building measures and standards ffor maintaining
QA aims a!

ee
Scanned by CamScanner
 TB sora Engineoring (MU - Som,
6 Com Configuration Mgmt& Quai;
5.24 _Sotwaro Bi
> 2 Se
Quality Planning
To chooso applicable procedures ; .
/actions and standards for a certain projecject,t, changes can
required to develop
he don ey
a quality plan,
> 3, Quality Control
— It will make sure that most excellent practices lowed b:
and standards are followed by the 5Ofty,
development team to maintain quality at,
products. defect f
~ tae
Quality of software will refer to software which sate
is realistically error o r defect fre € and whieh‘
delivered in time and within the allocated budget. 8

— Italso meets the requirements and/or expectatio

ns, and is maintainable,
~ ‘ies
In the software engineering term, software quality wetitiiee d
will indicate both the func
func
ti
tional ality a4
structural quality.
The different activities which are invo
lved in the Software Quality Managemen
t are ag follows
5.7.2 Software Functional Qua
lity

It indicates how well it satisfies a given function/design,

based on the functional requirement, or
Specifications.

5.7.3 Software Structural Quality

It handles the non-functional requirements that maintain the deliver

ance of the functional
requirements, such ag robustness or maintainability, and the extent to which the software Waa
developed properly,
.
5.7.4 Software Quality Assurance

Software Quality Assurance (SQA) is a set of activities to ensure the quality in software
engineering processes that finally results in quality
software products. The activities establish and
evaluate the processes that produce produc
ts,

5.7.5 Software Quality Control

Software Quality Control (SQC) is a set of

activities to guarantee that the quality in softwa
re
products should be maintained.
~ These activities focus on determining the errors in the
actual products produced. It deals with
product-focused action,
- The quality of software has improved signi
ficantly over the past two decades,
- The reason behind is that companies are using new techn
ologies for software development process _
such as object-oriented development, CASE tools
and. the testing technology such as Automation
etc.
- The software requirement should replicate the characteristics of the product that the
client
wants.

ud
Scanned by CamScan ner
 aeS eee
a alee ag = a
ura
ye 7
¥ 4 sm
:
es -" ¥ =

.
hit Tie ia: y
Ys te: .
‘all (Mu . Som
me Engineering | eS 7
assuranc,
5.
1
| Garr ;
Ware quality attri
ae PD 25 Softwa ‘2
ro Flick, Configuration Mgmt & Quality ASSUranes
The soft
- ,
specified and measured in tebuten such as mainttaj.
i vs
1 be dong i
abtil be accur y
itately t Ps
stages of TMs of sofware d ati, Usability, relicanno
- “At the early may h Proje ct it jg very ¥ Management,
Therefore, it }
difficult to 4 lefine a complete software specification
ali ty expectations,‘appen that software conforms
quali ne
| get their ee
to its requirement, but the users don’t > 2
° Software - Software quality man gement ia divided intgite Lo
Tree main categories 2
d which ; one three categories \
is ftware quality manage ot
q

\
ality and

(3) Quality control |

lows :
Fig. 5.7.2 : Main
. . categories of Softw:
‘are Quality Management
4 Quality assurance
ents or
The development of organizational Procedures ~ and standards that leads to high quality software-
4 (2) Quality planning
pr¢
The selection of appropriate proce a
: d) ework and used for a specific
i, lures and standards from project fram
‘ional software project.
was :
4 (3) Quality control —
- ards. the process ensuring g th that software development follows the quality procedures and
: It defines

provides an independent test on the software and software development

. .
Quality management
ec
-
are _

process. It ensures that project deliverables are consistent with organizational standards-and
goals. :

5.7.6 Software Quality Challenge

ment? (Ref.sec. 5.7.6) (5 Marks)

Q.5:7.2 What are the Challen
is free of bugs,
will never guarantees that the software
In the software industry, the developers cts. This difference
can give guarantees about their produ
+ whereas industrial product manufacturers
is due to the following reasons.

(3) Product Complexity an

modes the product allows. Generally,
of oper, ational
is the number
Product complexity binations of its machine
, -
: rm it s few mo des of operations with different com
al product pe
industri
settings. Therefore, assuring the operational
ns of ope rat ional possibiliti es.
- ckages allow millio: industry.
to the software
potential correctly is a majortask
Gofiwane Ps

Scanned by CamScanner
 Assurane, “za software
5-26 software Risk, Configuration MGT 5 CUSTY a, - Sohne
[EF sonware Engineering (MU - Sem. 6 - Com)
; . = z
(b) Product Visibility
ai ' een
— Generally most of the defects in the industry can be detectediE ; a
© 7
- Also the absence of a part in an industrial product can be
level com
5.7.7 Process Quality Product
nad hehe pe . - = ®
la.sz3 Evan the concpt of Quaty roses nce aa
_ Quality of oe norm He ttn ella and the process is enhanced till the prope: _ One
quality level is reached. .
. (a) Te
— Fig. 5.7.3 illustrates the process of quality assessmént based on this approach. (b) ¢
prcdnetia Process and product
— In manufacturing industry there is a clear connection among g Wincludes!
of software engmects.
quality. However, quality of software is highly subjective to the skill
like maintainability, reliability,
— In addition, it is hard to determine software quality attributes,these attributes. (1) Proc
characteristics affect
usability, ste, and also to tell how process
has a considerable demang (2) Aud
— However, from the past experience it has shown that process quality
on the quality of the software. : (3) Gui
aw Processe
- Process quality management have the following activities :
. os a) &
(1) Essential process standards.
(2) P
(2) Monitoring the development process.
(3) Reporting the software. : : . (3) C
cal
.pi Develop. t

(5) ©

: (6)
Br (7)

Fig. 5.7.3 : Process based quality assessment

5.8 Software Quality Assurance

2.5.8.1 Explain the concept

of Software Quality Assuran |
- Software Quality Assurance (SQA) is a group of activities to guarantee that the quality in
software engineering processes is maintained.
It make sure that developed software project would meet and complies with the predefined or
standardized quality specifications.
- SQA is an ongoing activity in the Software Development Life Cycle (SDLC) that consistently
checks the developed software to guarantee that it should meet the desired quality standards.

Scanned by CamScanner
 t
'& fo MwAre deve opment ind
Qre tent
- With
i sqq ea ty in, f methog ‘Ustries,

es i * througho out tion of — Projec°s to tent the software. Rather

QA 7 Nt a So} are dl.
- § Senerally Mire Ctivities eT level,
quality puig; Works on o i *Y standa “OVeg into the n
level only if the present/ ortor
Ore np}
ex, 7 Binecring
Tocesses have been €cutio, ” Strategiog
. Stand, ‘ards that fet in ding

Produce

bility, ¢ Itincludes the following

(1) Process definition and accom}; , Hi

nand (2) Auditing "Mplishment
(3) Guidance
@ Processes co |
uld be
|
||
(1) Software Deve
lopment method
(2) Project Manageme |
nt
(3) Configuratio | i
n Mana gement
(4) Requirements {
Deve lopinent/Managemen
(5) Estimation t

(6) Software Design

(7) Testing, ete.
5.8.1 Components of SQA System
en

SQA system always combines a broad varie

ty of SQA components. These components can
classified into the following six classes. be
‘
(1) Pre-project components
- This guarantees that the project commitments have been clearly defined taking into account the
required resources, the schedule and budget.

- The improvement and quality plans have been correctly determined.

(2) Componen tso f project life cycle activities assessme!
nt
ig composed of two stages: the development
life cycle stage and the
- The project
life cycle is
operation-maintenance stage.

Scanned by CamScanner
 ration & Ou:
6 Comp) 6-20 _ Software ae Se cemmeain ee
EEF sonware Engineering (MU - Sem.
Reviews, en pert Sota
identify : aa eet Me
The development lifo cycleJe stage components classes
tb
components are divided into the following su
testing. e include 7
the oper ation-maintenance phas ‘ ®PeClalizeg
The SQA components used a eahietset t life cycle components, which are applied taint,
i nance components as we:
mainte as d tanks.
nce
for functionality to improve the maintena
ment
e nen oect isavotoida nce and imp rove
(3) Thmpo oe orth camp
re def remove or at least minimize the rate of errors, baseq ny

organization’s SQA experience. |

agement |
| (4) Component s of sof twa re qua lit y man (2) 0
ging the development ona
s clas s of com pon ent s dea ls wit h a number of goals, such = the mana
Thi nly avoid or Seats,
nan ce of acti viti es and ear ly man agerial support actions that mai
mainte
ces.
schedule and budget failures and their consequen

(5) Components of standardization, certification, and SQA system evaluation

~ These components adapt international professional and managerial values within the institut,
— The main motive of this class is to use international professional understanding, enhancement of
the organizational quality systems with other industry, and evaluation of the achievements of
quality systems according to ageneral scale.
-— The different standards can be categorized into two main groups: quality management standards
and project process standards. .

(6) Organizing for SQA - the human components

+ The SQA base includes managers, testing professionals, the SQA unit and the resources involved
in software quality such as SQA trustees, SQA committee members, and SQA meeting
members.
Their main aims are to make the first move and maintain the
implementation of SQA
components, defect deviations from SQA proce: dures and
methodology, and advise some
improvements.
,

5.8.2 Pre-project Software Quality Assurance

These components help to improve

“oleot quality assurance ? (R 2 + temas)
the groundwork task taken before ing a project. It ey
includes : ; =
(1) Deal Review ;

(2) Development and Quality Plans

(1) Deal Review |

~ _ Software is developed for an agreement negotiated with a dlient or for an internal order to build
up a firmware to be fixed within a har
dwa re product,

Scanned by CamScanner
 Act drag€Vie
, Ww actions Ma
oe
Clarification ru, Tevi, CW acti functional specification,
Melude in depth exam
eal: ination of
Review of
6 ds the Projects
Sessmen tof § Chedule

the
© Profegg: ou
“Ssional Tego,Urceg ‘ee
abi;"equirement e stimates,
Evaluatio,, Stomer ility to on, " out
Hon of develo PMent Tisks
“AP ACity ty furen Ifill hig ob
the planned project,
7) Development and Quality Pla ligations,
Ns ‘
ind - After signin :
| oa
& the Softw. } oe
the same o; . . 7 develo
iSe
eae T8aniza on, a devel PMent contract with an '
activities are Prepared, “oPment pl, . an industry or an internal department of i - a

- Most
ost of the time
ime, , iti takes many mo a"
: nths
his phase, fetta gd,jetw: ®en the contract submission and the signing of the nH |Z A
as staft availability and professional capabilities may
The plans are then revised to refl
ect the changes that occurred in the
interim.
(i) The main problems treated in the project development plan ;
(1) Schedules i

(2) Important manpower and hardware resources

(83) Risk evaluations

(4) Organizational problems : team members, subcontractors and partnerships

(5) Project methodology, development tools, etc.
(6) Software reuse plans.
the project’s quality plan
(ii) The main issues treated in

(1) Quality aims | 7

d final project stage
(2) Criteria for initi tion and validation
activities.
he du le d co nf ir ma
ets, an d
otes other sc
(3) Lists of reviews,
a

5.8.3 Metrics

Scanned by CamScanner
 ke
= Ss ‘oftware Engineering ration Mgmt & Qual
(MY - Som. 6 -Comp) 5-30 en Softwaro
ofA FS, Risk, CE jul
aera Asay ra
Uli Ang Ne
Software metrics can be classified into three categories '
Classification
of Software metrics

2. Process Metrics

3. Project Metrics .
Fig. 5.8.1 : Classification of software metrics >t
> 1. Product metrics
It describes the character of the product such as volume, complexity, design
features, Performancs
and quality level.
> 2 Process metrics

These characteristics can be used to Progre

ss the development and maintenance activi
software.
ties of the

> 3. Project metrics

~ This metrics describe the project characterist

number
ic s and implementation. Examples
include the
of software developers, the staffing pattern over the life
schedule, and productivity, cycle. of’ the software, cost,
Some metrics belong to many
categories. For example, the
in-process quality metrics
are both process metrics and Proj of & project
ect metrics.
Software quality metrics
is a division of
Product, process, and Proj
ect. These
metrics than with Project
metrics:
Software quality metrics
can be further divided into
following categories :
"| Other categories of software
quality metrics
5.8.4
1. Mean time to failure
|

2. Defect density
| :
3. Customer Problems ::
}
a,
4. Client satisfaction
_

Fig. 5.8.2 : Other categories

eSsta

of software quality metrics

> 1. Mean Time to Failure

Scanned by CamScanner
 pefect Density
p .
A je als with the errors relatiye to the a0
It . Ware in poitit, ete.
«ey it measures code quality per unit, This mot *i2e articulated na tinea of cade or function P™
Tic jg “ .
customer Problems Used in many businesa software system?
3
measures the problems that custo
gtomer’s point of view tow neounter when using the product. It contains the
Mery e
ards the
cui prob] €M area of the on-defect
d problems together with the f software, which ineludes the &
orient de ect problems,
Client Satisfaction

a* sont =satisf
oy ate d is f Tequently measured by client survey data through the following
action
- five-point °

(i) Satisfied
(iii) Neutral
(iv) Dissatisfied
(v) Very dissatisfied
Satisfaction with the
quality of the product
an
its specific extent is usually gained through
: many
‘ :
i

methods of client surveys,

_ Base d on the five-poi
point data, many sitet?
metrics with minor changes can be constructed and used.
For example
‘4, Percent of entirely satisfied clients
9. Percent of satisfied clients |
3. Percent of dis-satisfied customers
4. Percent of non-satisfied customers
- Usually, this percent satisfaction is used.

58.4 In-process Quality Metrics

In-process quality metrics is the metric which track the fault during the arrival of machine
testing for organizations. This metric includes :
- Defect intensity while doing machine testing.

- Defect arrival method during machine testing.

- Phase-based defect removal pattern.
- Defect elimination efficiency.

585 Defect Density During Machine Testing

is
- Defect velocity during machine testing (testing after code is integrated into the system)
velocity in the field.
associated with the defect

Scanned by CamScanner
 ' ; Z software Enginee
Es. ng! 9 ( - - p) 5 k, Co nfiguration Mgmt &Q ual lity
| ;:|
Software Engineorin MU - Sem. 6 - Com 32 Software Ris! a22Uran tM back
- Ifthe higher defect velocity is established during testing then it is a notification that the POR iraee
has practiced higher error injection during its development process. _ Fix resp

- i the similar
It is generally useful to monitor succeeding releases of a product in i developmen, q ’ _ Percent :
organization. : . Fix qua

5.8.6 Defect Arrival Pattern During Testing

ix Back

Whats Dofect Arrival Pattom 7 (Rot. sec. 5.8.6) :

a te) — 2 Mera
ooo _ F Hixbe
[@.5.8.4
* Defect arrival pattern during machine testing ‘identii
. os tisa
- ' The overall defect rate during testing will give the summary of the defects. whe:
- The different methods of defect arrivals in the project will give additional information about - a
different quality levels in the project.
. /
— It includes the following : ; - Back
: : a
1. The defect detection or defects reported during the testing phase by time interval (e.g.,
Week), - =
Here all of which will not be exact defects. back
j 2. The pattern of applicable defect arrivals when problem identification is done on the Teported 5.8.10 Fix ¢
g.4 problems. This is the true defect.
Fix
3. The pattern of defect backlog overtime. This pattern is required because development ~ hy
organizations cannot find and fix all the identified problems instantly. ; : Pp
4. If the defect backlog rate is large at the ending of the development series in the Project
and a - Ai
} lot of fixes have to be incorporated into the system process, the consistency of
the system =
(hence its quality) will be affected. . pe
5.8.7 Phase-Based Defect Removal Pattern . 5.8.11 De
- This is an expansion of the defect density while doing testing.
- 4
- In addition to testing, it measures the defects at all stages
of the development cycle in the project,
: counts the design reviews, code reviews, and do verifications
before testing.
- °
H - Because a large percentage of development defects is associated to
design problems, conducting _
j formal reviews, or functional verifications to improve the
defect elimination ability of the process :
; at the front-end minimizes errors in the software.
7
- The phase-based defect elimination reflects the overall.
defect elimination skill of the development
process, . .
~ With consideration to the pattern for the design and
coding phases, in addition to defect density, ;
many development organizations use metrics such as inspection coverag ~
e and inspection effort for
in-process quality management.

5.8.8 Maintenance Quality Metrics

Following are the fixes that can be carried
out to remove the defects as soon
as possible with _
outstanding fix quality. ,

Scanned by CamScanner
 software Engineering MU. 5
2m. 6.
Softy, Fix backlog and backs
are _ Fix response time
%
opment _ Percent offending fixes

_ Fix quality, ,

aea 9
er FIX iBack log and Back,
teria) | _ x
Fix backlog is
: 88s0ciateg g Man
Age Ment Index '
identified Problems, ie Velocity
- :
Itisasim
2,
ple tally a f ident; of
bug 8rrivaly and th

bo
about _ When izisame is useg j. t PPblems ‘ * rate at which fixes are done for
© fi Stay beh ‘
organizing the Continuat; OTMAt of ch Y behind at the end of
- Backlog M anagement IndeOMx Proces
( MD s,; art, the chart reach month or each week.
“AR Provide significant information for
- If BMI is larger ¢p, 18 used
ek), os
| backlog is improveg, 0 100, it me, @0s the backlo
ANE theb
g is mi: ee Current and unresolved bugs.
fea | 7 Fix Quality
mz, MI is less than 100, then the

. - Fix quali
. ty or the numh er of fi
nt phase in the SQA. : ~
; : aulty fixes 18 another important
quali y metric for the maintenance
qualit

la 7 Ae sawed it did not fix the identified prob]

ive fixes ®m, or if: solved the original problem but created
0 a newbug. For complex software, defect
are harmful to client Satisfaction. The metric of

| 5811. Defective Fix

- (Trace it in the month it was found or trace
it in the month the fix was given, The first is a
customer measure; the second is a process measure.
Oo
- The distinction between the two dates is the period of the defective fix.
- QA helps to make sure that the development of high-quality software is in progress.

- SQA practices are implemented in most types of software development, in spite of which
used. In a broader category, SQA includes and
fundamental software development model being .
technologies to test the software.
. implements software testing
s test for quality in each phase of
ec ki ng for qua lit y af terconclusion, SQA processe
- Rather than ch software development process mov
es
sof twa re is com plete. With j S QA, the ity
development until the phase complies with the requ
ired qual
only once the current/previous
into thep next phase
. ‘ that help in building software quality
standards.
ede the
industry an 1SO 9000 and Capability
ks on one or moregies. These stan
entation strate
= Siegel
sya: + a nplem CMM.
guidelines and im:
Maturity Model Integra e

Scanned by CamScanner
 er Software Engineering (MU - Sem. 6 - Comp) 5-34 __ Software Risk, Se
mt
eatenMoma Ge
Hit
Eitan
mesures
5.9 SQA Processes
a
0.5.9.1 ain SQL Process with its bonofits. (Ref. sec. 5.9
— Processes include :

1. Software Development Methodology

2. Project Management

3. Configuration Management
4. Requirements Development/Management
5. Estimation ,
6. Software Design
7. Testing
- Once the processes have been defined and implemented, Quality Assurance has the following
responsibilities :
(1) Identifying weaknesses in the processes,

(2) Correcting those weaknesses to continually improve the processes.

- The quality management system under which the software system is created is normally
based on
one or more of the following models/standards: -

(1) CMMI

(2) Six Sigma

(3) ISO 9000

5.10 Benefits of SQA

- Monitoring and improving process.

- Make sure that he standards and procedur
e are followed.
- Prevents the significant problems from
occurring.

. Syllabus Topic : Software Quality Ass

urance Task and Plan

_ 5.11 Software Quality Assurance Task and Plan

@. 6.1List
1.1 Various Acvty In SOA, (et
see. 6
Q, 5.11.2 _ What are the differ
quality assuran
entce idelines and d
5.11.1 Test Management Reviews and Audit

@ Management Review
~- Management Review is also known as
Software Quality Assurance or (SQA).

Scanned by CamScanner
 eu - Quality Assurancg © is;
3 ™etho,
Marks / regular Procegs which a .
f acts. ies pl e mt & Quality
j Assurance
jo o- woe oener Words, Quali Plan © 8aftwarg
As Ady defing din nt © guar these thes related work products, eS
ri Way, SUrance kes 7 8 8ys: al
tho Project manager follows the
- Audit: An audit ig Te the Toot
. e
the regular Process wag

lowing

don

? 1. Develop SQA Plan

are developed.
- During project planning, Test. Manage
r makes an § QA plan where SQA audit
periodically. is scheduled

In the SQA Plan, the Test Manager should do following:

Identify the role and 1 responsibilities of SQA team

LP LEP PP I FP
List of the work products that the SQA auditors will review and audit

ME EP EF MP ED A SF
tasks
Create the schedule to perform tha SQA

sibility of SQA
Fig. 5.11.2: Role and Respon

a
Scanned by CamScanner
 & Quality Assuran, _
;Configuration Mgmt
5-36 Software Risk
BF sonware Engineering (MU - Sem. 6 - Comp)

1. Identity the role and responsibilities of SQA team work. Fach

says uality of his or her
for the 4
- Ina project team, every member must have responsibility
meets the QA criteria.
person has to make sure their work Without QA, no
ys the maj or role in the project.
~— of. p persons vo,whothe pla:Test Manager has to make clear the responsibility
The SQA team is the group group of.
business will run successfully. Therefore,
‘of each SQA member in SQA plan as below :

o Review and evaluate the quality of project activities to meet the QA eriteria
and engage
ent board and project teams to assess requirements
© Coordinate with managem
in project review and status meetings.
5.A2_S
o Design track and collect metrics to monitor project quality. @
expectations.
e the product meets the customer
o Measure the quality of product; ensur
:
auditor will review and audit
2. List of the work products that the SQA
5.12.1
th e work products of each Test Man
agement Process.
The Test Manager should list out ali
tasks such as
auditor ¢: an access to perform SQA
Define which facilities or equipment the SQA
"process evaluations and audits.
3 Create the schedule to perform the SQA tasks
with special
e the tasks to be performed by SQA
In this step, the Test Manager should describ
importance on SQA activities as welll as the work for each task.
tasks. Normally, the SQA schedule is
Test Manager also creates the scheduling of those SQA
driven by the project development schedule.
are
on to which software development activities
— Therefore, a SQA task is performed in relati
taking place.

@ Define the standards/methodology

process, ‘following steps are taken:
To review the Management activities against the standards
defects from the management process,
Define the policies and procedures intended to prevent

Document the policies and procedures,

Inform and train the staff to use these processes.

ess
5.11.3 Review the Proc

Review project activities are to verify co

mpliance with the defined management process.

Scanned by CamScanner
 12 Quality Evaluation
Standards
uch as
» Soft
ware qual ity i
role played by i
software in ou ting great im portan: i 7
r ine, day
ies lives, ce, mainly because of the very vital

ecial
ISO/IEC 25000 standard.
a
a

- Although numerous certifications for software quality exist (e.g., ISOME

le is
C15504, CMMI, etc.),
there is little evidence to suggest that compliance with any of thesé stand
nas

ards guarantees good

software products.

are Critics have gone so far as to suggest that the only thing these standards guarantee is uniformity
of output and thus, may actually lead to the production of bad products.
be based on direct evidence of product
- Consequently, the idea that s oftware evaluations should
izations are
Therefore, a growing number of organ
more widespread.
attributes is becoming well as
quality of the p: roducts that they develop and/or acquire, as
becoming concerned about the
the processes.

513 SixSix Sigm

Sigma — prog = (R08.
Taree
619) eso
(eMarie)
— ora sigma 7 Bx
Le a ee a 4 a (4 Marks)

on developing as well as

Six Sigma is 4 €

delivering error free PT

Scanned by CamScanner
 Er
{ got are
- :
IEP sotw
Software Engineering (MU - Sem. 6 - Comp) k, Configurat ion Mgmt & Quality Assy Ir 3 °
5-38 Sonware AS
5.13.1 —s a qgnat k
Characteristics of six Sigma
Va
— Six Sigma's aim is to deliver the product with time and with efficiency, th /
ae name meee hy 4
Ae
at ¢
increasing the customer satisfaction
and by delivering what the cu
— Six Sigma follows a methodology which is structured, les for the participants,
and it defines roles 5
— Six Sigma is nothing but a data driven process, and it also requires fo P a 6. pneu?
correct data collection for the
Processes to be analyzed.

— Six Sigma is about to put the results on economical Statements. custo

hich inetua » & I
- Six Sigma approach is business-driven, multi-dimensional
structured which includes : pesi
o Improving Processes
o Lowering Defects Mai
.
© Reducing process variability B
o Reducing costs 5.13.3
. . Fo!
© Increasing customer satisfaction
o Increased a? 7
.
o Profits a

~ The main idea behind Six Sigma is if anyone can evaluate _

how many “defects” can have ina
i
process, it can be thoroughly figure out how to minimize
them and can go closer to “zero defects” :
as possible and particularly that means 99.9997% perfect.
.
5.13.2 Key Concepts of Six Sigma
5.13.
Six Sigma revolves has a few key concepts.

Key Concepts of Six Sigma

1. Significant to Quality

2. Defect

3. Process Capability

4. Variation.

5. Stabla Operations

6. Design for Six Sigma

Fig. 5.13.1 : Kéy concepts of six sigma

» 1. Significant to Quality

Attributes are most important to the customer.

> 2. Defect

Failing to deliver what the customer exactly wants.

Scanned by CamScanner
 pftware,Engineering (M
Ue
ali Assura
Jality
a)
£ Process © Sem, .
4 3 *Pability

what kind of Process’

thereby hy 4
4 Variation can delive, a
Pecti
mt & Quality Assurance i
. . | what the customer Be &8 an d fe,
IPpants,
> be Stable Operation, els,
tion f :
or th,
gnsuring that the ad
customer exactly Wants, are sho Ud
; Design for Six c: © cong:
af Sigma ‘stent, Predictable Processes to improve what '
Designing to meet customer
* * . Deed,
Mainly Six Sigma focuses on
| re ability,
* and Procegg apab;
i 513.3 Benefits Of Six Sigma
| Following are the
~ reson and th en on UPgrading the
process ca:
benefits Of Six bili
g;
— Generates Per
sistent Suc ~
cess,
- ' Sets a goal
for everyone,
/ - Improves value
to customers,
_. = Improves the
rate of; ™provement
,
- Promotes learning.

| 513.4 Elements of Six Sigma

, j There are three main
|
elements of Six Sigma
:
Element of Six Sigma

. (1) Customers

(2) Processes

. (3) Employees

Fig. 5.13.2 : Elements of six sigma

% 1, The Customers

inly define quality.

competitive prices, prompt delivery, good
, on
rmanceec consistency,
Gafeqesmiely expect perfo
The customer always .
tion an'
stomer
service, omers need to gain cu
| to offer what the cust
S
an s e
th at is very importan'
ite
Th is me
satisfaction.

Scanned by CamScanner
 ep Software Engineering (MU - Sem. 6 -
Comp) 5-40 _ Software Risk, Configu! aMoms cual Asura
LY
> 2. Tho Processes
~ The central aspect of Six Sigma is to their metrics and measura,
. define the processes as _
- Ina software industry, the quality be always seen from the customer's viewpoint. ,
has to be a ive and processes, one can fing ou
~ By understanding the lifecycle ct
from the customer's perspe
what the customer is seeing and feeling.
> 3. The Employees

- An industry must involve all its employ . A process.

ees in the Six Sigma
- Company can provide opportunities and incentives for employees to concentrate on their talent,
and ability to satisfy customers and ultimately the company.
- The important factor in the Six Sigma is that all the team members have proper roles and Corregt
objectives.

5.13.5 Responsibilities/roles In a SIx Sigma

There are some more responsibilities/roles in a Six

Sigma program, which are as follows :
Responsibllities/roles In
a Six Sigma

1. Leadership

3. Team Leader ~

4. Black Belt

5. Master Black Belt

Fig. 5.13.3 : Responsibilities/roles in a Six Sigma

> 1. Leadership
e
A leadership team always defines
the goals and objectives in the Six
Sigma process.
> 2. Sponsor

Six Sigma sponsors who are high-lev

el individuals and they understan
are committed to its success, d the Six Sigma processes and
.
> 3. Team Leader

It is an individual respon
sible for managing the
work of the team member
mediator bet ween the Project sponsor and the s and also acting as a
team members.
ie

> 4, Black Belt

~ The person having this belt has

gained the highest skill ] eve
l and also he is an expe
in various techniques. rienced expert

Ms ee
Scanned by CamScanner
 As per the Six Si
|
| through inte Mal ®BogProgram ~ =
i trainin acti » the indi; ‘ Sotty,
— Vidu
Stivitieg Sang mo Risk
‘y
|
5. Master Black R elt hag th
designat Led my A SsuTrAanon
{ _ Aperson who dealg With a, te * &peri a."On * Beveral mpleted and and gone
Black Belt haa completed
a Brojecta.
This may be ©quivalent to th ™ or ityle
Ade
. . 9 ie hi; DB;
| ||
but {i
At the
conclusion of ¢ he design “le Dlayog * 8 not a ¢ ir
resistance issues, ect member of the team itself.
;
j the oach for ™m or
d reg); Age, you shoul ® technical and complex projects
scope of the Project tochuay
| buaents,
on, Y,tim,
Ing
ou shoul . °w who the
. Wd also h ave Customers or end-users are, their
" talents ~~ a cle:
Ines,
| a. Syllabus T Ie:Software
nstraints, and Nett
Reliabitity ming
correct oftware Reliability tana

Now to better understand consider a :

elapsed p rocessing hours. program X is estimated to hav: e a reliability of 0.999 over 8

That means, if there i a total of 8 hours of

i need . ° —_ program X 1000 times and needs
elapsed processin correctly (without any of the
7 e (execution time), it is possibly execute
failure) 999 times.

In software reliability one important question is: What is meant by the term failure?
e quality an d reliability, failure is
In the context of any type of discussion regarding softwar
requirements.
considered as non-fulfillment of software ng
ures can be only frustrati
r, eve n wit hin this defi niti on, there are several aspects. Fail
- Howeve
or terrible. need weeks or even
wi th in sec ond s, whereas so me other may
failures
It is possible to correct some
eration of
months to correct. de in on e fai lure may leads to gen
correction ma
is complicated,
- Farther if the iss ue
other errors.
lity
Me as ur es of Re liability and Avallabl e the mathematics regard
ing
5.14.1 ility tried to ext r apo lat
oftware reliab
re li ability.
of software
e aspect of s'

- Early work in th h e calculat

ion
theory for t
hardware reliability

Scanned by CamScanner
 Quality Assurangg
nfiguration Mgmt & =e
5 42
re Risk, co ry
* SoftwaSa
-U
Software Engineering (M Sem. 6 - Comp)
- e of wea,
er
—— ne on failure becaus
ated reliability
- The e p prediction of most hardware-rel ical wear such as the impact o¢
instead of failure caused by design defects.
; us e of phys! retail failure.
- In case of hardware, possibility of failures aap ared design-re
temperature, corrosion, shock are more to software can be
likely a8 d, all of the failures regarding
Unluckily, the reverse is true for software. Indee there
,
is no any scope of W
ear.

traced to design or implementation probl since failure) is 3 simple measure of

ems; ime- between-
In case of a computer-based system,
MTE (meant
reliability.

TBF = MTTF+MTTR
where

MTTF mean-time-to-failure and

MTTR = mean-time-to-repair
ure in comparison with other
Number of researchers consider that MTBF is a extreme useful meas
quality-related software metrics.
: ith failures; they do not have to do
Straightforwardly, end users are practically concerned wi
anything with defect count.
Since each defect which has been contained within a program do not
;
has imil ilure
similar ate ra
ths
sum of all the defect count gives very little indication regarding the reliability of
a system.
We will consider a computer-based program that has been in operation for three thousand
processor hours without any kind of failure.
Several defects in this computer-based program may not be detetted for tens of thousands
of
hours before their discovery.
In such case the MTBF of those errors might be thirty thousand or
even sixty thousand processor
hours.
.

Remaining defects, which are to be yet

undiscovered, might have a failure rate
or five thousand hours. of four thousand

Even though all of the first category of

errors (having long MTBF) are remove
software reliability is minor. d, the effect on
But, MTBF can be considere
d as problematic for two rea
sons :
(1) It estimates a time spa
n in between failures, but
not able to provide projec
and ted failure rate,

ife span even if that is not 5.1

Another measure of reliability is FIT (failures- what it implies.
. in-time), It ; .
failures a component will have -In- .
It is a statistical me
over one billion hours of operation.
OS Aen

Scanned by CamScanner
 Software avai] abil;
requirements at g .- *8 noth;
Siven
Ant
Availability _
Point ,. ;ngn time
bu
tt
he Probap; : Mratic,
. = ( and j ‘lity wh: tnMamt & Quality Assurance
The sensitivity ofMTR 7M 8 defing, " ich n Progr,
_
_—
The availability measyp
F reliabit; lity ou
*MTTR yy 100%,
; "im ia operating as per the
re can be i measure of the ma;,_. 15 Cong} “re is nim
“untainabitity Idereg 8 itt ilar to MTP ang
: of £RWare © bit more te MTTR,
i i NBitive
asure of
i Yilabus Topic ; Form “ompared to MTTR, an indirect
|i 45 Form al Tec hnical Review = Tec nical Review (Im
5

other

to do

and

of

(5) To create more manageable project.

or
The F cnnial Technical Review is used while providing training and it is also used as an example
for junior developers to study different ways for software analysis, design, and development.
The Formal Technical Reviews is a class of reviews that contains walkthroughs, inspections,
round-robin reviews and other small technical assessments of software.
Every Formal Technical Review is performed as a meeting.
only it
Technical Reviews is planned, controlled, and attended in correct way then
If Formal
becomes successful.

515.1 Steps In FTR => (MU - May 18)

_ Te ety.”
(Ret, sec. 5.15.1) EES
I

-_ eo
. The review meeting by cons ider ing the following |
conducted
uld bepetn
~ Every review meeting sho een $10 5 people ghould be involve in the review.
fpeople $
o Involvement ©
lita
>

Scanned by CamScanner
 ration Mgm t & Quality Assuran,ance
5-44 Software Risk, Configu
ker Software Engineering
i (MU -- Sem . 6 - Comp) but it should be very short.
Ag
ion should occur
o Advance preparation : Advance preparation tion
in this
can be spent in
the most 2 hours of work for each person
prepara .
g should be less than two hours.
© Short duration : The duration of the review m eetin .
through are conducted for modules oy
ign,
Rather than attempting to review the entire design, walk
for small group of modules. ponent to be reviewed). The review
focus of the FTR is on work product (a software ° m:Oe dees
The
le! ; a
eon sa. Th copies of produ
meeting is attended by the review
iew leader, all reviewers an
ing i :
The :
review leader is responsible for evaluating the product fo
material are then distributed to reviewers. socisl, wit

The producer organizes “walkthrough” for the product, explaining the m

ini ater. , le e
° s
reviewers raise the issues based on their. advance preparati ion.

@ Review Reporting and Record Keeping

:
During the FTR, a reviewer (the recorder) actively records all isgues that have been raised.
These are summarized at the end of the review meeting,
and a review issues list is produced. In
addition, a formal technical review summary report iscompleted.
A review summary report answers three questions :

1. What was reviewed?

2. Who reviewed it?

3. What were the findings and conclusions?

The review summary report is a single page

form (with possible attachments).
- It becomes part of the project historical
re cord and may be distributed to the project
leader and
other interested parties,

~ The review issues list serves two Purp

oses :
(1) Identify problem areas within
the product and
,
(2) Serve as an action item
checklist that guides the produc
er as corrections are made.
- An issues list is normally att
ached to the summary report,
- You should establish a follow
-up procedure to ensure
that items on the issues
properly corrected. list have been
|
~ Unless this is done, it is
possible that issues raised
can “fall between the cra
— One approach is to ass cks.”
ign the responsibility
for follow-up to the
review leader

eee .

Scanned by CamScanner
ity Assurangg
——as,

ry short, At

rs.

modules o,
Walkthrough is a Revie
‘he review Ge nerally Y it itis
i starteg
b iffere +
In walkthrough, doc or feodg A “me Inspection tne not a formal process,
4S itis
of product suggestions about it,

vhile the

n becaug,
ary, © Preparation befy . .
It is the informa] ee Te meeting and creation of a list
Te
1 challenging task in walkthros” S80 it does Not fi
iced. In ghs, °cus on documentation. Defect tracking is
— The followin
i g are the objectiv
es of W: alkthrou
o gh :
Understand and
learn the q evelopme
nt of software pro
o DetectingBe defect duct till date
s in the develo
ped software Produc
o t. ~
To explain information Present
in the document.
o To verify and discus
s about the validity of
the proposed system.
o Reporting the suggestions given by the
others (other employees).

> and | 517 Comparison between FTR and Walkthrough . :

- May 16)
=> (MU
| :
@.5.17.1
3 :
Compare FTR and Walkthrough. (Ref..sec.5:17)
: :
om |
Walkthrough S|
Parameter ting but it
— ie meeting
—Walkthrough is: a Review
7 So eas nota
. as itis
Concept A formal techni cal review isve aofprocess
$0 is different from Inspection
perfo rmed to give assuran formal process .
en i quality - ally it is started by the author of
j Generally it is
s done by software
the code
;
i
Performer This . testing activityr i rsons -
i engineers and other pe i | tna Walkthrough, the producer
|| sibes the product and asks for
rk produc r is inspecte desc’ -
i| | Process indivi a comments from the participa: nts

Scanned by CamScanner
 i ee

ie Software Enginoerin MU - Som. 6 - Com 5-46 __ Software Risk, Configuration Mgmt & Quali Assurares

Parameter FIR Walkthrough Loo

ea
Work Product A Work Product is any significant Walkthroughs generally help ™ examine
deliverable developed through the source code as opposed to design and
requirements, design, coding, or testing requirements documents. A step-by-step,
Phase of software development line-by-line simulation of the code is
done by the participants.
Way to perform It is usually performed as a peer review | A walkthrough is particularly helpful for
without management involvement. higher-level documents such as
requirement specifications and
architectural documents.

Chapter Ends...
Qa0

Scanned by CamScanner
 Software Testing and
Maintenance

girategic Approach to Software Testing,

Unit testing, integration testing, Verification, Validation Testing,
system Testing, Software Testing Fund
amentals, Whi ite-Box Testing, Basis Path Testing, Control Structure Testing
i ’ 0} i
ie

Black Box Testing, Software maintena

nce and its type
S, Software Re-engineering, Reverse Engineering.

6 Software Testing

Software testing is a procedure to verify whether the actual results are

same as of expected
results.

Software testing is performed to provide assurance that the software system does not contain any
defects. ,
Defects means errors which are detected by tester when actual result of our software module is
not identical as expected result.

Software testing helps us to find out whether all user requirements are fulfille
d by our software
or not.

Software quality depends on; at what extend software fulfills user requirements
and number of
defects occurred in software.

Software testing is used to give assurance that we deliver quality product to customer
.
To perform software testing we create test cases and test data. Test Case is a collection of
actions
which applied on our software product to check specific feature or functionality of it.
Collection of test cases is called as test suit.
Test data is the input provided to modules which are present in our software product.
Test data
tepresents the data which effects execution of the particular module. Sometime test data
is used
for positive testing. That means it is used to check that a provided set of input for given function
generate expected result or not. Sometime test data is used for negative testing. That
means test
data is used to test the capability of our software modules to handle unexpected input.

Scanned by CamScanner .
 software Testing and Maintenancg
ae,
6-2
[EP sottware Engineering (MU - Sem. 6 - Comp)
SS
6.1.1 Advantages of Software Testing |
:
g ? (Rot, sec. 6.1.1)14
lo. 6.1.1__ What ara the advantages of Software Testin
g
There are several advantages of software testin leads to softwary
re |
fai lur e by removing errors which
of sof twa
s the possibility
1. Testing reduce
arene

ve
failure. ps to deliver qualitati
m software and hel
i 2. Testing process removes maximum possible errors =
;
; . software to customer.
: long with quality.
ennrawill vat
‘4 _ 8. Testing ensures correctness and completeness of software a
i satisfy all of
: Testing allows us to verify and validate the software and ensures that software

the user’s requirements. .

outcome by removing errors which prevent
| 5. Testing enables the software to produce expected
}; ected outcome.
system from producing exp
iy
1¢ 6.1.2 Types of Software Testing
SRE) inate antares ee eae ee sels he
__Write note on Manual and Automation Testin
j : a
{ la. 6.1.2
=
a Software Testing is divided in to two categories
/
Types of
software testing

1. Manual Testing

2. Automation Testing

Fig. 6.1.1 : Types of software testing

i > 1. Manual Testing

Manual Testing is one of the type of Software Testing in which Tester treat himself as end user
and use every module of application from login module to log out module to check application
behavior according to requirement provided by user.
In manual testing, tester manually runs all the test cases without help of any automation testing
tools.
' - ° Manual Testing is the very basic type of all testing types and supports to search the bug (error) in
| the software system. -
- First we do manual testing for any new application before going’ for automation testing. We
perform feasibility study of automation testing in manual testing i.e. do'the analysis of benefits of
performing automation testing for our project to take the decision that whether to do automation
testing or not.

For performing manual testing, we do not need knowledge of any testing tool
Manual Testing requires more effort, but is necessary to check automation feasibility.

Scanned by CamScanner
 g &
Software Testin
ja not
that “100% Automatio?
ftw .
ossible” so we ne tos t; are Te st in g is
P ed to perform manual
mt
goals of Manual Testing
. t
uc
that our software prod
:
f performing m anual testing } .
_ The main purp.ose of e to giv e as su ra nc e
fect and it fulfills all a
does not contain any de un ct io na l requirements of end
ser-
they4 must
it es (i. e. co ll ec ti on of test ¢. ; gn ed in the te sting phase and
_ Test Su wa ourA50 shen are
8 de si
: ies present in
test all functionalit oftware product ‘ s
. loppeer and tester per form
‘

in g gi ve s as su r ect s are fix ed by d

Manualing teonst sahennsl ‘an i
ce that report ed def y dev elo
=
vetest ng the defects
:
pl oy s pu g- fr ee 8° —
: uct and de
- Mainly manual testin
g verifi ies th
© qua lity of the software prod
fo the customer.

_ Listof manual testing is as follow :

(j) _ Unit testing
g
(ji) Integration testin
(iii) System testing

(iv) Acceptance testing

a 2 Automation Testing find out

to ma ti on too ls to run our test cases to
we use au
is a process in which
_ Automation Testing
bugs from our softwa
re product.
which we
perform testing
te r tes t da ta int o the software on
en
software is able to
The automation ults to create test reports.
ected and actual res ployees,
and it also matches'the exp ne y an d resources such a5 em
am ou nt of mo
ires considerable
Automation testing requ
we
testing tools etc. ne ed to ma ke ch anges in code and
of error, we
ch an ge in re qu ir ement or occurrence
After n and again.
me test suite agai
require executing sa too ls and re-play it when
needed.
au to ma ti on
suite by using test testing.
We can record test to pe rf or m te st ing like manual
interaction
te st in g do es not require human ecuted manually
but not
Automati on ca se s to be ex
er of test
ma ti on te st in g is to decrease numb
Aim of Auto ly.
Testing complete test data and test
script.
replace Manual of te st ca se s,
e generation
m au to ma ti on testing we requir are stable at so
me extent
To perfor nt s of pr oj ec ts
ect if require me
te st in g is pe rformed for proj
Automation changing.
re qu ir em en ts are not frequently
ie .
tomation tools (ii) Mentis
List of some au

(i) Selenium (iv) Buxila

TP)
Qu al it y Te st Professional (Q
(ii) anagement)
(A pp li ca ti on Lifecycle M
(v) HP ALM

Scanned by CamScanner
 e
r icide F
ps pest
[EP sonware Engineering (MU - Som. 6 -Comp) ua : w
in
r oe
6.1.3 Difference between Manual and Automation Testing
ant

- 7
tion Testing, human interactj
Parame ™
pe
To perform manual testing human Tois not ary automation testing we use ma, ‘ 4
Human for test required gett
interaction interaction is required to run the test cases. rv
ti
execution. i i ; T
ere '
a ae
Requirements {To perform manual testing, We need | To perform “oe “s time, -
skilled
K loyees, more time and| automation
employees, cost and power.Automation
tools. Once test suite is recorded in
¥
easily run test suit.
automation tool then it can
otal _
«ig eean applicati
used to test = ome
can
~
be first tested Automated tenting is use
Application to | Any application ae and
ad-| whose requirements are :
Test manually. Informal testing like used perform
hoc and monkey testing are automation testing mainly
Regression Testing. :
performed manually.
is of ae ow test
while |The most boring part which
Execution of We cannot use manual testing
repetitively can be performed wi e help of
Same test cases. |executing same test suit. Repetitive | cases . a ,
automation. testing.
execution of test cases become a (e)
boring and error prone.

6.1.4 Principles of Software Testing

1)
la.e.1.4° Explain the principles of software testing. (Ref. sec. 6.1.4) “
as follows :
There are 7 Testing principles which are

(a) Complete testing of software is not possible

, we require performing the best possible
- Complete testing of software is not possible. Rather
application.
amount of testing with the help of risk assessment of the
defects may occur and test that module
— Risk assessment is the process of guessing module where
amount of time to test each and every
to find out those defects. Because we have not that much
possible.
module from our software, exhaustive or complete testing of software is not

(b) Defect clustering

y percent of modules.
- This principle states that about eighty percent of defects are found in twent
— Using experience, we can find out such risky modules.
repetitively, such test
- ‘But this approach has its own demerits such as if we run similar test cases
,
* cases does not find any new defect.

Scanned by CamScanner
 ide Paradox
yo 19 use same test
q and Mainten

e fy b. To solve thi “ases Tepetitively 9, the toat : r sting thon ator

defer : fF 18 Problem,
particular point we cannot find new
and include new test cases to help in fi NSe8 required
‘i ' wed and revised on regular basis‘
tot © revie
. Inding
qesters cannot use only exist: OW defects,
; ing testin
methods to find out more defec 8 Mechanism, I zs
ts. But after rform; ns should try to improve the existing
ig bug free. ing testing, you can never claitn your product
esti shows presence of defects
Testing process
can show that
tho dof ects '
that there are no defects, "Te present in the system under test but it cannot prove
Be en after testing . we cannot guarantee that system is
100 % error fi free.
Objectives of testing process are ag follows
°}) Finding
— defects whi ch are created by developer while developing software.

(i) Providing information about quality of software under test

(iii) To ensure that system meets the business and the user Tequirements.

(iv) To gain customer’s confidence by Providing them a qualitative product.

¢d Absence of error ,

if it is tested for wrong requirements i.e.

- The software which is 99% bug free can be still unusable
absence of error does not help if system does not satisfy user’s need and requirement.

() Early Testing

_ ‘Testing must be started as early as possible in the Software Development Life Cycle (SDLC).
out in early phases of software
_ ‘Therefore any bug in the requirements or design phase are find
testing.
- Ibis less costly to correct that bug in early stages of testing.
at time when requirements are gathered.
- Itis suggested that we can start detecting the bug

(g) Testing Is context dependent

site will be
is cont ext depe nden t’ speci fies that the way tester test an online shopping
Testing
d alone application.
different from the way he/she test stan

6.1.5 Objectives of Software Testing

=> (MU - Dec. 16)

Q.6.1.5 What are the objective of testing ? | Eee

(Ref. sec. 6.1.5)
software.
by the programmer while doing coding of
- Finding defects which can be generated

Scanned by CamScanner
 n,
Software Testi Ing and Mai
6-6 . nority o
ing (MU - Sem.
6- Comp)
ie retest the ofa rr aor
tware Enginee correction and defect.
ects to developerdoefor
ee Sof
the det ect ed def contain any uy;
_ Report s not requi ‘
assurance that software duct fulfills all sett pisnnin
product to give
ass ura nce tha t our software pro en ot
is done to give ie el
_ Software testing oo
user. finds ¢
end user. tware to our end
tha t we del iver quality sof (Business Regqui
ry ms
_ Togive assurance en ts pre sen t in the BRS Men,
requirem
that it satisfies . -
— To make sure quirement Spe cif ica tio ns)
which aes
SRS (System Re software product wore ot case
Specification) and by giv ing them a quality be
tomers
ence of the cus ectations of cus
tomer.
_ To get the confid quiremen ts and exp Int
fulfills al] the re
user friendly and
Tei
-
g Process
6.1.6 Software Testin
: in detail. (10 = 7
re testing-process 3
Q. 6.1.6 Explain the softwa ae . 9) gest &
re wiikag
. (Ref. sec. 6.1.6) var
P s activi
iou
s s whic: h helps to certify softwa
segtie _ of
ence of Test cae
process js a sequ Test planning,
— Software testing Re qu ir em ent analysis, _
ivities are -
g process act es.
— Software testin Test cycle closur : Fost!
t set up, Test execution, ia. :
ry and exit criter
vironm en w
development, en s has defined ent
proces
of software testing .
_- Each of the activity _

’ : -
Requirement ;
_
analysis
Test .
planning
Test case :
% development _
- Environment
setup
wid’

Fig, 6.1.2
t must be satislied
of test ing are pr' ere quisite conditions tha
erions
- Entry criteria 3 Entry crit
efore testing begins. d before
n of fes tin g des cri bes the conditions that must be satisfie
_ Exit criteria : An Exit criterio -
testing is concluded.
s
@ Phases of Testing proces

(j) Requirement Analysis as non-functional)

her ed req uir eme nts of sys tem (i.e. functional as well
_ In this phase all gat ements are testable or not.
ermine whether these requir
studies to det

Scanned by CamScanner
 pepending on requ
priority oftesting, its 6.7
1 is des
®Cideg
At the end of this ph
i . asg Re

gest planning Witement

ie ) j
a8 test Stratogy
a an out known
finds ont require, a eff
rts an, estim, S8e. Tt is ros
At the end test plan is
Prepa, Te
Med cont for ge a Sylity
st
of toat St ma “er. In this phase manager
em8 ; Inde
j ase Dev Suteom, © Of
r dew elop
rn enon t,
; rest . elopment test, Planning
: él ‘
"| In this phase all test data is q
eterm) ined revi
_ It includes generation 5 Verific . 'y Viewed and
nNetworked if necessary
Tework (
88 per requ;
u

pest environment setup

(io Marks) “ditirement) of test cases and test seripta

re SYstem
pletion of set
After comple
Test case ti UP, smoke te,
| St is perfo Tmed on it,

_ During this phase testing of

i plan and test cases, Software is carried out by test te am using previously prepared test
/
| — Intension of test executi
cution is to find bugs in software
| _ These bugs
gs are reported to development team for corre c! ting
the: m.
After correction re’ test isi performed in order to assure that reported bugs are removed.

| (vi) Test cycle closure

i :
This is end of software testing process.
ity of
se cyc le com ple tio n crit eria is det erm ined depending on time, test coverage, qual
i In this pha
, business objectives etc.
" system, cost of software
pared.
us in g all the se att ributes test metric is pre ng of analyzing
By
and def ect log s are available. Usi
n co completed
isfied testing has been
Before this phase
i rt is pr epared.
osure repo
defect logs, test cl are Testing
c Approach to Softw
ofore :Strategi
Syllabus Topic

Testing
oach
6.2 Strategic Appr
jn advance
be planned
s which can
get of activitie

Scanned by CamScanner
 nane,
ting an| d Mainto
software Tes
6-8 of steps
=Comp) be a serics
g (MU - Som. 6 ch wi ll
re Engineerin sting whi placed.
— ftware te s cam be
to dofine t late for so ng me th m
od
Hence a thero is need
a es as well
- de sign tech atniqu
tes t cas o
which specific ailable fr
om W'
tegies av
sting stra
to eliminate
of soft w aro te
= There are number is helps
reviews. Th
expected:
effecti ve technical
there is need of
o For effective testing, oration of t},
incorp
errors before tes
ting commences,
’ de “o utward” toward the
o! nent level
and procee
co Testing begins with comp eriy,
system . software engine
whole computer-based sui ta bl e for different 4
techniques 4
re considered a8
Different testing
points in time. for large projects,
approaches and at different conducts the testing but
dev e loper
jects software
Incase of small pro
it is necessary 4,
o up.
distinct activities, but
pendent test gro
is need of an inde
ered as two
gging are consid
Testing and debu g strategy-
gging in any testin ts which arp
accommodate debu
ant to accommoda
te low-level tes
software tes tin g it is im po rt as hi gh-level test,
For a strategy of rce co! de se gm ent as well
t implemen tation
of a small sou mer requirements js
required to verify tha
ant sys te m fun cti ons against cu’ sto
validate most import
which are used to
correct. the wel]
(newcomer) arid a set of milestones for
dance fo: r the practitioner
Astrategy must offer gui
experienced manager. en there is increase in
ps reg ard ing the tes t str ategy is done ata time wh
Since the execution of ste problems should be identi
fied as early as
t be measurable and
deadline pressure, progress mus
possible.

Validation
Syllabus Topic : Verification and —————= EE

6.2.1. Verification and Validation

[o.622 onat
Explain vertcaandtivalid
= Verification
. Lo
of a
- Verificati
neni itt be ori a a process of estimating the intermediary work products
: . user
ment lifecycle to verirify that we are in the correct track of creating the end
product:

. ~ ‘
-— Now the question is : The answers is the
duets oon by the intermediary products? .
is meanlocum "
intermediary
are generated during the development
consi:
. ents which
documents, database table design, ER
. °f q
phases such as recpiremente, design
specification,
matrix ete.
‘
‘9

diagrams, test cases, traceability

Sometimes we can avoid focusin s
thete documents but reviewing these document
-
can help us to find out most of the Tevie winig
e glitches. If these glitche s are found at later phases of the
development lif cycle then it_ will be very costly

Scanned by CamScanner
 ingineering (MU - Se
Mm. Be Cc
OF
Testing and uy, verification helps to §
inten, aNCg nd
Tn soreg eeeten. that the system is uses, *
laced. ‘ul,
PS in qhe main focus of the ‘teri
8 characterjq) -
T1Sticg are = “ification i
‘ll gation
:
vy
helps to ej, f Validation can be defing d
Nate | ° software meets all tho ; 7 egit is
SPecifi ' Totess 4 °
Corporation o¢ th, | Tecan also be defined a8 a pr Witement, — ““*lUating the final pred
i deployed d on suitab
. le environment.
‘OCe, Which shows that . Toduct to ensnsure that the
3
are e i sages .
"8 Neering tl
ij - Validation is performed in the softy * Product fulfils i intended use when
i are deve}
. i .
2 Projects, ther, |,
yg P pifference between Vey ifleation ang Vatican on
©pme:
nt life
i eter eto pe
3 necessary to

> (wu - May 15, Dec. 17)

ts which fe LORE mer
gh-leve] te sa
uireme Sts .
Concentrates on right way to bui
Nts is te uild a Cc
sys my : Oncentrates on output of build system.

for the well Verification Can bed efined :

eee . - .

of estimating the interm ‘in "tis. process | Validation can be defined as it is the
Oay work
of aa 50 softw ~ = development Process of evaluating the final product to
incre,
. ase in Pp roducts
; lifecycle | ensure that the software meets all the
early as to verify that we are in the correct track of | specified requirements.
; creating the end user product.
==—_—— —.

a The aim of Verification is to ensure that the | The aim of Validation is to ensure that the
product being develop is as per the product really meets up the user's

requirements and design specifications. requirements, and verify whether me

ae be correct in the first:
spec fications
c place.
Marks)
° , 31% ae . testing
- such as black
“on i i i
jMeetings Validation contains
" ;
i ification contains Reviews,
ne ti : box testing, white box testing, stay box
—_—
ections.
3 of a and Insp testing etc.
| user a Validation is conducted by testing team.
. : i
| Performer | Verification 1s conducted by quality
the assurance te Execution of code is @ part of Validation.
21ent . : a part of

ER [Execution | Execution of code 1s not @ P : ion about

explanation
of code +o ati
Verification. aout | V alidation process gives
ion process gives explanation ® ts _ | acceptance of software by the user oF not.
ification satputs are 28 per the jnpu'
: | Verifi
Explanation InP
its
ne whether the
or not.

Scanned by CamScanner
 >
[GFP sonware Enginsering (MU
. 2 = *
Sem. 6 - Comp)
my 6-10
Validation

Parameter | Verification ~an

1 software is done in
sting 0
ean
Processes Plans, Requirement Specifications, Design
otc.
Specifications, Code, and Test Cases
[_ are evaluated in verification.

coer]
6.2.3 Software Testing Strategy

a trategy” with suita

Strategy” Sft
9 m. (Ref. sec. 6.2.3) _-
l blo diagra
[2.6 244
Q. 6.2. _ Explain *Softwai re Testin testing process. Now we will see software process wits
We have already seen phases of so ware
; an
different aspect.
the spiral as shown 1n g. 6.2.1.
The software process can be considered as
* eering and Proceed ts
system engin
In the beginning, , the role of software isis defined by the lishment of the inform
ation domain,
software requirements analysis, in which there is estab cia decent
function, behavior, performance, constraints, and validation criteria for 8! .

Moving towards inward in the spiral, we come to design and at the end to —
System testing

System engineering

Fig. 6.2.1 : Software Process

It is possible to view a strategy for software testi

ng in the context of the spiral.
Unit testing gets started at the vortex of
the spiral and focus on all of the software
units such as
component, class, or WebApp content
object which are implemented in
source code. : .
Testing continues by traversing
outward direction along the
spiral to integration te sting. Here
the main concen tration is on designing and buildi
ng the software architecture.

which has been developed. -

At last we reach at system testi
ng, where testing of the softw
are as well as other system
is done as a whole, elements

Scanned by CamScanner
 P testing any con
™MPutey
streamlines which enhan,
w.
Neg ¢]

peas tm account the in of te,: 7

engineering, pra, Sef,
1
> Ctically t,, To ah
a oa ery turn direction along
The steps are g hown ; in Fig. an j lem, Cedural .
MEN : on Hint ¥ view, in the
6.2.9, Nati OF fon
In the beginning,
anf
testy ir ; tomntert of
iftwrare
co Neentra 18 a
properly as a unit, every

Therefore, the name; 1s unitIt test;

Ponent
indivi idually, Taking sure they funet
particular. paths ; . unetion

contro Stir DE use“© t Ystin

possible erro tech;
r detection cur of Ponent to confi &chnicni
es teativety which
. exerciag
ITm ent}
ire Grage as well maxime

Requirements

Design

_ Integration test

Code

Testing .
direction

_ Fig. 6.2.2 : Four Steps of Testing

1
Further there is
i need to assemble or
or integrate components to form the whole
wh software package:

Integration testing hig! ‘hl ig zh ts the

h
concerns
hich:
which. are re
lated to the dual problems of verification
.
and program construction.
on inputs and outputs are more
Test case design techniques which in general used to concentrate
common in the process of integration.
a series of high-order tests is conducted
After integration of software,
requirements analysis.
vali dati on crite ria which has been set during
There is need to evaluate functional,behavioral,
and
e that all infor matio nal,
esents absolute assuranc
Validation testing pr tware.
ir em e nts are fulfilled by the sof and in the
performance re qu th lim it of sof tware engineering
outsid e e
er te st in g step is considered
rd
The final high-o system engineer
ing.
elements such as
t of co mp ut er % ith other system
wi
wider co nt ex va li da te d
Ww hich issoftware
ine the
is ne ce ss ary to comb system
It and the overall
se, et correctly
hardware, people , databa the element r me
sh

System testing °°
function/perfor

Scanned by CamScanner
 Software Testing and Maintenane
6-12 al
(MU - Sem. 6 - Comp)
LEP sonwara Engineoring : Unit Testing
Syllabus Topic

6.3 Unit Testing > (MU - Dec. 15)

Rich St SS a
n . 9 (Ref. sec. 6.3)
unit testing __
la.Q.6.3.1 Explai nt stages of the software development lifecycle where
Software testing levels are the differe
testing is conducted.

There are four levels of software testing :

Unit >> Integration >> System >> Acceptance.
in detail.
We are going to see the Unit testing
= Unit Testing

Unit Testing is a level of software testing where indi

vidual units/ components of a software are
tested.
as designed.
The purpose is to validate that each unit of the software performs
A unit is the smallest testable part of any software. It usually has one or a few inputs and usually
a single output.
In procedural programming, a unit may be an individual program, function, procedure, etc.
In object-oriented programming, the smallest unit is a method, which may belong to a base /
super class, abstract class or derived/ child class. (Some treat a module of an application as a unit.

Unit Testing Method

It is performed by using the White Box Testing method.

When is it performed? :

* Unit Testing is the first level of software testing and is performed prior to Integration
Testing.
v
Who performs it?

It is normally performed by software developers themselves

or their peers. In rare cases, it may
| also be performed by independent software tester
s.
7 Unit Testing Tasks / Aspects of the software tested In unit
testing
- Unit Test Plan

‘- Prepare
- Review :
- Rework
- Baseline
- Unit Test Cases/Scripts
- Prepare

Scanned by CamScanner
 Unit Test
oo eS Perform

mu “Dee. 15) j yalt gesting Benefits i

if : a
anert theyey are
are et®®
run nfiden
7 Ce in
ji in'introduced due to the“very time any
change > is. changes
code / mainta:.:
taining code If grea
: . . unit tests “
j Also, if codes are already made lec : toSmmpdy abavan ian
impact of changes to ANY code j us ini 7
5 le; Pendent to ,
Codes are more reusable, In orden * ® unit testing possible, the unintended
/
means that codes are easier to rey to make unit testing pose
ware are i Development is faster, tf there j “e Possible, codes need to be modular. This
that fuzzy “d
eveloper tesp
‘ Weveloper set
that hopefully hit the code
2

and hope ome breakpoints, fire up the GU

8

I, provides a few i
i

But, if there is unit testing ;

wsually 3 sa: € 10 place, 5 qleveloper/te .
test. Writing tests takes time
ti, but the time . ster writes
is compe ted by thethetest, wri the code and ron me
he wits

ase / _
Development is faster in the long run too. The effort required to find and fix defects found during
unit, unit testing is very less in comparison to the effort required to fix defects found during system
-testing or acceptance testing. :
- The cost of fixing a defect detected during unit testing is lesser in comparison to that of defects
detected at higher levels. :

- Debugging is easy. Whena test fails, only the latest changes need to be debugged. With testing at
need to be scanned.
higher levels, chariges made over the span of several days/weeks/months
g
63.1 Stubs and Drivers in Unit Testin

Scanned by CamScanner
 Software Testing and Maintonanca
—
EP somware Engineering (MU - Sem. 6 - Comp) s5

(1) STUBS Module C. Module A is ready and we need

Assume we have 3 modules, Module A, ModuleModule
B and B and
:
C whi ch are not ready, so developer
to test it, but module A calls functions from alues to module A. Thi,
B and C and returns v
will write a dummy module which simulates
dummy module code is known as stub.
. ;
ORIVERS
from Module B
Module A which calls functions
* Now suppose we have Modules B and C — piece of code for Module A which will returp
and C is not ready so developer will write a d is known as driver.
values to Module B and C. This dummy piece of code is kno
Nowir
6.3.2 List of Errors Detected by Unit Testing - . Mod
[a.6.3:3 Enlist various me of errors detected by unit testing. (Ret. sec. 6.3.2) _ tdMari) | logic m
Following is the list of errors which are usually Unit Testing can detect : _ So, wh
- Local data structure efficie
- Boundary conditions — While
- Independent path — Wer
- Error handling path of sc

- Local and global variable — The

~ Incorrect initialization bet

- Incorrect symbolic representation of an expression _ oth

| - Incorrect arithmetic precedence oo.

- Global variable naming convention _ #¥
— Mapping error
é
— Log and exception handling a «6.44 Ty;
7a Referred different data type in the code and database
L
- Necessary input parameter not trim during the saving in the database.
2
—=—_ ——————[—_—_£_E___—ESE
EE ===
Syllabus Topic : Integration Testing

6.4 _ Integration Testing

=> (MU
- Dec. 15, Dec. 16)
[0.6.41 Explain integration testing. (Ret. sec, 6.4 oe Dec. 15,-Dec..16,.5 Marks
- Integration testing is a method of software testing in which all units
of software under test are
integrated and tested as a single group.
- Itis always done after unit testing is applied.
~ It mainly focuses on testing data communication among
all units of system.

Scanned by CamScanner
 ¢ an,
gpcromental approach
: : can be either to . “PProach an

menatenance e main units.

objective of integration test; WN, botte “Up “Femental Ppr
y
intestate d ing j “*PPoach,
. ;
c “tod Tming of beth
and we need
$0 develope; MMtonration ‘.
® fants in 6 .
™Munication betwee
Sting ren,
ule A, This

Module B
rill return
Fig. 6.4.1
Following are reasons
for Performing Integrati
. .
A Module is developed by 5 oftware 4
ati :
;
On testing
. eve Oper wh
orks) Jogic may not be same as ofother Software devel, ose level of understanding and pro P
go, while performing Integration Testin Pers from project em, Programming
: oy . 8, We requ}
efficiently with cther modules or not. “quired to check whether software madule works
ile developing single mod
ule, there is risk of cha
nges in Tequit ts by
rement the clients.
We may not perform unit testing for this new requirements
of software is needed. and so performing integration testing
There isis po possibilityty that inte
interfac
rfaceses (through which operations on data
base are done) present
between software modules and database
may contain error. ,
There is possibility of error occurrence due to exte
rnal hardware interfaces.
There is possibility of raising issues if exceptions are not handled prope
rly.
For all these reasons we need to perform integration testing.

| 441 Types of Integration Testing

1, Big Bang Approach ;

categorized into given types :
2, Incremental Approach: which is
o Top Down Approach
o Bottom Up Approach Pp
0 ° wn an
-

- (!) Big bang approach . product are created first and then they are combine
ined

P
s0 fiware nee
In this strategy, all modules of so Module 7
-
are istested ato from ‘Module Y to
the os "
ch As per the Fig. 6.4.2 all . is
tagterantn
*
ns _ a . . pe! .

integrahon beotin€
i

aaa neebt one ae by ©ne aad then the

; are combined
f

Scanned by CamScanner
 ee
Soft ware Engineoring (MU - Sem. 6 - Comp) Software Testing
6-16 mend Mal a,
and Mainten
ince

QLD
ELD-E- DED
Gemeente)
Fig. 6.4.2 : Big bang approach
al Advantage of big bang
approach
~ . Suitable for smal] sof
tware projects.
- Disadvantages of blg
bang approach
Finding defect is difficult task
because we-test whole software
at. once.
There are lots of interfaces
which needed to be test,
— Inbig bang approach, ther
e igs Possibility that so

High risk present

in this approach is
Priority basis becaus tha t critical modules
are not se parated
e all modules are
tested at the same ti and testeq on
— Peripheral modules me .
that are related wit
h user interfaces ar
basis. e not separated an
d tested on Priori
ty
(2) Incremental Approach

A Stub is dumm
y Program whi
replace called module
by stub.
Driver is dummy
Program which cal
ls an other module
ie. Calling module is replaced , We replace
by driv er, Place Module to be tested by driv. er
u

Scanned by CamScanner
 dow? Integration
y” jn Top to down theappro ach
botte, ‘m test:
are present at
;
;

In top down approach,

Fig. 6.43 :7 Top down approach

rs A gvantages of Top down approa

ch
Identification of bug is easy.
oproach
Critical Modules are
;
te sted ‘ori
on priority basis so critical designing defects could be found and fixed
early.
ted on
n approach
r Disadvantages of Top dow
there is need of
replacing lower level modules
Top down testing requires many stubs because for
riority

stubs.
time.
iciently because of lack of
Modules present at lower level are tested insuff

1 are tegration
b) Bottom up In is tested with modules present at
nt at lower level
up approach, every module P rese
In the bottom tested.
- for
le ve ls un ti l all mo dules are
higher tom up incremental
testing.
while perfor ming bot
Drivers are used

nd

oy

Scanned by CamScanner
 & _ Engineeri
& i
Software Testing and Maintenancs
6-18 | ; 4 comps
EP sottware Engineering (MU - Sem. 6 - Comp)
@ Advantages Bottom up approach After com
—
a .
Finding defect is easy task.
; . ‘ ‘ 1.
Ther
spec
- After developing one module, testing is started. It does not waste time in waiting for all modules
to be developed unlike Big-bang approach. 2. Ave
@ Disadvantage Bottom up approach : / Before |
that control the flow ae pro
Critical modules which are present at the top level of software architecture
: itical modules. ue
of software are tested last and may be defects occurs 1n critical
|
: ting
Syllabus Toplc : Validation Tes
x . 2 configu
6- ,
6.5 Validation Testing Confi
Da pe eT ea the
deve T
1.6.5.1 Explain Validation Testing in detall. (Ref. sec. 6.5) : a O Marks) |
— When integration testing ends, Validation testing begins. After completion of independent
components, the software is completely integrated as a package, and interfacing errors have been
found out and corrected.
- At the validation or system level, no difference remains in conventional software, object-oriented
software, and WebApps.
- Testing is concentrated on the actions which are directly visible by user and output which is user.
eseomaiebla from the system.
- There are number of ways to define validation, but a general definition is that validation will be
successful when the functionality of software is as per expectations of the customer.

- Here the main concern is user requirements. :

- A Software Requirements Specification explains all of the user-visible attributes regarding the
software and includes a Validation Criteria section which sets the basis for the approach
regarding validation-testing.

6.5.1 Validation-Test Criteria

- To achieve software validation a series of tests is carried out which demonstrates conformity with
user requirements. ‘
= Atest plan describes the classes regarding tests to be conducted. | ‘
- A test procedure defines particular test cases which are designed to ensure following:
o All of the expected functional requirements are fulfilled,
o Allofthe respective behavioral characteristics are achieved.
o There is accuracy in all the content and are properly presented.
o There is consideration of all performance requirements.

o Documentation is accurate.

Scanned by CamScanner
 Usability as wel) i it
er
Testing and Maintenance
compatibility, erro, mates
: after sau eons
maine req
of each Validation tert. remeonty are
re 1. Sime 18
of tho function ne er in

g, Avariation from *Pecification ignot ne character since it conforma to

gefore . scheduled delivery, *red and a ligt
|
it is
at control the , ne aMeutt to retarding deficiency is created.
figy, * ine projecv e
t. t
‘ations or
re is need to ne with the
gotiate client (c“
= configura
—mer)
usto
to ~
set a :
———y ew |
a
i 0 method for resow
lvine
g deficiencies.
nfiguration |
review 18j Conside;
.
i
the review 1s ma
king sure Gohu
0 Mares) | cs -s : its h
developed are prop ee accura'
of independent erly cataloged
°
Sociated elements oforetheam en
softwarecate
ane
he configuration review is a
Tors have been also known as 8 audit.
audi
Alpha and Beta Testing
bject-oriented [52 Write note on Alpha and Beta
Toss
(10 Marks) |
hich
vhich is user- j | testing
‘ mene
Alpha Testing is software testing which
is done to find out bu before deploying
i the software
ation will be application to end user.
—
Alpha testing is a type of acceptance testing.

: -
This testing is called as an alpha testing since it is performed when development phase of
arding the

. software application is near to Beta Testing. F

| approach
The objective of alpha testing is to refine the software product by finding (and fixing) the bugs
that were not discovered through previous tests.
in-house software engineers or QA staff.
Alpha testing is typically performed by
, stage before the soft
wate is released into the re al world.
uy ” “ Itis the final testing
in two phases :
- Alpha testing is performed y perform deb ugging of
test ed by de ve lo pm ent team members. The
re is
(i) In first phase softwa
quickly.
software to catch bugs qu al it y an al ys t team for additional
testing in
wa re
. ted b y 80! ft
software is tes
(ii) In second phase P
vironment se
actual user’s en
g
? Advantages of alpha testin y
Ss.

about the softw

- Free up team for other

Scanned by CamScanner
 EE sommare Engineering (MU - Som. 6 - Comp)
Reduce delivery time to market.
Early feedback helps ta improve software quality.
(2) Beta testing

a t the location of customer. . In this testing actual

testir ng is testin, ew hich is performed
whether the software issatisfying the;
las intended
i users wil 1 test the so ftrw: are to determine
needs and expectations.
Beta testing allows users to test software before it is released to public.

ve product through
- Beta testing minimizes the product failure risks and delivers qualitati
customer validation. It gives direct feedback from the user.
It ensures reliability, security, robustness etc. from user’s perspective.

— Types of Beta testing are : Traditional, public, technical, focused and past release.
Beta testing is also called as User Acceptance Testing, Customer acceptance Testing, Customer
Validation testing and Pre-Release testing.

Beta testing gives assurance that we deliver quality software to our customers by testing the
product under various situations in real world environment that can't be created in a lab setting.
* Advantages Beta Testing

Beta testing decreases product failure risk by performing customer validations.

Beta Testing permits tester to test the software application in post-lau
nch infrastructure.
Beta testingimproves the quality of software product by using
feedback of customer.
Beta testing is cost effective as compared to other data collect
ion techniques.
Beta testing helps to increases customer satisf
action.
© Types of beta testing

There are various types of Beta testi

ng :
1. Traditional Beta testing : Soft
ware Product is provided to targeted
end user and associated
data is collected in all aspects. This
data is useful for the improvement
of Product.
2. Public Beta Testing : In
this type of beta testing, product
is released publicly in real world
using online channels and data
can be collected from anyone. Usi
ng feedback from end users,
improvements in product are done
. “a

3. Technical Beta Testing : In this

type of beta testing, software Prod
group of an organization and coll uct is released in internal
ect data from the employees of
the organization. .
4. Focused Beta : In this type
of beta testing, software Pro
duct is released in the mar
collecting feedback about spec ket for
ific features of the program.
5. Post release Beta:
data is collected to improve the software produ
ct for the n ext release,

Scanned by CamScanner
are Testing and Mainter,

this testing actual ag

re is satisfying the:

@ product through

sting, Customer

by testing the
a Jab setting.
Few Weeks of time is . os
Perform the beta testing.

-.
Important issues can be corrected
by developers without delay in
Alpha testing.
Alpha testing focuses on giving
assurance about quality
2 of the Product, but it collects
software product before going feedback from|
tolend users about software produc
Beta testing. t and
gives assurance that the software
i
ciated product.is ready for. use in real world
" environment.

world Syllabus Topic : System Testing

users,
{6 System Testing
rnal
. = _— a
> (MU-May 17)
= aaa SGN EEE RUE
-
Set se SISTERS
: aes
loses _ Write short note on System T Testing: (Ref.
Sea 7sec. 6.6)

for .+ of entire and completely inteagr ated -_t software product.

gra based
- System Testing is testing 0° sts whose work is to test the complete computer baie
;
id ious s te!
.
=~
.
‘System Testisisenqugen
ce of variou

system. .

Scanned by CamScanner
 EP coma eninning tyson. 0-conp) 6.22
Software Testing and Maintenanea

le to log out module,

— System testing is end-to-end tosting. i.e. wo test system from log in modu
le
— Fore.g. In college admission project, system testing carried
out as
[begin moduia Lf Enquiry module |-of Admission ne
+f ton
aot}moat |
- System testing contains both functi onal (check
as well as Non-Functional testing (check whetherwheth er requirements of user ted eee
expectatio ns of user are fulfilled or not). mu
— There are Two basic categories of Software Testing stich as

Software testing
methods

1. Black Box Testing |!

2. White Box Testing |

Fig. 6.6.1 : Software testing methods

> 1. Black Box Testing

In this type of testing, we check working of our software project by running

it. We do not need to
check code of our software in this testing type. System testing
is included in black box testing
> 2 White Box Testing

In white box testing we check internal working

of our code. So in this type of testing tester need
deep knowledge of programming language which
is used in our software product.
= Types of System Testing
System Testing have more than 50
types. Below we have discussed some
of them :
| Types of System Testing

‘~>| 1. Usability Testing

>| 2. Load Testing /

—> 3. Regression Testing

—! 4. Recovery Testing

5. Migration Testing

ma 6. Functional Testing

7 Hardware/Software Testing

Fig. 6.6.2 : Types of Sys

tem Testing
1. Usability Testing

use software to check user friendliness. .

Scanned by CamScanner
 It is non-functional test; mE.

his testing basically conce, Ntratey

"9 how wa,
os It js verified th:at after fow },
in urs trainj ily User }, Ande the
{ jcon used in user terface ; Dg, end
ae
© Not confugy np. .6 7
picture.
d or not) 8

i ove them,
impr
Loa d Testing
Load testing is a type
ndiiti
life load cond tions. of Performan ce Testing which
specifies perforn
; , “ee system '
Load testing hel 7 " sear
i ation beha
Ps to specify how the applPlic
time . ves when multiple users access it at same
find out
This testing normally used to
d to 4. The maximum number of of users who can access the softw. .
software at same time.
9. Specifies whether curre: * i
: ntly available infrastructure i.e. software and hardware is adequate
to execute the application,

Check what hap pen m w. wh en maximum su5 multanseoush: Ly.

Q
=

number of users accesses the system

4, Scalability
st tomer (action tak en i
to increase capacity of system such as increase storage etc.) to
te

ore number of users to access our application. .

It ig non-functional type testing.

ne

ati ons and Web based

Load testing is normally used when we test Client/Server based applic

applications.
ee

4 3.- Regression Testing k whether chan

ges have
is used to chec
sting is a type of soft
ware testing which fects existing working
Regression Te in requirement af
_
du e to so me error oF change
in code
| been made that old
gi ve assurance
functionality. ed test ca se s to
e already execut
in code.
rming changes ware does no
soft
t disturb
added in our
that new code

working of existin
.| .
after the systera crash due V0
+ 4, Recovery Testing ‘i
«, done to SP° iy wheter "
_ Recovery
Testing 18 or failure © network not av

disaster such 25 POW

Scanned by CamScanner
 af ge
Software Testing and Maintenance,
EEF? sonmare Engineering (MU - Sem. 6 - Comp) 6-24

- In recovery testing,
. system a i. identify the point whereup theto thebehavior
backagain perform the operations
«point : of 4.
a wher
point
system was correct and then from tha’

system get crashed.

> 6. graltion Testing
Migra ed to give assurance that the software 7
be moved from 9deg
- Mi > Z perform
without any proble
‘ m.
sjetons Baharia 5 to current system infrastructure
system,
- i,ion
In Migrat testing," we check data fro old system for the compatibility with new
data from
> 6G. Functional Testing
ional testing
Functional tes' is a type of software testing which checks that every function present in the
of user. net
software application works as per requirements
the eoftware
This testing includes black box testing and it does ngt focus on the source code of
application. ;
Every functionality of the system is verified by tester using appropriate test data and actual
result is compared with expected result. .
If there is difference between actual result and expected result then bug is considered,

Functional testing is done using Requirement Specification Document.

> 7. Hardware/Software Testing

In Hardware/Software Testing, we perform testing of communication between

the hardware ang
software used in our system.
- IBMcalled the Hardware/Software Testing as "HW/SW Testin
g".
67
Syllabus Topic : Software Testing Fundamenta
ls :
6.7 _ Software Testing Fundamentals _
The main aim of testing is
to search errors, and a good test is the test which has
probability of getting an a high
error.
Hence there is need to
design and implement a cust
, “testabilityin omized software or a product with
” mind. keeping .

~ Simultaneously, it is also necess

ary that the tests themselves should exhibit
characteristics which lead a set of
s ‘to encounter most
of the errors with min
- | Testability :James imum efforts.
Bach Provides the foll
owing definition for tes
simply how easily [a
computer program] tability: “Software testab
can be te ilityis
sted,”
,

- Operability ; “The
better it works
while designing an , the more efficiently it
d implementing 4 can be tested.” If qualit
system, comparativ y is focused
execution of tests, allowing smooth tesi e] Y small number of bugs wi
ll bl ock the :

Scanned by CamScanner
 observability : <w),,,
. t
outputs, Syste, You see tow
distinct

Wrong output jg ce 88 as yg VU teat,

8 Varig Tuts which
automatically. So SIMpPly idontin
es
is cog, S8ible, Se re Seen°F orBiven ag
Oetchaaae of testing return
_ Con'troll. ability ;ESE be
<T,,S08
eo iMG Of inte 's through execution,
d from and optimized.” Generat; tter we can “mal errors is done
olde, ‘ yO formats. The isting Ds of al} . >ntro] the softy
a the More the 7
x software and code be ¢ utp: is 4
control lone Using cone can be automated
item, ard :
Xecuteg
possible to Specify tests
| of input, » and
Sombinatio; n of input,nation
ome liently, a. Varial bles straj
by the test - enc: It is possible to ;
Decomposability ; “By co. mate them, ante

Ele St a
smarte, ntrolling- engineer. It is also
ent in the and perform » Teproduced,
«ates © retestin. the Sco
pe of ¢
testing, we can elebipnets
testeg inde ot of software isolate problems
Simplicity : “The |
Softwa _
ntly, System is implemented from
expected from the ote there is to test i Dende
; ctural simpl fenty, ,
i ene C8 the featur
simplicity nn? Mickly YY We ws can :
| Actua) j stru
um test it.” Functional simpli city is
simplicity (e.g‘B+ a codin.g., archi
g stan . ® Modula rizedthe tominim
| Sets j Necessary to me t requi =,
dard is adopted for ctecon —- Propagation of fact), and ood
mai , -
Inspection and Mainte nance).

/ - Un
j availability of thorough i :
5 : information
an i i regarding archi
‘ i / internal, external, as well as shared, test will teem r. “esHen and the dependencies among
gtd Characteristics of a Good Test

0.6.7.1 Write Characteristics of a Good Tes(Relt.seo. 67.

“(6 Marks)|
Se

eae
There are some characteristics of a good
test as follows :
ii, . .
- There is high
the totem P ey of,finding out errors in a good test. To achieve this goal, there is need for
understand the software thoroughly and try to develop a view regarding how the
software might fail. a
Preferably, the classes regarding failure are searched. For example, one class of possible failure in
a GUT is the failure to identify proper mouse position.
mouse
A series of tests possibly developed to exercise the mouse in an effort to exhibit an error in

i position recognition.
as resources.
test is not redun dant. There is limitation in testing time as well
| A good
as another test.
in per for min g a test which has same intention
There is no meanin g
t.
tests must be differen
- The purposes of diffe rent ts which have same aim,
time as well as
reed”. In a set of tes
be “best of 6
:
ld of just a subset of these tests.
A go od te st sh ou
ay mitigate
toward the implementa tion of uncovering & whole class
resource limitations m having highest possib
ility
| the test
uld prefer
| - Insuch situati ion, one sho

i of errors.
i
Scanned by CamScanner
 PP sotware Engineer:ing 6-26
Software Testing ang Mainte
(MU- Sem. 6 - Comp)
lex. Even if sometimes
= A good test should be neither nplex. tester can
too simple nor too comp r 5 a
Series of tests into one test that the possible
case, he should remembe: side effects Telateg with
this approach may mask errors.
— Usually it is better to execute each test separately. _

Syllabus Topic : White-Box Tes ting an

6.8 White-Box Testing

[2.6.1 Wite not on Wie Box Toring, eh oee 65) ae

~ White Box Testing is testing process in which we verify internal coding and in
software product under the test. Hructure of
White box testing is based on analysing the internal implementation s system
under test, Thus
Programming knowledge or detailed functional kn owledge of system is major PTe-requisite for
tester.
i
White box testing mainly
concentrate 6s on the testing flow of inputs and
software, strengthening . outputs through the
security and improving des
ign and usability of softwa
White box testing is re Product,
also called as Clear Box testing, Open Box test
Transparent Box testin ing, Structural testing,
g, Code-Based testing,
and Glass Box testing.
The term “white box” is
used to indicate tes ting of
code of software because
Present inside the box, we can see what is
~ The clear box or white box
term indicate the capabilit
internal workings, y to see via outer Part of sof
tware into its
‘
~ It uses following met .
hods :
o Statement coverage
i.e. testing all progra
mming statements usi
tests, ng minimum number of
o Branch coverage : This '
is to ensure that all branch
once, con ditions in system are tes
ted at least
© Path coverage : It inc
ludes ensuring that eac
least once, h statement and branch
in system is tested at

ifferent coverage
types such as Cond
ition Coverage, Multiple

White box testing involv

es two steps. They
are:
Step 1: Understand the sou
rce code

Scanned by CamScanner
 3 White box testing *
. 1Ncluq,
» Tes! have very high },
Ss tonti
s tester = zoe the test. “vel *Mowledzg or rose
e effects ranted
mbiwit
ne , a ; - sec
Seeurity pro
is ble
basims
c and
Purpose of Performin
g “ns
malicious code in cohwan the eon e the 80 Are te Used in ro tuet, So the te:
:
. are
f; he softwareProduct went
—————__ ct rom at; Sti
steptthe2* sec ond test
Create stepcase
in s and &xecut, ie A. So -
Knowingly or aeOwiby ng}hackers. 8nd
ee one
naiy, should be able detect
- under the test for
oe White box tes
. 8 Of pro "
oe - The tester will generat, smal] ting in, te mae

e=ra] = lene product.

ine. ety
er low of contre
*28t eR for yee nd Vest ing the Sou
every StUCtury, NS Ede of wttrnsspretuc
Pee
.
frastry
ctuz
oe _ White box testing
pnowledge of pr,
may be ster shoula ee ,
in the software
r be pergy -
high leye]kn,
i ler test, Thus gr:; amming lan
dvantages of Pro "med by the dev elope
Fequisite g, yb! A Wh
esd in “a
are °meas ©vel
abouoper
t sSource cod
hay
te Box Testing ci der
t
Mrodsetunder the
i
Following are the advant test ER Tov
hrough the
ages of White bo 3 ad
. _ . Asit tests all possibjg
: Paths of Niesting :
ol tose °f system it ;
- Whi ite Box Test
esti,ing can be @pplie
Sting, _ As ‘ester has knowle d atearlie‘8r @test
thro
i,
i
dge of internal ang
hae ect. Stage as there is'ng need to wait for
i inpu
i tt helps isi testini g, GUL.
. & ait* becomes easy for ‘ester to
- White box testing find out which type of
Per forms Code optimiza
into tts
. . tion ion thro uy
z= Automa tion of White ;
box tests cases can
be done e. asil sane
_ Whi te box testing is y, hen >
| i
start wise bistrtes
ict bec ause
ono
Wecan
tin each and every statement
of cod le
8 early as soon as firs i .
tested at least one time
t module of software
482, Disadvantages of White is created. ,
Box Testing '
,oast
Following
. are the dis
i advant
ages of white box testing
:
at - White Box Testing is comple
x and expensive process,
- For testing larger applications usi
ng White Box Testing, it becomes imp
: exhaustive testing. ossible to perform
; :
- White Box Testing tests the software as it exists, hence missing functionality of system may not
be discovered.
- It is necessary to select all possible inputs to test each path which is time consuming process.
in software then there is"
- If Ifw white box testing performed by developers who develop code present
related errors.
less possibility to find out development
; : ‘to .
box testing, we need expe’ rt persons . who have deep knowledge of ‘.

; While performing ae which Application Under Test (AUT) builds. \

: programming language

Scanned by CamScanner
 Software SRS Maintenance
BF sonware
wotiware Engineering
Enginoering (MU - Sem. 6 - Comp) 6-28
—
In on,
— Syllabus Topic : Basis Path Testing

Basis Path Testing

PD (MU
- Dee. 15, Doe 7
Explain cifforent techniques in white
box testing. (Ref. sec. 6.9) EE
(Rot. soc. 6.5 ss
Basis path testing is considered as a white-box testing technique.
It. was proposed by Tom McCabe. These tests guarantee to execute every statement in the
program at least once during testing. Basic set is the set of all the execution paths of a
Procedure.
6.9.1 Flow Graph Notation - |
Before basic path procedure is discussed, it is important to know the simple
notation used for the
representation of control flow.

This notation is known as flow graph. Flow grap

h depicts control flow and uses the followin
constructs.
g

These individual constructs are combi

ned together to produce the flow graph for a Particular
procedure,

Sequence O—O
:

If

While

Fig. 6.9.1

Scanned by CamScanner
 Ago ftare. Engineerin MU . Som m
mes CO}
pasic Terminol
gf ogy *SSoclateg whe, 8-29
Node
stil
: Each flow raph nude ve
Tho FI
contains a conditio,
dition is; callog aw Pro;Sen) or ins
- Edge : Edge is thy ° icate node, 0
nnectio
control. An edge sae n betwoen
termin two Nodeg.
procedural statements ato at a Node ' The eg

- Region + A region in a flow gr

nt in! ‘a
the
. Ure,

f‘Or the
> (MU - Dec. 47, May 12)
. Dec. 17, May 14, «
owing f} . contains OOcontro] ion flow
statements A, from the start point to the =end
. ere are .
the control statement. various “xecution paths: depending upon dlecision
- - eci taken on

2. Cyclomatic complexity, V(G),

for a flow graph G is defined as

WG) = E-N+2

where E is the number offlow graph edges and r

i N is the number of flow graph nodes.

8. Cyclomatic complexity, V(G), for a graph flow G.is also defined as

/ VG) = P+1 | | |
s contained in the flow graph G.
Where P is the number of predicate node
following flow graph.
Example : Consider the

Scanned by CamScanner
 set Le er a ae
i, s
1
ee
es

ey Software Engineering (MU

- Sem. 6 - Comp)

Region, R 6
Number of Nodes
= 13
Number ofedges
= 17
Number of Predicate Nodes
= 5
Cyclomatic Comple
xity, V( C)

VC) =R=6;
. Or

VC) = Predicate Nodes +1

5+1=6
Or
WC
= E-
) NaQ
17 ~1342= 6
6.9.4 Deriving Test Case
s
_- The main objectiv
e of basic path te
sting is to derive
The process of derivi the te, st cases for
ng test Cases is as the Procedure unde
follows : r test.
From the design
or source code, de
rive a flow graph.
_ 1. Determine the Cy
.

clomatic complexi s

ty, V(G) of this

*

discussed abovo. flow graph using

‘

any of the formul

a
2. Even without a flow
graph, V(G) can be de
statements in the co termined by counting
de and adding one to the number of conditio
it. nal

Scanned by CamScanner
 gineering (MU - 5,
em. 6 = Comp)
:
Prepare test cases th
3. a

ty nen” & Xecuti*on of

executed and compared to the expe cted results,
wax
aintena
ce

: graph Matrices
is a two 0 didi mensiong} mate
Graph matrix
Tix that h, elps in
and columns.each determ| inin
to number of node 8 in fl
in,equal the basic wet. 1t has
one
try cor res pon d:
gpn ow Braph.
ond
i
8 to each node-node pa
7
air Teprese:
edge e 18i
Baachch edg represente:
ti
to dissti nts an edge in fl ‘OW graph.
a
by so
d ed wi me let ter ngu ish it f,
h ed, ov id ro:om oth er edges,
Then eac ge is pr wei
- - with some link weight, 0 if there ;
‘ 18 no connecti
connection. on and 1 if there is

For e
a pro
° vidrap
ingh wei ght s eac
nan tes h lett
ia oc t erson
is replaced by 1}
y 1 indicating a connecti
on
on matrix.
.
Bach row with two 0 entrieentri s represents a predicate
node.
the entries is
Then for each row.sum of obtain :
for each aeeiaiiianinieeia
Now the : value so obtained each row is add
ed and 1 is again added to get the cyclomat
: ic
complexity.
.
the internal” workin: g of the different procedures is tested, then the testing for the overall
‘Once ona
functi lity of black box testing techniques are used
.
gram structure is tested. For this

Syllabus Topic : Control Structure Testing

ing
6.1 0 Control Structure Test
o
e
Testing in det
9

fa.6.10.1_ Explain Contiol Structure we hav e se en in previous

section is itself a technique
technique wh ic h
The basis path testing structure testing.
category control fficient in
which comes under the
as hi gh ly eff ective, it is insu
simple as well
pa th te st in g is considered as
Even if basis
testing.
itself. on control structure
other variations
go in g to see some testing.
- Now we ar e
i m p r o v e th e quality of white-box
n testin: g
helps to
These broade
l condit ions
ing t the logica
610.1 Condition Test c h w o r k o u
design h\ i
a test-case |
ably preceded
h most prob
itil,

i o n , w h i c
le. press
am modu ora relat
ional ex
.

.
pie
om
oe

Scanned by CamScanner
ai
iii i t ae

Software Testing and Maintenance

[FF sottware Engineering (MU « Sem. 6 - Comp) 6-32

~ Arelational expression takes the form

El <relational-operator> E2 rator> is nny one
where El" and dk £2 are arithm aB§ ns whereas the <relational-ope
ithmetic expressio of >,
(
>=, =, #(non-equality),
quality), < or <=.
: / or more simple conditions, Boolean
In a compound condition elements present are; two
Operators,
and parentheses.
It is considered that Boolean operators which are probably per ‘ 4 nd ;
mitted in a compou conditio. n
contains OR (|), AND (&), and NOT (7). wool .
Acondition which does not contain relational expressions is considered as a Boolean expression.
Ifa condition is wrong, then minimum single component of the condition is wrong. Hence, types of
errors in a condition contain Boolean operator errors (incorrect/missing/extra Boolean
operators),
Boolean variable errors, ’ Boolean parenthesis errors, relational operator errors,
.
and arithmetic
.
expression errors.
~ The focus of condition testing is mainly on testing each
and every condition in the application to
make sure that it is error free.

6.10.2 Data Flow Testing

- The data flow testing technique opts for test

paths of a program based on the placemen
definitions and uses of variables in the respective ts of
program.
- Forthe illustration of the data flow
testing approach, consider that a uniq
assigned to every statemen ue statement number is
t in a program. Also we will assume
that functions in the program will
not make any changes in their par
ameters or global variables.
~ Fora statement with S as its
statement number,
PEF) 1% | statement S containsa dtntioofnX} USES)
~
{| stalohen! eae 7
Ifs tatement S is an if or loop
statement, its DEF set doe
USE set depends upon the s not contain anything
condition of statement i.e, empty and its
8.
~ The definition of var
iable X at statement
S can be considered
S’ provided a path is present from statem
as ]i
definition of X, ent S to statement
S’ which do not have
' any other
.

Scanned by CamScanner
 In such case,
Band Maintenance ’ testing:
g
jooP Testin
| any one or >,

20 Operators,
» they are not g
poop testing is considereg
.
Ri
QB

id condition hicnt
Sufficie se, ce *
importan
*,

validity of loop constructs, deg ® white-box testing a ique whi h foeu

loops it is pos sib le to € dates
For it i fe * 7 on the
pression, me
erent Classes: . sim, ple1
s our diff
Joops, and unstructured loop * . loops,
, types of
perators), Tated loops, nested

‘ithmetic

ation to

Fig. 6.10.1 : Classes of Loops

loops, where n is
Simple loops : The following given series of tests can be carried out on simple
the maximum number of permissible passes through the loop.

1. Skip the loop entirely.

2. Only one pass through the loop.

8. Two passes through the loop.

the loop where m <n.
4.“ m passes through
1 passes through th
e loop.
n-lna,nt ed loops, there
§
ap pr oa ch for si mple loops to nest
is need to extend the test
Nested loop| s : If there te st s with increase in
th e level of nesting.
the number of possible n Am er ic an software engi
neer)
is increase in Be iz er (a
umber of tests.
te impractical n .:
the number of tests
to all other loops.

Scanned by CamScanner
 Software Testing and Maintenance
key Software Engineering 6-34
(MU -A Sem . 6 - Comp) olen keeping the outer loops at their: lowest
$ st Too}
2. Carry out easy loop tests for the innerm
o )
'
values. Introduce different tests for out.o¢
iteration parameter (for example loop counte r.
range or excluded values.
ding all other outer Io,
: 3. Workt outward,
rd, whiwhilo executing tests for the next loop, but holding . SPS at
s to “ty“typpical” values.
minimum values whereas other nested loop
\ 2en
loops have been tosted.
4, tinue the process unless all .
Con ted ‘ = It is possible to test concatenated loops with
- Concatenat the help of the 8pproach
oops : It 1 .
defined for simple loops, if all of the loops are not interdepen dent.

loops and the loop coun ter for first loop is used a th
ver, if there i
i concatenation
is 0. f two
However,
independent.
starting value for second loop, then the loops are not
d
When en there ere 1Sis dependency of loops on each other, then the approach which has been applie to
nested loops is recommended.
Unstructured loops : Whenever possible, it is essential to redesign this class of loops so as to
reflect the use.of the structured programming constructs.
SSL,

Syllabus Topic : Black Box Testing . @

a as 2s SS S99... Ey

6.11 Black Box Testing

[0.6.1.1 Explain Black Box testing. (Ref. sec: 6.1 eons

- ‘The software testing methods which test the functionality of an
application without knowing its
internal structure, coding information and knowledge
of internal paths of the software is called
black box testing.
- In this method test cases are built based on what
application is supposed to do.
~ _ Itis also known as behavioural testing or
specification based testing.
- In Black Box Testing we concentrate on
inputs provided to software product and
software product without applying output from the
compulsion about knowledge of the
used in software under the test. programming language

Black box testing can be applie

d during each level of softwa
re testing process.
- It makes use of various testin
g techni ques like Boundary Valu
decision models ete. e Analysis (BVA), equivalence class

Inpput E> | Output

Executable
Program. |.

Fig. 6.11.1 : Black box

testing

Scanned by CamScanner
 o
(ware Tes
Soltwara Testing and Maintenance
the steps Ww hich are use 1 to po rior
f m b lack b io xt eating }
7
ments a pe
“) 1 " require ications of tho ystem
i i or } anal yzed,|

itive t
test data i.e. data for pos \ ,
j- geste select valid Ont sconari
r10 to vor if 'Y whether application
under
§
t data and gi as exp ect ed
to processes tha
and giv o out put
3 yes4t jsjs 8 able
ati |
tester selects invalid test data for neg
lo gi ns tes t sce nar io to vorify whot!
‘ piso ple to process chat date and give output as expected
nee
test is
a.
; ester state expected outputs for cach test dat
tes test cases witi h the selected test data. Then test
.° ar e tester genera
—
ison between the a actual
peware tester performs compar ee
i
pe fect is- detected if actual resesulultt is not same as expect res
ed ult .
6.
ed to developer.
._ hen detected defect is report ae
can th en fix tha t defect and then application is retested by tester.
:D eveloper
i ng methods are used in Black Box Testing :
‘
lo P ing g tes t ca ses followwi
got deve
VA)
spssd ary Value Analysis (B ries of the input
_ ry val ue ana lys is is a process of testing bounda
d . the name indicates bo un da

yalues-
ed technique in BBT.
itis most commonly us m, jus t above minimum, nor
mal value,
ues at their; mi ni mu
to select input val
Here pasic idea is
value.
just below maximum
jaximum value and
ioning.
me s aft er the equ ivalence class partit
vA always co
oning into
n c e class partiti ib le in pu ts by dividing them
g
ti) q u i v a l e er of all po ss
rt it io ni ng re duces the numb
ass pa
- Equivalence cl
t values.
classes. av oi ds re du ndancy of inpu
oroughly and
It te st s ap plicatio n th
_ sting.
d at all levels ofte e is applied.
It can be ap pl ie
va lu e an al ysis techniqu
undary
al wa ys pe rf or med before bo re la te d an d use d togeth
er.
- It are clo!sely
ui va le nc e partitioning
BVA and eq ors that
em an d all the fact
ct graphing tput of sy st
(ii) Cause - effe t i o n s h i p be tween ou
lains rela
ni qu e g r a p h ically exp tielbe
- This tech em
tput of syst f any specific
CB" test cases
such
affect the ou i k e s se le ction of
i "aviour of
S¥S tem. It ma
eh
. oen xteernal b
eys the ee
l
d e n t
i que te st s effec ts.
s techni the
he e
> Thi e cause
-
a t t h e y l o g ically relat
th
t

Scanned by CamScanner
 keep Software Engineering (M
- U
Som. 6 - Comp) 6-36 Sofware TeandsMai
tntoo
nanes
(iv) Error - Guessing .
:
Error guessing is a technique which mak ; d skill for testing : similp,
es use of tes ter s De temnal techuiiques.
applications to find out defects whic
h may not be dete ed by
us
It is usually done after formal testing
.
techniques are app lied.
It list outs all possible defects in system and then design tests which will atte
mpt to produce
uce them
The success of error guessing technique is mainly depends
on knowledge and skills of tester.
6.11.1 Types of Black Box Tes
ting
1. Functional testing ~

Functional testing is a type of software test

ing which checks that every function Presen
software application works as per requirements of user t in our
or not.
Functional testing includes black box testing and
it does not focus on the source code of the
software application.
.
All functionalities of the system are veri
fied by tester with the hel p of suitab
compare actual result with le test data and
expected result.
If there is difference between actual
result and expected result then bug
is detected.
Functional testing is done using Requ
irement Specification Document,
2. Non-functional testing

— In this type of black box

testing, we do not perform
testing to test specific functiona
Non-functional testing is lity.
used to check non-function
scalability, usability, and al req uirements such as perfor
security are fulfilled or not. mance,
3. Regression testing

- This testing is pe
rformed to give gu
arantee that new
any interruption in code added i
working of existing functionalit
ies,
6.11.2 Advantages of Black
Box Testing
(i) It is efficient for lar
ge systems,
(ii) It identifies contra
dictions in functional
Specificat ion
(iii) Detailed functional
knowledge of system is not
(iv) Tester and develo
prerequisite for tester,
per work independently,

Scanned by CamScanner
 Engineering «
6 - Comp)
Ca Sem. oo
ee ng
: “3 pisedvantages of Black Box Testi Setemaes Tasting andi airtenanes
ro Testing and Maintonance,
@ It is difficult to find out all possible inputs for
iiwet test-case in lirmited tine
' (i Test method cannot be used for Singl
:kill for testing simila,
ji) Test cases cannot be des’ ee
iques. !
‘ened ns knowledge of funeti.
netional Bpecifications
(iv) It may leave many program paths un
tested beca us
of time eai int,.
constr
mpt to produce them, pifterence betw:
een White Box Testi Ng and Black Box Testing Techni
kills of tester. i git-4
> (MU - May 15, May 15)
6.11.2 pare white box and black box

e0t4)| ee |
tion present in our =parameter | Black box testing
= A
It is mainly applicable athigh
sgpicable levels
levels of testing : °F : _— applicable at lower
source code of the a . levels of testing i.e. unit and
' bo wed
Acce integration testing.
Cie and system testing.
:
— nating _—=
and specification i
ple test data
- se for irement
tidaiteme te a isthe Detail design is the basis for White .
aa Box Testing.
Box Testing.
_— -
, estini
3 ed out by
b It is carried out by software testers. |It is carri
d
fF performed y
developers.
ms
It aiat how syst em
is perfo rming
‘Ain It aims at what functionality ts

system performing. its functionality.

lity. i
Programming knowledge and
Programming knowledge and
| performance, : pequirements implementation knowledge is
i implementation knowledge is not
necessary to carry out WBT.
necessary to carry out BBT.
\it is more expressive than BBT
- It is less expensive than WBT.
— |cost :
In black box testing, we do not test |In white box testing, we test the
co tecarenon Focus 02 code and focuses on the security
of
the code and focuses on the
coftware product and flow of control.
functionality of software product.
ee that old j nae . «no provide
does not ean
box testi ng
.
provi des facility of White box testing
:
.
j
{Facility provided
Black
ation among facility of verifying comm
| verifying communic
3 not make among different modules present in
different modules present in software product.

software product.
po nance
la bu s To pi c : Software Mainte
"Syl
ails

nce
6.12 Software Maintena
alt

Scanned by CamScanner
 fez Software Engineering (ML J - Sem. 6 - Comp) 6-38 ! Software Testing and Maintonancg

= 5
Mainten c h angi B
ance is requ ired to gi give assuran
rance th that th the softw
fiware has ab ility to satisfy the

uirements of user.
- Nainintenance isis important phase for software product which is developed using any SDLC mode}

non corrective software act: we :

Due to corrective and ions, ea need to make changes in Software
products.
Following are the needs of maintenance :
1 To correct the defects found in software product.

2. To improve the design of software.

3. To improve performance of software product,
4. To add new features. :
5. To improve communication with other software.
6. To transfer legacy software system into new software system.
7. To replace the old software by new software.
6.12.1 Cost of Maintenance

' Maintenance requires high cost. A mos

t important part of the financial reso
maintenance in a software life cycle. urces is spending on

A study on estimation of cost for

software maintenance found that
high as sixty seven percent of the the cost of maintenance is as
cost of overall Software Developme
nt Lifecycle.
Making group of enhancements
. and corre ctions in
misunderstanding related to management reports causes some
high cost of corrections,
Understanding the types of
software maintenance assist
software maintenance, us to understand the structur
e of cost of
Understanding the factor
s that make bad impact
assists us to guess the cos on maintainability of software
t ofmaintenance, application can
Few environmental asp
ects and their relationship
following things : to software maintenance
costs includes
1. Operating environment
includes hardware and
software,
2. Organizational environm
ent includes Policies, com
petition, process, produc
t, and personnel.

G Requirment
EJ Designing
[7 Implementation
0 Testing
0 Maintaince
Fig. 6.12.1 : Cost of maintenance

Scanned by CamScanner
 18 engineering (MU - Sem, 6. Comp

ghe cost required for softwa

re mai
d Maintenan ce
- jnto the software developmen élifocrn er .
8,
2© chan Bing

ILC mode}
Software _ Legacy software which work
on slow
prove itself better than newly
comin
AS technology advances, i
are costly.
Most engineers who Perform A
to find out problems.

ware-end factors which inc. |

ry soft increase Maintenang,
_ Structure of source code of software
© Cost
a } oo

_ Programming Language, , | ~
- External environment dependencies, oe t=.
- Staff availability and reliability,
°
a Syllabus Topic
: Types of Softwa
a re Maintenance

419 Types of Software Maintenance

_ > (MU- May 16, Dec. 16)

(@.6.13.1__ What are the different types ofmaintenance? (Ret. sec. oe

Types of maintenance

1. Corrective Maintenance

2. Adaptive Maintenance

3. Perfective Maintenance : ;

4. Preventive Maintenance

Fig. 6.13.1 : Types of maintenance ‘

|
1, Corrective Maintenance
in
typ e of mai nte nan ce con tai ns changes and updation performed for fixing of defects found |
- This .

ed by end user or tester.

software product that are detect

Scanned by CamScanner
 EF sontware tn neerin
Se g (MU - Sem. 6 - Comp)
ginger 6-40 Software Testing and Maintenance
~ In corrective maintenance,
wo perfo rm actions for correcting the defects in our software
that mako bad effect on differ
ent parts of our softwa ssenign, lagle or cod Product
re product such as _
This type of maintenance is oe, le.
emergency maintenance in whi
tempor ch unschedu hange
arily keeping software in ope one for
ration.
Corrective maintenance has ;
approach to examine the
the system was origin original specifications to
ally des: igned to do. state that what
- Because of pressure
given by manage ment, the
emergency corrections maintenance team release
called as patching. small codes fo.
Twenty percent part of all the
maintenance activities are per
formed to do corrective mainte
> 2 Adaptive Maintenance nance

ance contains making changes in softw

make change in our software

- Adaptive mainte
nance includes
updating
environment like
the hardware or the
operating system.
- Here, the concept
environment is us
applied on the sy ed to point to the
stem. conditions and the
influences which
- are
For example, bu
siness rules, wo
rk Patterns, and
Software application. government poli
cies are factors
: which affect the
oy
' will have a Sign
ificant effect on

-— Adaptive maintenan,

, Rew features
for increasing
the

Scanned by CamScanner
 off inee Softwara Testing and Maintenance
otive maintenance includes performing enhancemonts in functionalities of application
perl are in addition to enhance the performance of software application
g0 : : ‘
icontains enhancement in both functionality and in efficiency of the source code and modifying
7 ef netionalities of the software application according to changirig needs of users

perfective maintenance contributes 50% of total maintenance which is the largest of all the
- paintenance activities.

tenance
preventive Main
a preventive Maintenance contains changes and updations to avoid problema in future software
application.

its objective is to solve the problems which are not major at this point but may cause serious
y igsues in future.

nce of errors.
preventive maintenance includes applying changes to avoid the occurre
preventive maintenance also includes doing actions to avoid the occurrence of errors.
y of
it tends to decrease the complexity of software application by improving understandabilit
program and growing maintainability of software application.
It includes documentation updating, code optimization, and code restructuring.
are affected by the
Documentation updating includes making changes in the documents which
changes related to the present state of the system.
y execute the program or to use
Code optimization includes changing the programs to quickl
storage space in correct way.
am for decreasing the complexity of
_ Code restructuring includes changing the structure of progr
source code and making it understandable.
e organization and no outside requests
_ Preventive maintenance is performed only for maintenanc
are accepted for this category of maintenance.
maintenance activities.
_ Preventive maintenance contributes 5% of all the

Types of Software Maintenance

Perfective Preventive Corrective

Fig. 6.13.2

Scanned by CamScanner
 EP sonware Enginooring (MU
- Sem. 6 - Comp) 6-42
Software Testing and Mainte
6.13.1 Steps to Create Ma naneg
intenance Log

> (MU- May 16, Dec. 18)

Steps for maintenance log. | 860. 6.19.1
A maintenance log is a doc
ument that records who did
what, when, and why.
— Maintenance logs are extremely useful
for troubleshooting recurrin g or obs
Provide a record of all work performed cure problema, as
they
on the system and m ay shed light
interactions betwee n seemingly unrelated sym on hard-to-e pot
ptoms.
Maintenance of your val
ued assets is an essential chor
e to perform at regular inte
would happen if you own a ry als. What
precious metal ornament and
it gets rusty over time?
lose its value,
therefore to keep your assets in a pres It wil l certainly
entab] le and functional con
maintain them on a timely basis. diti on you
Same is the case with yo ur pro need to
not maintained with time they perty and vehicle tha
will be de-valued. t if they are
To keep an organized maintenan
ce Program it is better to desi
maintenance schedule of gn a log in which you can put
every equipment your
you own.
Let us consider the example
;

Equipment Maintenance Log

The maintenance log is

a thing which hel
i
Maintenance logs are crucial because they PS You in a case of coll
help to mai apses, damages and repair:s. |
set program, stuff, kits or tain the intern
al or external
vehicle on Periodic interlude scam of your
s,

Scanned by CamScanner
 - qhe : maintenanc
‘i: e log ig usually sk, ete)
provide services on contract basis, : the a
hed in
. Generally, maintenance logs refor
. gervices that it will retain its ana &et an
In future

g. Outline the cost of maintenan,

SPot ce,
4, Smooth flow of operations with
: no bu gs
at 5. Emergencies are possibly
: with a maintained
ned enyj +
ly Several pre-designed on-line te ‘vironment.
mplates are 7 *
available for :
websites vawrent categories for the ‘sketchi Ng your Maintenance
different mai .
logs. Ma y
documen friendly way. Just downloagainte
8 log in a user-fri the tea ee Microsoft excel also
mplate and maintain -
Syllabus. Topi everything,
c : Software
Re-engineerjting
:\\

re Re-engineering |

can stay in the current market,

it is known
Software Re-Engineering is process of re-structuring
or re-writing components of old software
application without modifying its functionality.

- Itis a procedure where the design of software is modified and source

code is re-written,
- Old software system cannot use with the latest technology available inl the market. If we use it to
perform some task, then we may face lots of problems such as hardware become out of date,
updating of software becomes a problem.
For example, in the beginning UNIX was developed using assembly language. When C language
and
was developed, UNIX was re-engineered in C, as writing source code in assembly language
understanding it become difficult.
software product require more
developers observe that’ some components of
Sometimes
maintenance than o ther components and such
components are requiring re -engineering.

Scanned by CamScanner
 ome=e
e
pe
7”, -

Rs eee :
‘\ L Cine -
1 ct eal if

eR
6-44
~ Re-Engineering Procedure
includes following steps
: oe complete software
1. Decide which components of software we wan
t to re-engineer.
some components of it ? or
2. Do Reverse Engineering to find out fea
tures of existing software. _
3. Perform restructuring of source code if
needed. For example modifying function-
programs in object-or
iented programs. crienteg
4 Perform restructuring of data if needed
.
5.

Ca
Use Forward engineering
idea to generate re-engineere
— There
d software.
are some importan:
t terms used in Software re-eng
1. ineering.
Reverse Engineering

Itis a procedure to get sys

tem s pecification by analyzing and understa
This procedure can be reverse ndin
: g the existing system,
software development life cycle
Phase to requirement gather mod el, i.e. go from maintenance
ing phase.

Fig. 6.14.2 : Reverse Engine

ering .
2. Restructuring of sou
rce code

of the already existing

software,
It is associated with
re-arran,
fing the source code.
. Perform source code-r In Restructuring of so
estru cturing or data-r urce code, we can
estructur ing or both.

3. Forward Engineering
- Forward engineering
is a Procedure of find
hand which is output ing desired software
of reverse engineerin product from the re
g, quirements in
- - It presumes that so
me

Scanned by CamScanner
 ro Engineerin (MU - Sem. 6 - Comp)

mponent reusability
C

system
It may be a small module or sub-
a
y | labus
Syl Topic : Reverse Enginee Tin
1 ig

iented soften
pe
> ( wu- May 15, May 18, May 12)
G61 “Explain softwar
: e reverse :éngineering
a in detail. ~ (Ret. sec (Met.sec. 6.15)
6.15) eee
9 6.18-2 Write note on Reverse Engineering. (Ref sec,

Itisa procedure to get system specification by analyzi erstan

_
a.life
This+. Pp procedure can be reverse software development 7 me = a
em.
“pele modish Le. @9
nce
phase to requirement. gathering phase.
| 3
_ Reverse engineering is : the procedure
" > th at recognizes S an obj ect, a devis ical properties

/ systema7 through
on -analysis of architecture of system, functions
onal
and operat‘ations. 4

Cons ler existing system has design about which we do not know anything. System designers
perform reverse engineering by analyzing the source code and attempt to get the fais
of softw are
With the help of design, designer attempt to make conclusion about-specifications
product.
e w software works in order to
ess of analyzing an object to observ ho
- Reverse engineering is a proc
ures in the object.
duplicate or add new feat
many times it is used in
ine eri ng is inv ent ed in older industries and now
Idea of reverse eng
generation.
h ardware and software
computer of program which is in the
ing & machine code
wa re re ve rs e en gi neerin, g includes revers
So ft source code.
ce of Os an d.1 s. It istransformed into the
format of the sequen code of a program
since the
to fin d out the 5 our ce
neering i s performed enhance the performa
nce of a
Software reverse engi ram do spe cif ic ta sk s, to
study how the prog m or to detect un
secure
source code need to an error detect ed in the pr og ra

program,
repair a bug ie. Cc rrect
to
program like virus.
contents from

Chapter Ends...

noo

Scanned by CamScanner