Tnblo of Contents

Modulo 1

Chapter 1 : Introduction to Software Ennhiootlnn and Proconn Modoln 1-1 to M6

Syllabus : Nature of Software, I'olhvaio l nglnrcitng, Kollwnrn I’roctwr, Capability Maturity Model (CMM). Generic Process Model,
PrescripUvo Pnxvss Models : Iho Waterfall Mixfol, V-modol, Incremental Procosa Modelo, Evolutionary Procoso Models, Concurrent
MaI.?!-:, Agile I]ny2 , iljily Pjlociplon. Extremo Protirnminlnp (XP), Scrum, Kanban model.
1
1.1 Software ‘*

Syllabus Topic : Nah ho of Software.

Nature of Software
1-3

____ . ................................ 1-3

............... 1-7

............................ 1 -8

................................... 1*9
......................... 1*10

1 .4.1 comparison witn conventional tngineunriy riuvuoo ........................................................

...................... 1-13
✓
....................... 1-13
1.5
..................................... 1-14

................................ 1-15

....................................... 1-15
1.6
✓
...................................... 1-19

. ...... 1*1u

........................................... 1-19

. ....... 1"21

.......................................... 1-21

........... ...... 1 “2d

✓
................................. 1-25
1.8
_i i ...................................... 1-2o
1 .8.1 Difference between watertail moosi ana rncremenmi muum.............................................
........................................... 1-27
✓ Syllabus Topic : Evolutionary Process Models .........................................................
............................................... 1-27
1.9
....... ....... 1-2/
1.9.1 Spiral Model (Dec. 17) .......................................................................
........................... i-2y
1 .9.2 Prototyping Moaei (uec. i . . ......................................................... -
............................................... 1-31
✓ Syllabus Topic : Concurrent Models ....................................................
. .................. 1-31
1.10 Concurrent Models

✓ Syllabus Topic : Agilo Process

1.11 Agi’o Process (May 15, Dec. 15, M a y 16, Dec. 16, May 17, May 18) -

✓ Syllabus Topic : Agility Principles ............................................................. -

1.11.1 Agility Principles (May 15, Dec. 17) ........................................... —

1 . 11 .2 Advantages of Agile Process (May 1 6) ....- ----------------------------------------

1.11.3 Difference between Prescriptive Process Model and Agile Process Model

Scanned by CamScanner
✓ 2
1.12 V
Extreme Pm. * n10 Pro
9 rarr »rning (XP)..

p
-: x:r"— i
S
y«ab us Topic : scrum.... ............................
1.13
Scrum (De C> .....................................
✓
bUS
? Topic: Kanban Model...
1.14 K
ban Model

Kanban (or Software Teams

Kanban Boards
1.14.3 1*4
Kanban Cards
1.14.4 (Advantages ol Kanban1
1-4
1.14.5 i
Comparison of Scrum and Kanban.
Chapter Ends 1-4

Module 2
Chapter 2 : Requirements Analysis and Modelling 2-1 to 2-3

Syllabus . Requirement Elicitation, Software requirement specification (SRS), Developing Use Cases (UML).

Uirement Model
- Scenario-based model, Class-based model, Behavioural model. ______
2.1 '------------------- 2-'
Requirement Engineering (Dec. 16)

Activities Involved in Requirements Engineering. ......... 2<

Syllabus Topic : Requirement Elicitation 2-

2.2 Requirement Elicitation (Dec. 17) ......... 2-4
2.3 Requirement Analysis .................. 2-7
2.4 Types of Requirements ....................... 2-7
2.4.1 Functional Requirements (Dec. 16) 2-8
2.4.2 2-9
2.4.2(A) Types of Non-Functional Requirements 2-10
2.4.3 Domain Requirements ’.................... ...... 2-10
Syllabus Topic : Software Requirement Specification (SRS)
2-10
2.5 Software Requirement Specification (SRS) (May 15).............
2-10
2.5.1 Advantages of SRS
..... 2-11
2.5.2 Characteristics of SRS
..... 2-11
2.5.3 Format of SRS
..... 2-13
2.5.4 SRS Document for Online Student Feedback System (May 15)
2-16
2.5.5 SRS for Hospital Management System (May 17, May 18)
.,..2-19
Syllabus Topic : Developing Use Cases (UML)
....2-22
2.6 Developing Uso Cases (UML)
....2-22
Syllabus Topic : Requirement Model
....2-25
2.7 Requirement Model
...2-25
2.3 Analysts Modelling
...2-27
2.8. 1 Analysis Rules of Thumb
...2-28
2.8 2 Elements ol Analysis Model
Syllabus Topic : Scenario-based Model ...2-29

2.9 Scenario-based Model

2.9.1 Writing Use-Cases.-

Scanned by CamScanner
 IU - Sem. 6 - Comp)
Table of Contents
2.9.3 Swfmlanc Diagrams .............
Syllabus Topic : Class-based Model... ...... 2-31
2.10 ...... 2-32
Class-based Model ............... ................
....... 2-32
2.10.1 Identifying Analysis Classes
........ 2-33
2.10.2 Specifying Attributes .............
........ 2-34
2.10.3 Defining Operations ................
....2-34
Syllabus Topic : Behavioural Model
..... 2-35
Behavioural Model............................
.....2-35
Chapter Ends
2-37

Module 3 '

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 : LOG, FP, Empirical Estimation Models : COCOMO II Model, Specialized Estimation Techniques.
Project scheduling : Defining a Task Setjor the Software Project, Timeline charts. Tracking the Schedule, Earned Value Analysis.

Management Spectrum, 3Ps (People, Product and Process)

Syllabus Topic : Process and Project Metrics.......................
Process and Project Metrics ....................................................
3.2.1 Metrics in the Process and Project Domain ....................................................................................................................
3.2.1(A) Process Metrics and Software Process Improvement ...................................................................................................
3.2.1(B) Project Metrics ...................................................................................................................................................................
...................................................................................................................... 3-6
Syllabus Topic : Software Project Estimation
3"6
................ 2-7 3.3
3.3.1 Metrics tor Size estimation (May i o , uec. i o , w a y ■. . .......................................................................
.............................. . .
.............................3-8
.......................... . ........................... 3-8
........................ . „ , „ t r. ......................................... 3-8
....................... . ........................... 3-8
3.3.3 Function Points (FP) (May .. ......................................................................................
...................... . . .....................................3-10
Syllabus Topic : Empirical Estimation Models .....................................................................
...................... . ................................ 3-10

.................... 2-11
.......................... 3-11
................... 2-11 3.4.1 COCOMO II Model (May 15, Doc.16) .......................................... ♦.•..............................
............................. 3-15
................... 2-13 Syllabus Topic : Specialized Estimation Techniques ......................................................
................................... 3-15
.................. 2-16 Specialized Estimation Techniques ..............................................................
3.5 .................................. 3-15
................. 2-19 3.5. 1 Estimation for Agile Development .......................... - ......................................
........................................ 3-15
................ 2-22 3.5.2 Estimation for WcbApp Projects .................................................................. .................................... 3-16
............... 2-22 Syllabus Topic : Project Scheduling ................................................................ .............. 3-16

3.6 Project Scheduling ................................................... 3 .16

Syllabus Topic : Defining A Task Set for Software Project...... ............... ..................................

3.6.1 Defining A Task Set for Software Project .......- .......... - .............- ...............- ............................................

3.6.2 Reasons for creating a VVBS in A Project ................. - ...................""

Scheduling Technique ............................... 3.19

3 7 1 Critical Path Method .................... ‘ 1

3 72 Program Evaluation and Review Technique (PERT) ............................ - ........ .....

Syllabus Topic : Tracking the Schedule ---- -------------------------- ------------- --------------- --------- - -------3-23

36 Trsckmg the Schedu’o

Scanned by CamScanner
 ni VV'U - 6 - Comp)

Syflabu# Topic : TimoLlno Charts

3.8.1 TimeUno Charts

3-8.2 Enmed Vnluo Analysis ..

3 8.2(A) Features of EVA

3.8.2(B) Need for EVA..

Chapter Ends

Modulo 4

C h a p t e r 4 ; Software Design

Syllabus : Design Principles, Design Concepts, Effective Modular Design - Cohesion an

Component-level design. User Interface Design. _
4.1 Software Design
4.1.1 Qualities of Good Design
✓ Syllabus Topic : Design Principles
4.2 Design Principles.
Syllabus Topic : Design Concepts
4.3 Design oncepts ••••••••
Syllabus Topic : Effective Modular Design
Effective Modular Design
4.4.1 Advantages of Modularization
4.4.2 Functional Independence
✓ Syllabus Topic : Cohesion
4.5 Cohesion (May 15, May 16, Dec. 16, May 17, Dec. 17, May 18).
4.5.1 Different Types of Cohesion (Dec. 15)
4.5.2 Advantages of Cohesion
4.5.3 Disadvantages of Cohesion ....-
Syllabus Topic : Coupling
Coupling (May 15, May 16, Dec. 16, May 17, Dec. 17, May 18)

4.6.1 Types of Coupling (Dec. 15) . .............

4.6.2 Advantages of Coupling

4.6.3 Disadvantages of Coupling

4.6.4 Advantages of High Cohesion and Low Coupling (Dec. 17)
4.7 Differences between Coupling and Cohesion
✓ Syllabus Topic : Architectural Design
4.8 Architectural Design
4.8.1 Functions of Architectural Design

4.8.2 Architectural Design Document

4.8.3 Architectural Style (Dec. 15)

Syllabus Topic : Component - Level Design

4.9 Component - Level Design ....

Syllabus Topic : User Interface Design....

4.10 User Interface Design (Dec. 16, M a y 18)

4.10.1 Command Line Interface (CLI)

4.10.2 Graphical User Interface (GUI)

4.10.2(A) Gt II

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

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

Risk Management (May 15, Dec. 15, Dec. 16, May 18) ..................................................................................................................

Syllabus Topic : Risk Assessment .................................................................................................................................................. 5 4

Risk Assessment ........................................................................................................................................................................*......

5-5
Syllabus Topic : Risk Identification .....................................................................................................
5 5
5.2.1 Risk Identification

5.2.2 Risk Analysis...................................................................................................................................................................

5.3 Risk Containment ..............................................................................................................................................................................

✓ 5-7
Syllabus Topic : Risk Projection
..5-7
5.4 Risk Projection ....................
..5-9
Syllabus Topic : RMMM.....
..5-9
5.5 RMMM (May 15) ..................
5-10
5.5.1 The RMMM Plan
5-11
✓ Syllabus Topic : Software Configuration Management........
5-11
5.6 Software Configuration Management.....................................
5-11
5.6.1 Benefits of Software Configuration Management
.5-12
5.6.2 SCM Disciplines.................................................................................
.5-15
Syllabus Topic : SCM Repositories ...................................................................
.5-15
5.6.3 SCM Repositories..............................................................................
.5-17
Syllabus Topic : SCM Process .........................................................................
.5-17
5.6.4 SCM Process.....................................................................................
.5-18
5.6.4(A) Configuration Identification ...............................................................
.5-19
5.6.4(B) Change Control (Configuration Control) (Dec. 15, May 17, May 18)
5-21
5.6.4(C) Version Control (Dec. 15, May 17, May 18)......................................
5-21
5.6.4(D) Configuration Audit ......................... ..................................................
5-22
5.6.4(E) Status Reporting ..........................................•.........................-........
5-23

Scanned by CamScanner
5.8
5.8, 1 Components of SO A oystwn ........

582 Pre project Software (5uW Assure

V Syllabus Topic : Metrics ........................
...................................................................... .
5.8.3 Metrics (May 15)................................
5 8.4 In process Quality Metrics ................
....................................................................... .
585 Detect Density During Machine Testing ..............
..................................................... 5-3?
5.8 G Detect Arrival Pattern During Testing ............
...................................................................... 5-32
5 3.7 Phase-Based Detect Removal Pattern ...................
............................................. 5-32
5.8.3 Maintenance Quality Metrics.............................
...................................................................... 5-33
5 8.9 Fix Backlog and Backlog Management Index.......
...................................................................... 5-33
5.8.10 Fix Quality........................................................ ....................................................................... .
5.8.11 Defective Fix.......................................................... ....................................................................... . .
5.9 c h a Processes............ *.........

5.10 Benefits of . . ...........................................................

............................................................. 5-34
✓ Syttsbus Topic : Software Quality Assurance Task and Plan ..........
............................................................. 5-34
5.11 Software Quality Assurance Task and Plan ........................................ .................................................................... 5-34
5. 1 1 .1 Test Management Reviews and Audit................................
................................................... 5-35
5. 1 1.2 Implementation of the Quality Assurance.......................... ..................................................... 5-36
5.1 1 .3 Review the Process ................................................................
_ ........................ ....5-37
5.12 Quality Evaluation Standards ..............................................................
........................................... 5-37
5.12.1 Quality Evaluation Standards .........................................................
................................................. 5-37
5.13
......................................................... 5-33

........................................... 5-38
....................................... 5-39

..................................... 5-39

............................. 5-40
5.13.5 Responsibilities/roles in a Six Sigma .....................................................
............................. 5-41

............................................ 5-41
5.14
.................... 5-41
5.14.1 Measures of Reliability and AvaiiaDiiixy..................................................
.............................. 5-43
J Syllabus Topic : Formal Technical Review (FTR) ..................................................
................................ 5-43
5.15 Formal Technical Review ( r l H ) (Dec. 15, May io, way 1 ( , way i o ; .....................
................................ 5-43

......................... 5-45
...................... 5-45
5.16
....................................................................... 5-45
5.17 Comparison between FTR and Walkthrough (May 16) .............................................
....................................................................... 5-46
•
Module 6

Scanned by CamScanner
 Sofiwar® Tearing rmcff's.
Fyriabwa Topic : Strategic Approach to Software Testing ........
'3? Strategic Approach to Software Testing ........................... _

Syriabu* Topic : Verification and Validation

*3 6.3.1 Verification and Validation
«-«
r
23
,n
62.2 Difference between Verification and Validation (May 15, Dec. 17)
23
V*
6.2.3 Software Testing Strategy.
3<
Syllabus Topic : Unit Testing...- ........................... .6-12
6.3 Unit Testing (Dec. 15) ....................... ........................ —6-12
6.3. 1 Stubs and Drivers in Unit Testing .......... —.6-13
6.3.2 List of Errors Detected by Unit Testing. — 6-14

*' Syllabus Topic : Integration Testing ......................................................................................................................... —............. 5-1*

6.4 Integration Testing (Dec. 15, Dec. 16) .......................................................................................................................................... ............... ®-14

6.4. 1 T ypes of Integration T esting ............................................ ......................................................................................................... ®45

•*" Syllabus Topic : Validation Testing ............................................................................................................ - ................................................ 6 ' -’ 3

6.5 . ......................................................................... 6-18

............... . .
. ...................................................- ......... —6-18
........ 5*38
.......... 6-19
............. . .
. ....... 6-19
................. ..
z* o / a v K »A»****<*n Alnha nnH Rptsi Tp tinn .................. 6-21
0.5.3(A) L/IH6rODCO Deiweun Mipiid aiiu ouia icouny ...
...................._....... -..6-21

....................................... —.6-21
6.6
............................... 6-24
Syllabus Topic : Software Testing Fundamentals...........
.............................................. 6-24
................................ . . 6.7
.............................................................6-25
................................ . .
......................................... 6-26
/
........................... 543
........................... 543 6.8
.................... 6-27
.545 6.8.1
................................................ 6-27
6.8.2 Disadvantages of White Box Testing ..................................................
545 ............................ 6-28
✓ Syllabus Topic : Basis Path Testing ..............

. . . .......,546 6.9 Basis Path Testing (Dec. 15, Dec. 17) .......................................................................
............................ 6-28
6.9. 1 How Graph Notation ............................................ ................................. 6-29

6.9.2 Basic Terminology associated with The Flow Graph ............... ................................. 6-29

6.9.3 Cyctomatic Complexity (Dec. 17, May 18) ....................... ...................................6-30

fi-1 fO
6.9.4 Deriving Test Cases .................................. .................................... 6-31

ysfein 6.9.5 Graph Matrices ......................................... ..................................... 6-31

Syllabus Topic : Control Strocturo Testing .............— -t ...........— ................................ 6-31

IH0.

6.10 Control Structure Testing.

Scanned by CamScanner
 .ntents
Tab'o,
..6-31
8
..6-32
Igr *“•»»»-
Condition Testing ...6-33
6.10.1
pata Flow Testing .... ...6-34
6.10.2
6.10.3 6-34

Syllabus 'Topic : Black Box Testing 6-36

Black Boxt Testing (D®c. . ..................................................... 6-36

6.11
Types of Black Box Testing 6-37
Module 1
Advantages of Biack Box Testing
6.11-2
6.113
. 6.11-4
Syllabus Topic :
xxxr Software Maintenance
'E 6-37

.6-37

■•6-33
V Syllabus
Software Maintenance (May .....................
...6-3$ Nature o1 Software, Software En
6.12 cost of Maintenance
...6-33 Prescriptive Process Models
T me • Types of Software Maintenance . Models, Concurrent Models, Ac
Syllabus Topic . yp 1 ....6-4$
Types of Software Maintenance (May ,
6.13 6-43
61 7l stops to Create Maintenance Log (May
6-43
Sy1Iab us Topic : Software Re-engineering ...........
6-45
6.14 Software Re-engineering
6-45
Software
Syllabus Topic : Reverse Engineering
M
6-45
6.15 BWM. E nsinee""a(«’» «• "y “’ V
" [Q. 1.1.1 Whatissot
Chapter Ends □□Q Definition
Computer software,
instructions that tell
, built, that actually

- In computer
processed by
Computer s
as online d<
Computer
own.

- At the h
individu

A macY
change

- For ci

comp

An i
syst

- Th<

"ju

Scanned by CamScanner
 Introduction to Software
Engineering and Process Models
Module 1

Syllabus

*®*43

°S3

...... 0-4$
Software
....... °-45
(2 Marks)
..... °-45
What Is software? (Ret, sec. 1 . 1 )

□Qq Definition -on of data or computer •

C r or

f, that actually performs -------------- ------------------------ information

In computer science and software engineering computer so

processed by computer systems, programs and data. . non-executable data, such
Computer software includes computer programs, libr
as online documentation or digital media. realistically used on its
Computer

Scanned by CamScanner
 eejingJMl Sem. 6 - Comp) Software Engi

Tlie majority of software is written in high-level programming languages that aTe Inforr
efficient for programmers to use because they are closer than machine lang. local

languages- busii
are translated into machine language using a compiler or an interp A gr

ofTci
tdence

Ov<

No
as:
in
di
; ::
======== —
with the hardware. The arrows .
s
User

TT~7F
Application software
__

Operating system

Hardware

iC

Syllabub Topic : Nature ot Software

1 .2 Nature of Software

(5 Marks)
Q. 1.2.1 Explain changing nature ol software. (Rot sec. 1-2)

Now-a-days the software is not only remains a product, it also becomes an interface for delivering
a product.
As a product, software is able to deliver tne computing potential wiucn is ua iuaiiy vinwwui .i*
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

(operating systems), the transport of inionnation (networks) and the generation and man agonxent
of other programs (such as various software tads).

Scanned by CamScanner
 1-3 Introduction to Soltwam t-nginoorinq and Proco-ra Mcxfcfls
Software Engineering (MU - Som. G - Comp)

Information delivery is the most important aspect of software. To make any data more useful in a
local context, software can transform the data. It also help, in improving the competitiveness of a

to worldwide information networku (c.g., tho Internet), and

offer the way to gather information in o u w .

Over the last half-century, significant change, are occurred in the role of computer software.
Now-a-days the software become, more sophi.tieated no well a. complex because of variou.
aspects such spectacular improvement, in hardware performance, tremendous up-gradalmn.
in computing architectures, huge enhancements in memory and storogo capacity, and extensive

Sophistication as well as complexity lead, to amazing result, on sucee.. of systems, but they may
also lead to huge problems for those who want to develop complex systems.

m the economies of the industrialized world, the big software industry is consider, as a
dominant factor.
an entire team -----
In an earlier era, software was developed i rfiich is necessary to deliver a
which every person is responsible for one
complex application.

1.2.1 Defining Software

Software can be defined in different ways:

Definitions
ms) that ivhen

and performance.
2.

of the programs.

Now to understand the software exactly we have to examine some c

make it different from remaining human made things.
.. ns logical rather than a physical system e

1.2.1(A) Characteristics of Software __ (5 Marks)

entire. (Ret sec. 1MWL

Scanned by CamScanner
 SotV«

2. Software _

T lOTwiitStwa

4. Efficiency

■■ Characteristics of software
Fig.1.2.1
, st i s not manufactured in the classical sense
! Software is developed or engineer ,
. ., roun d in software development and hardware
_ Even though there are some snmlant.es “ .
manufacturing, both the activities are considered as fundam entaJly y different

there may be quality problems in hardware which may no pr

_ In both of the activities there is prominent dependency on people but there is vast difference in
the relationship between people and work accomplished.
- The main aim of both the activities is construction of a “product”, but the perspectives are not
same.
- Software costs are concentrated in engineering which indicates that it is difficult to manage
software projects similar to manufacturing projects.

2. Software doesn't “wear out”

L sec. 1.2.1(A)(2))
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.
However after some time period, there is again increase in the failure rate ns there are
cumulative effects of dust, vibration, mishandling, tremendous high or low temperature, and
number of other environmental maladies on components of hardware. In simple words, the
hardware begins to war ret.

Software does not have any risks of such environmental maladies which lead to wear out of
hardware.
In early life of software there may be high failure rates because of undiscovered defects. However,
these can be corrected.

Scanned by CamScanner
 Before the software gets consistent state by corrections, any new change get introduced which
again increases the failure rate.
- Gradually, the lowest failure rate level starts to increase which indicates that the software is
deteriorating due to change.

~ There is one important difference in hardware and software regarding wear aspect is that in case
of hardware, a failed component can be replaced by spare parts. This facility i s not available in
software as there are no such spare parts.
- All the software failures point out that there is an error in design or in the method by v/hich the
respective design was transformed into machine executable code.
- Hence the tasks of software maintenance which handles requests for change has significantly
more complexity as compared to hardware maintenance.

3. Custom built software

- Component reusability is an important aspect in software industry.

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

4, Efficiency
Software is Baid to be efficient if it uses the available resources in the most efficient manner and

R. Maintainability
. u eusiomcr — “
requirements.
through modifying the
Software engineering prorides the ability to maintain the software
software rather than changing whole product like hardware.

«. D.p«Kl.blllW

10
. a F so that it is W«’
•— ♦„ fulfill the customer’s requirements, so tn
. Dependability provides services t
. « -♦ rtf customers on the system.

Scanned by CamScanner
 _p s S

Sottwar
Software Engineering (Mu . Som . 6 . C omp)
1
-2.2 Software Application Domain
broad ca
Virtually on all computer platforms, software can Imj groupc

5
6. Web Application J;

_»[ 7. Artificial Intelligence Software]

Fig. 1-2.2 : Software Categories

System software
p rocrams Few of them such as

zz x zz
information structures.
but dete™iMte
- Some other system software such as components of OS. several drivers, networking related
software, and telecommunications processors are generally used to process heavily in e rm a
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. Engincering/scientific software

Tlwse types of software are characterized through the “number crunching” algorithms. There are
number of 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 modem applications within the engineering/scientific area
as they are shifting from traditional numerical algorithms.

Scanned by CamScanner
 — oftwaro__Enginooring ( M U - Sem. G - Comp) 1-7 Introduction to Software Engineering and Process Models

4. Embedded software

These are the software which are merged within electronic devices and arc used for the purpose of
implementing and controlling the features as well as functions for the end user as well as system
itself.
—> 5. Product-line software

— These software are developed to provide a particular functionality for use by several customers.
- The focus of product-line software may be on a restricted marketplace like inventory control
applications or can focus on mass consumer markets such as word processing, spreadsheets,
graphics based applications, multimedia, database management, and personal as well as business
financial products.

—> 6. Web applications

— These applications are also called as “WebApps”. This is a network-centric software category
which covers large number of applications.
- In shortest form, WebApps are same as of the group of linked hypertext files which provide
information through text and limited graphics.
- Now-a-days the modern WebApps are evolving into environments of sophisticated computing
which offer stand-alone features, computing functions, as well as content to the end user.
- It is also possible to integrate WebApps with corporate databases and business applications.
Artificial intelligence software
In these applications non-numerical algorithms are g<
complex problems which cannot lie handled by computet

There are various applications in this category such as

Syllabus Topic : Software Engineering

Software Engineering
(HU -Dec. 15)

(5 Harks)

Q. 1.3J Explain tho tom 'Software Engineering'. (Het. sec. 1.3)

0. 1.3-2 Detina 'Software Engineering'. (Ref- sec. 1.3)— - ----------------------

„ . two concepts. Software and Engineering.
Software

Software
related to specific functionality. Sei
loftware is set of executed programs
is called as a program.

Scanned by CamScanner
 n -
5
£-1® /MU - Seni. 6 - Comp) — V§ Introduction to Software Engineering and ProcoS *****'*
El Software Engineering rO n '- 3
T
than just a program code; i t also includes data structures which allow P ° the
— Software is Hl . a tion and documentation related to software product which def* 110
to manipulate m uger to use this software. Software engineers design
functionality und guidance to

the software product.

Engineering & and well defined principles to develop products.

catl
Engineering is an apph

Software Engineering
Definition 1 ntifica
..thod of applying '

design, OR

(5 Marks)

Tools

Methods

This approach is divided into 4 layers :

1. A qunlity focus

Any engineering approach must rest on the quality.

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

2» Process

Foundation for SE is the Process Layer.

- SE process is the GLUE that holds all the technology layers together and enables the t i n
development of computer software.

- It forms the base for management control <jf software project.

Scanned by CamScanner
 fl Tsoftwain Enghiooilng (MU - Sum. G - Comp) 1-9 Introduction to Soltwiun rn<|ln.intlnq nnd Prnctm

3. Method**

S E met hods provide the "Technical Quest ionti" for building Software.
Met hods contain a broad array of taaka that include conununicat ion requirement nnnlyHin, design
modeling, program construction testing and nupport.
4. Tools
- SE tools provide automated or semi-automated support for the "Proc.cns" and the "Methods".
- Tools are integrated so that information created by one tool can bo used by another.

1.3.2 Activities of Software Engineering

|q. 1 .3.4 Enlist Acttvltlos of Software Engineering. (Rot, sec. 1.3.2) ' (2 Marks

Software Engineering includes many activities as follows :

- Understanding the user requirements is the first most important activity in software engineering.
- According to the requirements, the process of designing the system and taking decisions is
implemented, which further leads to successful completion of development of product.
- Constructing the software product based upon designs and decisions made earlier is the next
activity in software engineering.
- To verify the performance and quality of software, testing the software product is essential after
i t is constructed by software engineers.
- The next step is to provide maintenance for software product which is deployed to the customer.

1.3.3 Need of Software Engineering

(2 Marks)
. sec. 1.3.3 )
Q. 1.3.5
1 environment on which software is working
on the software engineering principles used
nlso changes

Implementing and managing I rg quaUty Sottwarc

-. — —‘-r::x— —
modularize the tasks so that size of so ware

Without any standard method or management, .t

with high quality.

correct them as early as possible. Software ngmee to

” . ... , h o nrevious software to of developing new software to

develop and efforts . . . „ »av in which software system can he

. ... .is needed in future.

Scanned by CamScanner
 6 SO'

1.4 Software Process

methods such as
------ "S ncorlng Pr ° ce
®J
Software ----- .
. JTahorinoand

analyst

(ii) Design

(Hi) implementation

Software engineering process

lequential flow in order to develop software.

..... _le in detail in subsequent points .

ol

(i) Requirement gathering and analysis u8CTS business

_ In this phase stakeholders communicate with «>sto™e

requirements like who will use the system? How
bo the system input and output? etc.
ification Document (SRS) is prepared.
Depending on these requirements, Requirement Spec

(ii) Design
Pha
. TW . ™ .r •< “
document as an input.

Based on requirement specifications software design is prepared.

Output of this phase is design specification which specifies hardware and software requirem
of system.

Data Flow Diagram, flowcharts etc. are included by design specification document

Design specification acts as an input for implementation phase.

Scanned by CamScanner
 parts called modulcn.
These modules are assigned to development team members and actual coding is started.
This is longest phase of system development.

-> (iv) Testing

- Testing phase involves testing of actual code of system against requirements of user in order V>
ensure that system will satisfy all needs of users.
- Various testing strategies used are unit testing, system testing, integration testing -
- Output of testing phase is corrected and modified software code.
■> (v) Deployment

- In this phase the system is deployed at users’ site for their use.
_ In this phase customer uses the software and give feedback to development team for any changes
or modifications in system if any.

(vi) Maintenance .

- “
maintenance of system. application as per user’s
n,ia
. . » ph... ™ “
requirement.

1.4.1 Comparison
itional Engineering Process.
Q. 1.4.2 Compare Software engineering with Convert (5 Marta)

Ref. sec. 1 .4.1 . i r ~~«vrctTxtional engineering.

software and data processing. are genera lly used in

. J drawing similarity from tne me
This idea is expanded by drawing
engineering. . method is used in the field of scientific researc ,
f
II i s *•“* “
ri B<te E
u ,e 5 .epS . r ™ > « ” ' "'’
engineering-

Scanned by CamScanner
 1
r -, WJ r° engn;"' and Process Sot
£te°gn Q ineerin 9 (MU ■ Sen,. 6 - Comp)

are mostly repetitive :

2.
3. Search for alternatives,
Decision,
Specification,
6. Implementation peering as well.
It is advised that these steps are applicable to me of hardware and systems
It of integration
Software engineering is considered as a resu
engineering, including a set of 3 key elements - method
manager to control the process of software development o ff cr automated or semi-
The methods give the technical “how to’s ” for building software, applying methods, the
automated support for methods; and procedures describe

cL'pZd » mdiU.-J »»”» “™

... ..... - - — — - • — — - - -
n soiLware enguicciuis, ------------------------
| Software Engineering Abstract Design —> More Abstract Code
Concrete Products
(Manufacturing Engineering Abstract Design —>

The problem domains of software engineering can

c<
In contrast to another engineering discipline, it is therefore much larger in scope and thus

Traditional manufacturing engineering that normally emphasize mass production is loaded with
production features. Thus, it is highly production concentrated. Software engineering, in contrast,

Product standardization assists in cost reduction in manufacturing, whereas such a possibility is

remote in software engineering.

The jxissibility of process standardization, however, i s very high in the latter.

n and appHcahon-
Conventional engineering process makes the use of unlimited number of doniai itcd b u t

specific ideas which are proved. Software engineering, in contrast, makes

gickd concepts such as loops, conditions etc.

Scanned
Scanned by
by CamScanner
CamScanner
 Models

I
growing sequence of levels of a software development organization.
— The higher the level, the better the software development procedure so reaching every level is a

The 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.

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

Optimizing

Defined

Repcahbte

Initial

Fig. 1 5 . 1 : CMM Levels '

Scanned by CamScanner
 Mode'S
.ntmduc tosottware Engjoj
»=Sg!!war» Engineering (Mu ■ S em. s ■ Comp)
CT.
Level 2 : Repeatable and consistent project
. rnnd»« w
This level
------------- of
__ Software
s/viuytoiu Development association
--- -- h alld 010 1 yCO-tionS* 2
management processes to keep the track of cost, schcd -----------oiectswiUxshnaarnPP
<
The procedure is in region to repeat the latest success association-
£* level tvf®
Program management is a most important feature o

Level 3 : Defined are documented, standardize

o9

The software procedure for management and engirt ’ ov erall associatio software
and incorporated into a standard software procedurei forjhe * o f tbe standard softw
every project developed by association use an appro software product.

Level 4 : Managed software development through

Management can successfully control the efforts Q
precise measurements.
both software procedure and software
At this level, association set a
maintenance.
At this level, the performance of procedures is controlled throug
mechanisms, and is quantitatively predictable.

Level 5 : Optimizing

The important characteristic of this level is concentrating on

At thia level, modifications to the procedures are

at die same time maintaining statistical probabil
improvement aims.

1.5.1 Capability Maturity Model Integration

[a. 1.5.2 Wiito note on Capability Maturity Model Intron ( C M M I t ( H n l . noc. 1 . 5 3 )

The CMM model's application in software development has sometimes been problematic.
Applying multiple models that an? not integrated within and across an organization could be
costly in training, appraisals, and improvement activities.

The Capability Maturity Model Integration (CMM!) project was farmed to sort out the problem of
using multiple models for software development processes, thus the CMMl model has superseded
the CMM mode). though the CMM model continues to be a general theoretical process capability
modal used in the public domain,

CMMI framework consists of a collection of computer programs based on kiwwk -. > -tern
eagpneenof. wrfbraiv engineering, integrated product and prx®ss develop*— n t

Scanned
Scanned by
by CamScanner
CamScanner
 ■
T "

1 I ’ M M I f«r JVv*V‘p r n t f C M M I - 1»F,V»

2. C M M 1 F«w ( C M M l - RVC)

3 C M M l f<»r A n v « i * i l r .n K ’ M M I - A(.*(p
nda
’ nii ? „ TU- U,™ .p. 0™. m „|,| € „ rapm .„,. . h nI>iTw ,T
1
°«ch > pnxw and Uw, ™, x™. . p ,„ „f
soft l Ihrsr grmip<».
O

CMVIptv

tor n-.a-iaginj,
thr
° u Rh rrwtounng
rronlortnp
a«rj
<»g««rsr»r.r* 5 iw*i
dcvwloprpwit
P'ocn*> 5
SOfhv;
1 0 Cora Procais Area,
u»«d In all CMMUACQ 1
pravx>w yj-rtarr.*
,ti(: to onatto
ativ e intormed ard
decWva
anqui' ’On
t toactor- -p

Fig. 13.2 : CMM Framework Groups

cedure
Syllabus Topic : Generic Process Model

:e and
dure-

termed as Software Development Life Cycle.

detail for a generic process model with some
ks Now we are going to discuss all these phases in
tic. important aspects-

be
"XL— —

of
XZXXL— L-. - »
d

designer.
ineenng conuuixo
!-
-------- i 14 « fit into the overall picture.
,
(i) wh .„a.. s <ho S .««“” ”“ ,16 ‘ ”

Scanned by CamScanner
 r\- . Ftvg

or aaivHy <* ' * A nw

,. . ., n - *prj|-tim ,
nnd, ■
pniiTTmint; nnnlv*i* nf d a t a ? i$ cm-' **
• ,•n 7 That >* ’ - The
ttii) vlmt rnvironment will I b r tyrf tn be pltw***
can 1

(tv) Wfrpt uwt interface i* required and how •’ >t ured? Any

iv) Hnw system* communicate with other computer*? - Anj

CT,Wrr
<vi) Dors the system provide t h r required performance . wl.,t budget do« the ‘ tT agr
;
(rii)What time period has been planned and how serious t jjger in automating some Th
have and i s i t realistic? What are t h e cost/benefits tradco
manual procedure? q w ate the
When answers of these questions are received, the developer is
RISK involved in implementing the system.
(1) Requirements Gathering and Analysis
, a+in<T a specification and a design.
- Requirements Analysis is the first important step towards ere b
- Trying to design a solution to a problem without totally understanding the nature and
requirements of the user will always fails down the solution.
- It has been shown that more than ninety percent of software that are rejected by the cu
after delivery is because the software does not meet the customer needs, expectation
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
the viability of a software solution. al

- 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.

(2) Analysis Summary

uuaiysis is to generate a “requirements specification document’ or a

“target document” that illustrates great extent detail in an unambiguous a manner regarding exactly
w at t e product should do. This requirements document will then form the basis for the succeeding
design phase.
I
The requirements document may consists of :

- A Project plan containing details of delivery times and cost estimates.

Scanned by CamScanner
 Sc’hvarv l.mronriirui ( d * ‘;,%in ‘1 nt>
TV ____ 1 1Z lnfnvhM.l>on to fk)fP/afa F'nglrworlnq and Pry 0 4 Mo«hh

A model of the Rofhvnrc’s fiiudionnlily and behavior in Ibe form of Main flow / UML diagram
and, where suitable, any performance nnd <laln ronsiderations, any inpul/output detnil.’i etc.

- The results of any prototyping so that the emergence of the software and how it should behave
can be c.\|xwd Io the designer. This might contain a user’s manual.

Any formal Z or VDM specifications for the system requirements.

Any test data that may bo 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 arc sum-up by the analysis.

Software Requirements
Software
project Review analysis or Review
functions,
planning prototyping

Prototype
Project plan 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
 Program source
Prototype
in
preliminary specification

ng . 1.6.2 : Design .nd Implementation (Coding)

Software Testing
W and debugging car.
when the part of the software eomponents/modules has been written, testing
be started.
- Following techniques are involved in testing:
(i) Verification and Validation : This technique is usefid for checking that the software meeti
the agreed specification and verifying that the software is correct in its operation.

(ii) Black and white box testing techniques : It is helpful for testing the insides of the
modules for correct operation and testing the interfaces of the module.

(iii) Integration Testing : Testing that the modules all working together properly.

(iv) Acceptance Testing : Allowing the customer to test the product.

- Debugging can be defined as it is an art of recognizing the cause of failure in a part of software
and correcting it.

(5) Deployment

After completion of software development, we have to install it at client site. This process is
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
 S y t l n b u * T o p i c ; PtrocHptlvw p f o r » « « M o d H v

Proscriptive Process Models

I-, V<r» w )

The following framework activities are performed irrespective 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, tasks,
quality assurance and change the mechanism for every project.

Syllabus Topic : Waterfall Model

1.7.1 Waterfall Model

1 Q. 1.7.2 What is waterfall model ? State the practical situations in which it can be used.
software (Ref. sec. 1.7.1) (5 Marks)

2D. | Q. 1.7.3 Explain the waterfall model. (Ref. sec. 1.7.1) ____ (5 Marks)

insides of - 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 mode] any phase of development process begins only if previous phase is completed.

Requirement
Analysis

~t of softws
Design

| Implementation

Verificatlon/Testing

Maintenance

in>
r

i&
Scanned by CamScanner
 I n 1hi<! ph*i«*> fill *vi‘* **f *T**' * *** *
HaV >»r.l4»-r« Ami reHH*rft*T z * w*** (flU-Bi ** r » *1'*' rir
1
-At I Sf- f-.-J flf m- '
(
tV* a n
z »«•**** ** ’
%,
. r|Z'*<T' ™ **
Ba,c»«.| nn rrqnjrrrnrnl. ffprrtfrt*tw n Hr*mm*’**
aft bitfi't’irr
It <* bl or print o f pyfftrm rrprr®-* n , ’.nc *F‘ rm

It iff nffKponffibility of developer.

Verification / Testing
, - ; s verified against reqi
Here coding or job done by dcvelopc - ents of user.
a V —A — Cl M n»»11 r-nliefir <111 ' 1

* dcvdopment team Th.s <- software as per user requirements.

- Maintenance also includes addi g

=?■ Advantages of waterfall model

(i) It is very simple to understand and easy to u

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

Disadvantages of waterfall model

(i) It is not useful for large projects.

(ii) Not suitable for projects in which requirements are not clear initially.
(in) 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 when the requirements are very well known, dear and fixed.

- Product definition is stable.

Scanned by CamScanner
 Rww wnwiaiawi i i i *"B*K*ttHldtaKtMBB**l***»* *a*a*B

" IVchnoh'gy tp Mibb iv?i*i»<I

Bn i r inv no aihlnRiH'ni* n piifv mmi w.

Ample n-; wvm with required t u p it r e ntr iwRibihl* frw-ly
Tbv pivii't i in Rhort.
i ■ ■— ■■ — '■ ........................................... , , . . . .......................... — - ------------------------------------------------------------- ------------------------™_________——— —————— —

SvIIrHur Topic : V-Mo<J«|

MMM I ------ — ------------------ ---------- ----------------------------------------------------------------------------------------------------- - -------------- --------------------------------------

1.7.2 V-Modcl

□. 1.7.4 W; e note en V-MoOel with verification nn-J variation phases.

(Het sec. 17.2) (10 Merke)

- 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 arc bent upwards after the coding
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.

- The horizontal and vertical axes represent time or project completeness (left-to-right) and level of
abstraction respectively.

Fig. 1.7.2 : V-Model

- This model is basically divided into two phases; verification and validation.

Scanned by CamScanner
1.7.2(A) Verification Phases

3, Archlloctuce Design

Fig. 1.73 Verification phas«

Requirements Analysis
1
■— , , . M l n W l M " * ” ' * ”
requirements of the system are collected ny au j o+ has to perform. However it de*.
This phase is concerned with establishing what th ’
not determine how the software will be designed or rpn iiirements document ji

generated. system’s functional, interface

The user requirements document will typically escr * y e
performance, data, security, etc. requirements as expecte
w,, h
„ „ ...a » — «» -» understanding “ “ , ,
nssrs csrefiilly review due document on this document would serve aa the gui e
system designers in the system design phase.
The user acceptance tests are designed in this phase.
There are different methods for gathering requirements of both soft and hard methodology
including; interviews, questionnaires, document analysis, observation, throw-away prototype
use case and static and dynamic views with users.

2. System Design
Systems design is the phase where system engineers analyze and understand the business of th
proposed system by studying the user requirements document.
They figure out possibilities and techniques by which the user requirements can be implement
If any of the requirements are not feasible, the user is informed regarding the issue. A resolution
is found and the user requirement document is edited accordingly.
The software specification document which serves as a blueprint for the development phase i-‘
generated.

This document contains the general system organization, menu structures, data structures etc.’
may also hold business scenarios, sample windows, reports for the better understanding.

Scanned by CamScanner
L ± l Software Engineering (MU - Sore. 6 - Comp) 1 -23 Introduction to Software Engineering and Process Models

- Other technical documentation like entity diagrams, data dictionary will also be produced in tliis
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 AU 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
 —
The following a ro the typical plmses of validation in the V-Mode
!• Unit Testing
• a module design phase.
In the V-Model, Unit Test Plans (UTPs) are developed during This model is con
2. The developmen'
These UTPs are executed to eliminate bugs at code level or ur
regarding the sol
~ A unit is the smallest entity which can independently exist, e.g. a P 8* '
3. If there are chs
- Unit testing verifies that the smallest entity can function correctly when isolated from the rest 4 requirement doc
the codes/units.
2. Integration Testing
1.8 Incremental Pr<
Integration Test Plans are developed during the Architectural Design Phase
- These tests verify that units created and tested independently can coexist and communic
among themselves. Q. 1.8.1 Discuss inc

Test results are shared with customer's team. ________(Rsl. sec. '

The increment
3. System Testing
The series of
System Tests Plans are developed during System Design Phase.
functionality 1
Unlike Unit and Integration Test Plans, System Test Plans are composed by client’s businey - After the first
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 requirements have been met. The increme
Load and performance testing, stress testing, regression testing, etc., are subsets of system
Following tasks are
testing.
1. Communii
4. User acceptance Testing
2. Planning
- User Acceptance Test (UAT) Plans are developed during the Requirements Analysis phase. functions e
Test Plans are composed by business users. UAT is ■ 3. Modellinj
resembles the production environment, using realisric data. UAT vXTatXZZ
4. Construe
meets user s requirement and system is ready for use in real time. '
5. Deploym
Advantages of V-model
Characteristics
1. This model is simple and easy to use.
1. System i
2. Tlie testing activities such as planning, test designing are occurred •
PUOr codin 2. Partial e
wastage of time. Hence it has better chance of bum™ , 8- This avoids
i n « defect
a r h tracking
v COn,pared 3. First ta<
3. Proactive - «.
that. means the
t diagnosis of defects is d waterfaU model.
ear 8 a 4. The req
4. Avoids the downward flow of the defects. ge.
5. It is considered as good for small projects in which re *
quirements are easily understood.

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.
3. 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 - D e c . 16)

Q. 1 .8.1 Discuss incremental model for software development with merits and demerits. i
Dec. 16. 5 Marks

- 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 ,

1. System is broken down into many mini development projects.

2. Partial systems are built to produce the final system.
3. First tackled highest priority requirements.
4. The requirement of a portion is frozen once the incremented portion is developed.

Scanned by CamScanner
 . —Fnalnwlna and Process
1 26 lr
So«waraEn n inoerin 0 (Mu. s , m . 6 . c<OTp) ' " r ~ l "‘ :ll °"

□ Communication
Q Planning
Increment # n
fl Modolllng(analysis, designs)
*0*0 0
Software functionality & feature*

SI Construction(code, test) Delivery of 3 rd increment

■ Deployment(dellvery, feedback)

Increment #2

Delivery of 2 nd increment

Increment #1

1 .9 Evolt
Project calender time
- Noi
Fig. 1.8.1 : Incremental Model gro
dis
Advantages of Incremental Model
- Ac
1. After each iteration, regression testing should be conducted. During this testing, faulty elements inc
of the software can be quickly identified because few changes are made within any single - D
iteration. is
2. It is generally easier to test and debug than other methods of software development because q
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
I architecture which were not evident in earlier prototypes. 1 .9.1 J

1.8.1 Difference between Waterfall Model and Incremental Model

Q. 1.8.2 Differentiate between waterfall model and incremental model.

(Ref, sec. 1.8.1) .
-
---------- ------------------------------------------------------- (5 Marks)

Parameter Waterfall Model

Incremental Model
Simplicity Simple
Intermediate

Risk Involvement High

asily manageable

Scanned by CamScanner
 and Process Modelo
a) 1-27 lnlroductlontoSollwareln<|i.'->wln(j
Software FnninnnrinqfMU ■ Sem. 6 - Com
Incremental Model
Parameter Waterfall Model

Difficult Easy _________

Flexibility to change

User involvement Only at beginning Intermediate

Rigid Less Flexible

Flexibility

Least Promotes maintainability

Maintenance

Duration Long Very Long

Syllabus Topic : Evolutionary Process Models

1.9 Evolutionary Process Models ---------------------------------------------------- - ---------------------

- Normally the Evolutionary Development Model is based on the ' p ““ ple e tf being
growing increments of an operational software product, wfth the way of evoluhon bemg
discovered by operational experience .
- According to the business need and the changing nature of the market there are lot of
improvements required in the software product over a time.
- Due to this lot of improvement is required in the product hence evolutionary developments model
is iterative in nature.
— There are two types of models in Evolutionary process. They are .
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 - D e c . 17)

Q. 1 .9.1 With a neat 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
 i;
2 i n P)

2 Dofifln
1 . Idontlficntion

□.Construct
3. Evaluation and
Risk Analysis

Fig. 1.9.2 : Spiral Mode!

0) Identification

- This phase identifies all business requirements of system at the beginning. It involves cl
understanding of requirements by communication between stakeholders and customer.
In the subsequent iterations all subsystem requirements and unit requirements are identified.

(ii) Design

In first iteration, design phase develops conceptual design of system based on initially gather*}
requirements.
In further spirals or iterations, it develops logical design, physical design, architectural design
and final design of system.

(iii) Construct

Initially construct phase develops a code for conceptual design to get user Redback.
In next subsequent spirals, detailed working model of software is constructed with increment
number and are delivered to customer for feedback.
(iv) Evaluation and risk analysis

In this phase management risks like cost overrun arp J ,

feasibility of system is also done. ntified and monitored, technical

feedback. t potential risks in system and provides

Spiral model can

If customers are be
notused
sureforabout
projects
theirwhere budget \and risk evaiuation
reouim •
unportant factors.

Advantages of spiral model

(i) It is more flexible to changing requirements

(ii) Requirements are achieved more accurately

Scanned by CamScanner
EFT Software Engineering (MU - Som. G • Comp) 1 >29 Introduction to Software Engineering and Procnm Mod H

(iii) User can see the system from l rt iteration to end of development.

(iv) Risk management is easier.

<r Disadvantages of spiral model

(i) It is difficult to manage development process.

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

1.9.2 Prototyping Model

-> (MU -Doc. 16)

- 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.

< Requirement gathering

k and analysis

Build
Quick design
prototype

Refine User
prototype evaluation

Engineer
a product

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
 Software Engineering (MU . Som. 6 - Comp)
T GoftwiHn I
WO Quick Design
r
jtotypc design) of syst L ' Advnntngns of pr
iquircmcnts <1’
(i) f t nnal>h*N cn
developed.
development
Quick design is not detailed design of system; i t contains
(H) Refining of ji

(iii) Oornmuniral
(hi) Build prototype
(iv) Mor<< involv
i, the first prototype of «yRUrr
— Based on feedback received from user about quick design greater ext?
is created.
Dlsadvonbirjfjn <
- Prototype is working model of system under development.

(iv) Use Evaluation

Q. 1.3.3
Once prototype is built, proposed system is presented to end user or sysu — (i) Refining of
User determines strengths and weaknesses of prototype i.e. what needs to be ad hat is expensive ;
be removed. (ii) More invol

(iii) Refining o!

(v) Refining prototype (iv) Practically

extends I*
— Depending on comments and suggestions came from user, developers refine previous prototype to
form new prototype of system.
- New prototype is again evaluated just like previous prototype.
1.10 Concurrei
The process of evaluation and refining prototype continues until all user requirements are met by
prototype. •
0.1.10.1 Wr
(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.
ically online system in which web interfaces have a very high amount of interaction with end
users, are best suited for Prototype model.

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

16 Pr
which is incorporated in the prototype to result in a useable system ” ° V ‘ de & feedback

They are excellent for designing good human computer interface syste

Scanned by CamScanner
 1-3 1 Introduction to Software Englnooring and Process Models

Advantages of prototyping model

(i) It enables early evaluation of system by providing working model 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 user’s requirement at
greater extent.

Disadvantages of prototyping model

-> (MU - D e c . 17)

Dec. 17. 5 Marks

(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)

Inactive
Modeling activity

Under . Represents the state

development of a software engineering
activity or task

Awaiting
changes

Under review
Under
revision

Baselined

Done

Fig. 1.10.1 : Concurrent Models

Scanned by CamScanner
 o are Engineering (MU - Scm. 6 - Comp)
ricri nec ri ng•
_.n C urrcnt cnR
’ kn0 7 L C ., f iterative ue well as concurrent ekm% Q. 1.11.2 Wte
Tins model helps software team in the rcprcscntatio
various process models. defined for the s P*ra m °del is Ca Q. 1.11.3 Wh;

For example, consider the modeling activity which flfJ prototyping, analysis, and de8 i I Q . 1.11.4 V/ri

out by calling one or more software engineering actions s . software engineering act j ' Q . 1.11.5 V7ri

In Fig. 1.10.1 we can observe schematic representation modeling approach.

- Agile so'
in the scope of the modeling activity with the help ° f C° nCU1T h are note d at any particular ti
The state ofactivity modeling may be any out of the states wlnc action8j o r tasks
requiren
function;
In the same way, it is possible to represent remaining
- I t advo
communication, construction etc. in an analogous manner. 'multaneously but exi
improve
All the activities regarding software engineering are exe
different states. - The te:
Dcveloj
- For example, consider in the early phase of a project, first aiting cha nges state.
(not displayed in the diagram) has been completed and exists - The va

- The modeling activity whose state is inactive at the time of completion of initial communicate range <
now changes its state to under development. - There
=• However, if the customer enforces that changes in requirements should be necess y done, the agility
modeling activity shifts from the under development state into the awaiting changes state.
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. Based

— For example, in the previous phase of design (an important action regarding software engineering sever

which occurs in the process of modeling activity), an inconsistency in the requirements model is o 1
uncovered.
o
— Because of it the event analysis model correction, is generated that will activate the requirements
o
analysis action from the done state into the awaiting changes state.
Concurrent modeling is proved to be compatible for all the types of software development and
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, 2 o
process network is defined by the concurrent modeling.
- All the activities, actions, or tasks on the network execute concurrently with other activities, c

actions, or tasks.

- In the process network, events which are generated at one point activate transitions between th*
states.

Syllabus Topic : Agile Process o

1.11 Agile Process

Scanned by CamScanner
 - Som. G - comp)

hat aro Agilo Processes ? (Re f. 80c soc. 1.11)

1 1 1}

O- >.11.4 Wrt(e short nolo on Agi ,„ Mo|1Kxtekw (Ro( ,

Agile software development describeTTrT ----------------------

0ppronch to
requirements and solutions Pvnl„„ n.._ . software development under which
functional teams and their custonu eflbrt of self-organizing and cross-

dCTC
'° Pmentto change.
ges rapid and flexible response - a”0 stomal

P
“’ " * - — - Agile SoItware

“0 a broad

practices vaiues impr

agw ““ ° ves fte

Based on their combined experience of developing software and helping others do that th
seventeen signatories to the manifesto proclaimed that they value:
O Individuals and Interactions over processes and tools.

o Working Software over comprehensive documentation.'

° Customer Collaboration over contract negotiation,

o Responding to Change over following a plan.

- As per the view of Scott Ambler (Canadian software engineer, consultant and author) :

o Tools and processes are important, but it is more important to have competent people
working together effectively.

o Good documentation is useful in helping people to understand how the software is built and
how to use it, but the main point of development is to create software, not documentation.

o A contract is important but is no substitute for working closely with customers to discover
what they need.

o A project plan is important, but it must not be too rigid to accommodate changes in
technology or the environment, stakeholders' priorities, and people's understanding of the
problem and its solution.

Scanned by CamScanner
 linooring and Process

1-34

1 .1 1 .3 Difference b?

1.11.1 Agility Principles 0. 1.11.9 DHfqrer

(MU - May 15, Dec.
(Pel. SI

Q. 1.11.6 Explain principles of Agile Mclhodology. (Ref- s e C - Parameter P

Q. 1.11.7 Describe and discuss characteristics of Agile Process Mo Basic aim Deve
(Ref. sec. 1.11.1) ' ---------------------- to th?
on
Functionality It
Customer satisfaction by early and continw requ

2.
Popularity It is
3.
4. Close, daily cooperation between business people and develope Examples Wat

5. Projects are built around motivated individuals, who should be t

6. Face-to-face conversation is the best form of communication (co 1
7. Working software is the primary measure of progress.
8. Sustainable development, able to maintain a constant pace.
9. Continuous attention to technical excellence and good design.
1.12 Extreme I
10. Simplicity is essential.
11. Best architectures, requirements, and designs emerge from self-organizing teams.
Q. 1.12.1 E
12. Regularly, the team reflects on how to become more effective, and adjusts accordingly.
- Extrem
1.11.2 Advantages of Agile Process softwai
(MU -May10

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,
ves
Inipro Quality.

Scanned by CamScanner
 production to Softw
■fland Procoss
ndA
" 0ll0Pr O co33 Modal
procoss
mX’iT*’ "***• """ - -------
Parameter <5 Murka)

Basic aim Process Model

ructure
>ugh early and
continuous delivery.
Functionality 11
can accommodate changing
requirements fines distinct sot of activities, actions, tasks
milestones, and work products that arc required
to engineer high-quality software.
Popularity It is more popular.
Comparatively less popular.
Examples Water fall mo del, Incremental models
Scrum, extreme Programming (XP), Feature
Dnven Development (FDD), Dynamic Systems
Development Method (DSDM), Adaptive Software
Development (ASD).

j .12 Extreme Programming (XP)

□ ~ ---------------------------------------------------------— JMU - Dec. 15, May 17)

- Explain Extreme Programming ( XP) with suitab|e dia g ranl . (Re( < Ja Dec. 15, May 17, 5 Marks

is a software deveiopment o,ogy

■ sXz “ requirements.
quality and responsiveness to changing customer
Planning/Feedback Loops

Release Plan..
Months'
Iteration Plan

Acceptance Test
Days

Stand Up Meeting
One Day

Pair Negotiation
Hours/

Unit (Test
Minute /
Pair Programming
SecondjX’*
Code

Fig. 1.12.1 ; Extreme Programming

Scanned by CamScanner
 ara £n g ln "d °5
Software Engineering (MU - Sem. 6 - Comp) -36 Introduce Releases m — -------
Softv
As a type of agile software development, it checkpoints at which 2.
cycles, which is intended to improve productivity
customer requirements can bo adopted. . jn pairs or doing extensive Co
prog
Other elements of extreme programming include : - flture s until they arc a ally needG(j
review, unit testing of all code, avoiding programming expecting changes storn
a flat management structure, code simplicity and c a £
(>rS 0 0 d, and frequent communica
requirements as time passes and the problem is bette
with the customer and among programmers. elements of traditional soflWa
The methodology takes its name from the idea that the b

As an example, code reviews aro considered a beneficial I

1.12.1 XP Values
i in 1999 ■ communication, simply
- Extreme programming initially recognized four values «<!;♦:An v t ’
feedback, and eouragl A new value, respect, was added in the second edtfon of Eztrtc .

3.
XP values

1. Communication

2. Simplicity

3. Feedback

4. Courage

5. Respect

Fig. 1.12.2 : XP values

1. Communication

- Building software systems requires communicating system requirements to the developers of the
system. In formal software development methodologies, this task is accomplished through
documentation.
- Extreme programming techniques can be viewed « j „
disseminating institutional knowledge among members of a devdopL teZ
- The goal is to give all developers a shared view of the svstem k- .
wh,ch
users of the system. matches the view held by fl»
1U
uub unu, extreme programming favors simple designs
011 metaphors
users and programmers, frequent verbal communication a d ’ collaboration®1

Scanned by CamScanner
 £T Software Enqineoilng (MU -jem. G ♦ Comp)~ ___1: 3 / _ jnlrndm Hon to S o l i w i m Enqirmerlng and Proc<5 Modo!-,

2. Simplicity

- Extreme programming encourages starting with the mmplcnt solution, Extra functionality ca.
then be added later.
- The difference between thia 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 the 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.
- As per Kent Beck (American software engineer and the creator of extreme programming),
“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
 „ -oFnalnoedng and Proews Mon,,
eaajWwaro Engineering (Mu . Scim 0 . Comp)

------------------------------- of effort to hapl

This is an effort to avoid getting delayed in design m re factoring their code
anything else. Courage enables developers to feel com
ncressa
'y- , t „0 th „t future changes can t<
This means reviewing the existing system and mo
Stakeholder

code away: courage to remove source

create that source code.
that is obsolete, no matter how much effort was us
bo stuck on a complex problem f w
Also, courage means persistence: a programmer

6
5. Respect 7

— The respect value includes respect for others as well as self resp
- Programmers should never commit changes that break compilation, that mak *g
12 _ _ _
fail, or that otherwise delay the work of their peers. 13 ___
14 ___
15}
- Members respect their own work by always striving for high quality and seeking for the te,
Product
design for the solution at hand through refactoring.
- Adopting the four earlier values leads to respect gained from others in th
- Nobody on the team should feel unappreciated or ignored. This ensures a high level of motivate. - The w<
and encourages loyalty toward the team and toward the goal of the project. tailore

- This value is dependent upon the other values, and is oriented toward teamwork.

Syllabus Topic : Scrum

1.13 Scrum

€> (MU -Dec. Il)

|Q. 1.13.1 Write short note on SCRUM. (Ref, sec. 1.13) _______ D e c . 1 7 , 1 0 Marks]

- Scrum is an agile framework for managing knowledge work, with an emphasis on software
development. It is designed for teams of three to nine members, who break their work into action
that can be completed within time boxed iterations, called "sprints", no longer than one nio
and most commonly two weeks, then track progress and re-plan in 15-minute stand-up meeW Scr
called daily scrums. for pro

Scrum principles are mostly based on the agile manifesto and help to guide activities regal® process
5
development inside a process which includes framework activities such as requirements, an* - Bi
design, evolution, and delivery. cu
as
in all the framework activities, work tasks happen within a process pattern called a sprint.
- S
w

Scanned by CamScanner
Software Engineering (MU ■ Sem. 6 • Comp) 1 *39 Introduction to Software Engineering and Process Models

Stakeholder liaison
Product I Dally
backlog ’ 'Sprint 'scrum
refinement' (Max 1
month)
Product owner
i
Scrum
2 master
3
4
6
6 xemental
7
8
9
Potentially
releasable
10
Sprint Sprint
increment
11 backlog
planning
12
13
14 Topicl : forecast PBI’s
15 Topic2 : Plan work (e.g. tasks) Sprint
Sprint retrospective
Product backlog Review

Fig. 1.13.1 : Scrum Framework

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

24 h

30 days

Sprint backlog Sprint Working increment

Product backlog
of trie software
Fig. 1.13.2 : The scrum process

Scrum mostly focus on the use of a bunch of software process patterns which are proved effective
for projects with restrictive timelines, changing requirements, and business criticality. All such
process patterns defines several sets of development actions :
Backlog - A prioritized list regarding project needs or features which offer business value for the
customer. It is possible to add items to the backlog at any time. The respective product manager
assesses the backlog and changes the priorities as per necessity.
Sprints - Includes work units which are necessary to gain a requirement defined in the backlog
which should be incorporated in predefined time-box (usually thirty days).

Scanned by CamScanner
 B print.Therefore, k
to
idg nment. _ When rl
massive
Software Engineering (MU - Sem. 6
not in v ° 1V '“pt C
" d on dad/ basis by ttl.
_ To com:
„_ork — .ehort- ’ condd C* t be answered by
Modifications (such as backlog wo rk in » s cC 1106 d a nd pass a <
members are allowed by the apn»‘ u
min”* h 3 re _ When :
(nsually
Scrum meetings - are snort. qUC8 > the v/2
c
Scrum ♦team, Three
inrec most import n on.
n(?
team members are : n icct’ ‘
_ The w
1. what did you do since tbc In Cva
feting and ’ UatC3 factor
the
2. What obstacles are you cncou 3 _ The si
ster, ba
3. What do you plan to acconip B9 a Scrum ward
A team leader, who is known
unco’
responses from each person. team i 9
pledge socialization” audit. Kanbc
Ute important use of Scrum mee
possible. iq that they
Agile
. (customer) so that the ne„l; matci
encourage a self-organizing team
■ ted by the customer. This
Demos - implement the software
be demonstrated
’ ”7 ted as well as evriua planned functionality,
fimetw but instey throi
ota
, ___ mflV not able to “ “ ox. ________ Whil
!t ablished tune bu _
softv
Kanban Mode] In p
und
Uni
U4 Kanban Model
(10 Marks) pro'

q 1.14.1 Explain the Kanban

Model in detail (Ref, sec. 1.14) nee

Kar
ofcapadty and full transparency of work.
Th
Work items are represented visually on a kanban board, alloc
of every piece of work at any time. op
Kanban is enormously prominent among today's agile software teams, but the kan a* _ w
methodology ofwork dates back more than 50 years. ‘ a <

In the late 1940s Toyota began optimizing its engineering processes based on the same model m
that supermarkets were using to stock their shelves. - R
Supermarkets stock just enough products to meet consumer demand, a practice that opting v
the flow between the supermarket and the consumer. ii
Because inventory levels match consumption patterns, the supermarket gains signify
efficiency in inventory management by decreasing the amount of excess stock it must hold at a»!
given time. Meanwhtle, the supermarket can still ensure that the given product a consumer nee*

Scanned by CamScanner
133 Software Engineering (MU - Som. G • Comp) 1-41 lntrod(iclion_to_Softwaro 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 wan passed to
the warehouse describing what material was needed, the exact amount of this material, and so
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
 Software
Som. G - Como) to S?f«waro Enginooring and Process !S&

D
e„ p;;"" “ n '“‘hod-logy mUe. upon fu.l tran-paroncy -f work -'<■ XX“ th 7"
f rc U e l nb l 1 U, ing W
w” rk ° ’ “ “" ™" *« ° ’ ’ Kan
sizes

Advanta<
P»«cenlfy updated

1 To do 1 Do no

© TIS 28
T Research option®
© TIS-25 S TIS-27 © TIS-23 p
T Engage JolChuttkj ‘ 4
to travel to Pluto T Engage Jupiter T Engage Saturn SpacoWayj tor
Express for travel Resort a s PTP
travel

® TIS-25 ® TIS-27
T Add Doimos Tours ■t Engage Speedy
as a travel partner Spacecraft

® TIS-26 J
+ Reach out to the Mr-
Lines for group tours ** I- Pla
Red Titan Hotel

- Ak;

Sign Contract for

wof
SunSpot Tours
- The
beci
Fig. 1.14.1 : Kanban Board
As '
1.14.3 Kanban Cards
dev

the

represented as a separate card on the board. every work item is 2. Sh

as a card on the kanban board is to allow team members - Cyc

of 1
manner.
ion shi
!
m, giving the entire team
- By
done, how long that piece of work is estimated to take, and so on
- Ov
Cards on virtual kanban boards will often also feature screens
that are valuable to the assignee. pei
rei
Allowing team members to see the state of every work item 8
all of the associated details, ensures increased focus toll g™6 " P
°‘ nt “ time
’ as well as - Sh
tra
blockers and dependencies. ’ ceability, and fast identification of cy
th
1.14.4 Advantages of Kanban
Di
Kanban is one of the most popular software dnvoi • - In

Scanned by CamScanner
 - Sem. 6 - Comp) 1-43 Introduction to Software Engineering and Process Models

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

or 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 kanban team is only focused on the work that's actively in progress. Once the team completes a
work item, they pluck the next work item off the top of the backlog.

- The product owner is free to reprioritize work in the backlog without disrupting the team,
because any changes outside the current work items don t unpact the team.

- As long as the product owner keeps the most important work items on top of the backlog, the
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

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

- By optimizing cycle time, the team can confidently forecast the delivery of future work.

- Overlapping skill sets lead to smaller cycle times. When only one person holds a skill set, that
person becomes a bottleneck in the workflow. So teams employ basic best practices like code
review and mentoring help to spread knowledge.

- Shared skills mean that team members can take on heterogeneous work, which further optimizes
cycle time. It also means that if there is a backup of work, the entire team can swarm on it to get
the process flowing smoothly again. For instance, testing isnt only done by QA engineers.
Developers pitch in, too.

In a Kanban framework, it's the entire team's responsibility to ensure work is moving smoothly
through the process.

Scanned by CamScanner
 Engineering and Process
Sofhv
. gpm, G . Comp) . 44 Introd JC
3. Fewer bottlenecks K-l Soft y.-nro Engincnrinq (1

Multitasking kills efficiency. The more work items ln night nt any K ivnn time, the more A cumulative
switching, which hinde rs their path to completion. blockages by

Thats why a key tenant of Kanban is to limit the nm „„nl Of work >*• prognren (WIPh Work . ilu states s u c h ai

progress limits highlight bottlenecks and backups in the tenm'n process due to lack of f W ] , t h e s e states c

people, or skill sets. n T P merged upstr

- For example, a typical software team might have four workflow states: o o, n regress, , 1750 r ------
Cl Do1
Renew, and Done. □ ini
wre
g a ,c
- They could choose to set a WIP limit of 2 for the code review state. That m »
limit, but there’s good reason for it: developers often prefer to write new code, ra er an S p 1250 ------

esnssi p JoqwnN
time reviewing someone else's work.
1000

— A low limit encourages the team to pay special attention to issues in th " » nd to
750
rexdew others work before raising their own code reviews. This ultimately reduces the overall
cycle time. 500 --

4. Visual metrics
250
— One of the core values is a strong focus on continually improving team efficiency and effectiveness
with every iteration of work. qL c
Jan 1
— Charts provide a visual mechanism for teams to ensure they're continuing to improve. When the
team can see data, it's easier to spot bottlenecks in the process (and remove them).
— Two common reports Kanban teams use are control charts and cumulative flow diagrams.
5. Continue
A control chart shows the cycle time for each issue as well as a rolling average for the team.
06 Aug to 14Sept - We know
o Issue increment
1w13h 17m average 3d median <1m min time 1 3 w 6 d 23h max time 240 issue
• Cluster of issue continuou
g

Average
** Rolling average CD is the
£

□ Standard deviation
- Kanban ;
o

time (ant
Elapsed time (days)

- The fasti
O

the mar
custome
____

1.14.5 Compar

Q. 1.14,2 [

Kanbai
should not
TO
co
CD

V)
0)
Q.

Issue transition data

Fig. 1.14.3 : Control Chart

Scanned by CamScanner
 Sonware Entering (MU ■ Sem. 8 ■ C o mpl , „ ,

• • ■ - ...... ............. ............. ...........

blockages by seeing (be number of *“»
08 Issue
states such as “In Progress” or "In Rn • « ° " " in intermediate
these states can increase the likelihood f “ rc " Ot Sh PPCd
‘ " 1f l a blockage in
m M VC intogn,tl<,n
merged upstream ° ' ™" nirt " u '« work does get
1750
jODone
iO In Progress
1500 ■ To Do —

1250
Number of Issuso

1000

750

500

250

Jan 1 Jan 1 6 Feb 1 Feb 1 5 Marl Mar 16 Aprl Apr16 May1 May 16 Jun 1 Jun 1 6 Jul 1

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

[q 14,2 Differentiate between Scrum and Kanban Model. (Ref, sec. 1.14.5) _— I
Kanban and scrum share some of the common concepts but have very different approaches. They
should not be confused with one another.

Scanned by CamScanner
 Software Engineering (MU - Sem, 6 - Comp)

Parameter SCRUM _______

Continuous flow |
Tempo Regular fixed length sprints
(i.e 2 weeks)
Continuous delivery or at the tew,
Release At the end of each sprint if approved by the discretion. _________ ______________ Module 2
methodology product owner. ______

Roles
No existing roles. Some teams enlist the
Product owner, scrum master, development
help of an agile coach. ______~ ______
team

Key metrics Velocity Cycle time. ____; ____________________j

Requirement Eiic’rta'
Change Teams should strive to not make changes to Change can happen at any time.
Requirement Mode'
philosophy the sprint forecast during the sprint. Doing
so compromises learning’s around
estimation.

Scanned by CamScanner
 Requirements Analysis
and Modelling
Module 2

- Syllabus ------------------------------------------------------------------------------

Requirement Elicitation, Software requirement specification (SRS), Developing Use Cases (UML).

Requirement Model : Scenario-based model, Class-based model, Behavioural model.

2.1 Requirement Engineering

. + (MU - D e c . 16)

Dec. 16. 2 Marks

Q, 2.1 .1 What do you mean by requirement? (Ref, sec. 2.1)

Requirement

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

Characteristics of requirements

There are various characteristic of requirements. They are as follows :

Characteristics of requirement |

1 . 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)

Scanned by CamScanner
 (Mu s
1. 6 -Comp) 2-2 ' Requirements Analyst..

- A n >bU,ren,6ntS 8houW be un
“™higuous •
s n wor
contain amb’ ’ ° d or statement has more than one meaning, jf
difficult 10 fulfi11
correctl the rcc llirements

■*
" therefor th l y- e asB5Bs
®Eng
1 2, p f u
l hemcnts should bo unambiguous means non confusing.
mcnts should be testable (verifiable)
It’s a
Stages

lho
requirements sb™ 11 i . " At
the
Ia
whether they ar • oo testable means tester should be able to easily test the r and v -
and u nambigu glm erQCnted succe8Bfull y or not. For easy test, the requirement sh S 1 1 A

__ ' should be clear (concise, simple, precise)

8
- If there * should be clear. They should not contain any unnecessary informal

the beC
” “ ° meS 10 aChieVC the
> -
4
’ he understandable
- The
b
understood by e understandable means when anyone read it then it should l
make U p
- It should be ™per conventions are use
t Should be grammatically correct. '
“■ „ , mlMe ihw

be
. 2" 77”“ requirement
Spemfied said to be feasible if u “>•
„ «■»
k • «- w e .<
6 lmplemente
estimated budget and time. d using existing technology,.
-> 6. Requirements should be Consistent

a
‘ X77T" “ . «.«. ’ -
111
Requirement Engineering
- it
- The procedure which collects the software requirements ft- - T
them is called as requirement engineering customer, analyze and
- The aim of requirement engineering is to

Specification’ document. Weate and maintain ‘System Req

- Requirements engineering is the process of underst ’

0 8 defining which seI i
required and identifying the constraints on these serrtce '* " ’

_ Requirement engineering processes ensures your s » ’’

316
ending up with high qualify software. ° wfll meet the user expect

Scanned by CamScanner
 2-3 nnquiromcnta Anafysla and Mode King

It’s a critical stage of the software process as errors nt 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 specifics 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, see. 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 :

Activities 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

1. Requirements Inception

Inception is a task where the requirement engineering asks a set of questions to estabfish 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.

•4 2. Requirements Elicitation

In requirements engineering, 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
 r. M n mmMAn nndM
quirvmonts Annly.t. nnd Negotiation LlCl Sofiwaro Englnoorir

Requirements nro identified (including new ones i f the development is iterative) and conf]
In require,
with stakeholders are solved. Both written n n d graphical tools (the latter commonly used i n
design phase but some find them helpful n t this stage. too) are successfully used as mds. discovering
practice in ,
Examples of written analysis tools : use cases nnd user stories.
~ The term el
Examples of graphical tools : UML nnd LML.
joist lie coll<
4. System modelling
Requircme
Some engineering fields (or specific situations) require the product to be completely designed from the u
modeled before its construction or fabrication starts and, therefore, the design phase Safety and
performed in advance.
Requireme
For instance, blueprints for a building must be elaborated before any contract can be app
workshops
and signed.
- Before rec
Many fields might derive models of the system with the Lifecycle Modeling Language, where,#
. elicitation
others might use UML.
usually fo
'Note : In many fields, such as software engineering, most modeling activities are classified as design activities
There arc differen
anc
* not as
requirement engineering activities.
(1) Interviews
"* 5. Requirements specification
- Interview
Requirements are documented in a formal artifact called Requirements Specification (RS). of intervit
Nevertheless, it will become official only after validation. A RS can contain both written and o Strut
graphical (models) information if necessary. in ad

Example : Software Requirements Specification (SRS). o Non-

decii
6. Requirements validation
o Oral
It is the process of checking whether the documented requirements and models are consists
o Writ
and meet the needs of the stakeholder. Only if the final draft passes the validation process,*
o Fact

o Gro
7. Requirements management
reqi

Managing all the activities related io the requirements since inception, supervising as the nystc. (2) Surveys
■s developed and, even unttl after ft is put into use (e. g„ changes, extensions, etc.)
- Organic
require
- The ad
2.2 Requirement Elicitation _________ becausi
’ ' _ _ _ _______ • - Survey

( M U - Dec. fl - Frequc
Survey
. Dec. 1 7 , 5 Marks]

Scanned by CamScanner
 software Engineering (MU • Scm. 6 - Comp) 2-5 noqulromonti Analysis and Moding

In requirements engineering, requirements elicitation in the practice of researching and

discovering the requirements of a nystem from uscro, customers, and other stakeholders. The
practice is also sometimes referred to ns "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 bo 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 Tor
Safety and Reliability).

- Requirements elicitation practices include interviews, questionnaires, user 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.
o 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
 2-0
J_Softwaro Eng'neennp (MU •
of objectives that i3
(3) Questionnaires
w hich c»o W i n ''
Questionnaires arc a document * • o f those questions which
questions and their options- <r; v C

-rk.-p. «a crivrn to aH Stokch ln

ir»
ation i g n °
and compiled. no qu cfltl °
economically j3
rc
issue may be remaining unatten • feting '
• tnflv
The advantage of this
because it collects requirements f discovery-
n-Mive method of d ala

• eerS
or? may identify the fun
(4) Task analysis an d e ngm

r nware develop 6
- In this technique, team of so nee ded to develop-
nations then it is analyzed by tEh,
specifications for which the new system > op ,

_ Ifthe
to findcustomer has somefor
out requirements software to do
proposed the P-
syste

(5) Domain Analysis

_ Each software put into some domain category- genera]

_ The experienced persons in that domain can be a gr

requirements.

documented for further requirement analysis.

m w
“ "I „ . „ do — . - ‘

. It supports prortdius d.Ull. ,p«

1 ! th€ tl d P
Kthodlrat doos Mi k»ow«so"rt«™“> '.“ “ “ “ '’'
based on requirements provided at initial stage.
_ We prototype is displayed to the client and the feedback is collected from client.
The client feedback is used as an input for requirement gathering.

Observation
(8)
Team of experienced persons visits the organization or workplace of client.
They observe
They observe the flow of control at client’s end and how execution problems are dealt*
*tself draws some conclusions which aid to form requirements expected from the software

Scanned by CamScanner
 dFF Software Engineering (MU - Som. 6 - Comp) 2-7 Roquiromonts Analysis and Modelling

2.3 Requirement Analysis

Q. 2.3.1 Write noto on Requirements analysis. (Ref. see. 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 requirements.
- 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
 ------------——————— are divided into three
The requirements, which nro in genem nfl _ ’-------, d(imn i n requiremen
functional requirement non functional requirements. mPntg
ffr r
'~

Non Functional
4
Reti'jin’mnnls 2 only
r ••ndtanal Require"'**'”’
- • “ hrc’jr

2.4.1 Functional Requirements

(Mij
! 2 4 1
Q. 2-4-2 Exp 3.n Functional Requirements. (Ref- sec- - - l

- - The Functional requirements specification create document regarding the operatic ’n> * dataUae wa Vm, . »

***» Mtaae to either

Th* spread can data w.th
In software engineering, a functional requirement is used to define a function regard
or its component, in which a function is described as a specification of behavior between, ” Security Requfrwmnu

and inputs.
Tn the functional requirements there may be elements such as calculations, technical det£ Memben cf the Mar r,
manipulation and processing, and other specific functionality which define what a Members cf the AdmiaistratcT? rr-.-c
supposed to implement. 2.4.2
As defined in requirements engineering, functional requirements is used to mention $
results of a system. 0. 2.4 3

This should be contrasted with non-functional requirements that mention overall charts These are basically the quality eon
contract.
like as cost and reliability.
The priority or extent to which th.
Functional requirements drive the application architecture of a system, while non-L.
They are also called nan-behavioral
requirements drive the technical architecture of a system.
o Portability
Functional Requirements should include : o Security
o Descriptions of data to be entered into the system. o Maintainability

o Descriptions of operations performed by each screen. o Reliability

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

o Performance
o Descriptions of system reports or other outputs.
o Reusability
□ Persons who can enter the data into the system.
o Flexibility
j Way the system meets applicable regulatory requirements. NFRs are classified into followir

Examples of Functional Requirements o Interface constraints

of o Performance constraints :i
Functional requirements must contain functions performed by specific screens, outlioe ®
performed by the system, and other business or compliance requirements the system f®

Scanned by CamScanner
I T Software Engineering (MU • Som. 6 - Comp) 2-9 Requirements Analysis and Modelling

Interface requirements

- Field 1 accepts numeric data entry.

- Field 2 only accepts dates before the current date.
Screen 1 can print on-screen data to the printer.

o- 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.

Regulatory/Compllance 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 Functional Requirements (NFR)

(MU -Dec. 16)

Q. 2.4.3 Explain Non-Functional Requirements with types. (Ref. sec. 2.4.2) Dec. 16. 4 Marks

- 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
o 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
 --------Software Engineering (MU ■ Sem. 6 • Comn)

° Operating constraints Softwarn Engineering (MU - r jQ r n , G .

Life
° cycle constraints : maintainability, portability, e • Thn outcome of the req’
Economic
° constraints k n o w ic dgc of the function Requirements Specific
i1
The process of specifying non-functional requirements n k c gystem will operate. '' ~ SRS 13 alw called as reqi
the system, and also the knowledge of the context within w i
~ SRS ia base for software
project are gathered and
- It 13 generally signed at
Non-functional
Requirements ~ Follwing are 6 require!
1. SRS document shoi
External 2. SRS document sho
Product Organisational
Requirements
Requirements Requirements 3. It should be easily

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 5. SRS document rec
behavior in a specific way, e.g. execution speed, reliability etc. 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 necessity
etc. Q. 2.5.2 V/hat are advar,ta f

— External requirements : Requirements which are generated from the factors that are extern- (1) SRS contains the bast
to the system and its development process, e.g. interoperability requirements, legislate as per expectations.
requirement.
(2) A SRS gives a base fo

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

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

Syllabus Topic : Software Requirement Specification (SRS)

2.5 Software Requirement Specification (SRS)

(MU -May 15
q, 2.5.1 What is SRS document ? (Ref, sec. 2.5)

SRS stands for Software/System Requirement Specification. SRS is a special kind of docu®
which contains user requirements for a system which states properties and constraints that &
be satisfied by a software system.
IEEE defines software requirements specification as, ’a document that clearly and

Scanned by CamScanner
PF| Software Engineering (MU C_ll Regnlrornonh Ana tysli and Modelling

The outcome of the requirements gathering and nnnlynin phase of the 8DLC in Software
Requirements Specification (SRS).

- SRS is also called as requirements document.

SRS is base for software engineering actions and is generated when all requirements of software
project are gathered and analyzed.
It is 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) ______ (4 Marks)

(1) SRS contains the base for agreement among the client and the company who develop the product
as per expectations.
(2) A SRS 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.

Characteristics of SRS

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

A good software requirement specification must satisfy following characteristics.

Characteristics of SRS

1. Correct
— - - - ------------------ ------------------- I 1. - . . 1
Jl

2. Unambiguous

3. Complete

4. Ranked for importance/stabillty

5. Modifiable

6. Traceable

7. Verifiable

Fig. 25.1 : Characteristics of SRS

Scanned by CamScanner
 2 12
Isoftwaro Enginooring (MU - Som, 6 • Comp) ~ Requirements Analysis an
U Correct

- SRS is correct when oil requirements of user are described in the requirement docu ment
Tlio listed requirements must bo matched with desired system. The requircm

~ This depict that every requirement is analyzed to give assurance that it (SRS) contain , Remember tt
requirements. 2.5.3 Format of SRS
Remember that there is no specific tool or process to ensure the correctness of SRS.
Q. 2.5.4 Exp<3:n '
- Correctness gives assurance that all stated requirements are worked as expected.
2. Unambiguous Structure o!

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
SRS so that it will be non-confusing and simple to understand.
3. Complete

SRS is complete when the requirements undoubtedly specified that which work the software
product is required to perform.
This contains each and every requirement associated to performance, design and functionality.
4. Ranked for importance/stability

Each and every requirement has not same importance, so every requirement is recognized k>
make differentiation between requirements.
For this purpose, it is needed to undoubtedly recognize every requirement.
Stability refers to the probability of further modifications in the requirement.
5. Modifiable

The requirements given by user are changeable, so requirement document must be generated in
such a way that those modifications can Bp innhidgU onn . . . . .
structure and style of the SRS.

6. Traceable

SRS is observable when the source of every requirement is unambiguous 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.

Verifiable

SRS is testable when the stated requirements can be tested with a cost-effective procedure to
verify whether the final software fulfills those requirements.

Scanned by CamScanner
 Som. 6 - Comp) 2-13 Roquiromonts Analysis and Modoliing

The requirements are tested through reviews.

- Remember that clear requirement is needed for verifiability.

2.5.3 Format of SRS

Q. 2.5.4 Explain general format of Software Roquirumont Specification (SRS). (Rot soc. 2.5.3) (10 M.sfka)

Structure of SRS document includes following sections with various subsections in i t :

Format of SRS

1. Introduction |

(i) Purpose j

(li) Scope '

— (iil) Definition, Acronyms, and 1

Abbreviations |

(iv) References |

(v) Overview [

2. The overall Description

(i) Product perspective

(ii) Product function

(iii) User characteristics

(iv) Constraint i

— (v) Assumption and dependencies|

(vi) Apportioning of requirements |

3. Specific Requirements j

(i) Interfaces

— (ii) Database

(iii) Performance ;

(iv) Software system attributes

4. Change Management Process

5. Document Approvals

6. Supporting Information

Fig. 23.2 : Format of SRS

Scanned by CamScanner
 Introduction
T
"»*»«- ».<*. UW '■ “ '* *\
subsections :
(0 Purpose
TIU section
This .• specifies the main purpose ofr SKb <«0CUI
AUS document with it* intended audi cnce for X
SRS is constructed.

(ii) Scope

- This section specifics scope of the system for which SI

- Scope defines not only benefits, objectives and behaviour of software product but
limitations of software so as to understand the boundary o

(iii) Definition, Acronyms, and Abbreviations

To avoid ambiguity of terms specified in requirements, SRS provides definition, abbreviation

acronyms about these terms.

(iv) References

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

(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 concer?
about this section. It contains following subsections :

(i) Product perspective

This section contains the information which states the benefits of current product over oth-
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 W'
relationship among variables present in the system. This information is provided in si®F
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 knowledge U’
least the educational qualification or basic knowledge related to the field. This section ph>'*

Scanned by CamScanner
Software Engineering (MU • Sem. G - Comp) 2-15 ~ Requirements Analysis and Modelling

(iv) Constraint

It includes limitations of components used in the system 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 arc 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 provides a
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
 Pcqui

jfotwaro Engine

’ntroducH
1,1

This doci
feedback
he utilize

1 -2 8eop«»

This
Table of Contents

1. Introduction
1-3 O7«rrvj®
1.1 Purpose
This ?r

1.2 Scope re Wed <

1.3 Overview

2. General Description

2.1 User Manual

3. Functional Requirements

3.1 Description

4. Interface Requirements
Z
4.1 GUI General Des
cr
4.2 Hardware Interface ~ ~
lota cf p
4.3 Software Interface a- atu;

5. Performance Requirements “ Anothei

it
6. Design Constraints »■
2.1 Useri!
7. Other non-functional Attributes
The syj
7.1 Security hard cc

7.2 Reliability 3. Functional

7.3 Availability 3.1 Descr

7.4 Maintainability - Fc
cc
7.5 Reusability
- St
8. Operational Scenarios r€

p Preliminary Schedule

Scanned by CamScanner
 2-17 Requirement Analysis and Modelling
software Engineering (MU - Sem. 6 ■ Comp)

Introduction
1.
sc
1.1 Purp°

This document gives detailed functional and non-functional requirement/! for online student
feedback system. Tho purpose of this document is that the requirements mentioned in it should
bo utilized by software developers to implement tho system.

1.2 Scope

This system allows tho students to provide quick feedback which is provided by collage staff. Tho
feedback report is generated and which is checked by HOD’s. Ho can view grade and grade
obtained to tho lecturers.

1,3 Overview

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

Submit Feedback
Feedback Report
| Student}
Online Student
Feedback System

Send Feedback Form

E-mail To Student

Fig. 233 : Online student feedback system

2. General Description

- This online student feedback system replaces the traditional, manual feedback system by which
lots of paper work will be reduced. The teachers are able to provide feedback regardmg faohty
and students are able to provide feedback easily. This is primary feature of this system.
- Another feature is that feedback form can be provided to student and staff by emailing for filling
it •

2.1 User Manual

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

3. Functional Requirement

3.1 Description

- For identity of system .WM W? “ """ *“

corresponding subject and skills.
- Statistical report acconlingly subject or skill should display individual s report whenever
required.

Scanned by CamScanner
 Software Peering (MU • Scrn. 6 - Comp) 2-19 Rcqulromnnl.i AnofyslJ and Modeling

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 - M a y 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 '

May 17. May 18. 20 Marks

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
- PHID - Patient Hospital Identification Number

1 3 Scope of the Project

- The purpose of this specification is to document requirements for a system to manage the
hospital.
- The specification identifies what such a system is required to do.
- The Hospital Management System will manage a waiting list of patients requiring different
treatments.
- The availability of beds will be determined and if beds are available the next appropriate
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.
- The current manual method of managing patients, nurses, and beds is time consuming and
error prone. It is also difficult to manage the large paper flow involved in this process.
- The Hospital Management System will allow hospital administrative staff to access relevant
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

2. 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.

2.2 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.3 Operating Environment

Following are the requirements for running the software successfully :
- Processor - Pentium III or Higher.

Scanned by CamScanner
[Ji Software Engineering (MU ■ Som. 6 • Comp) 2-21 Ftoqijtremonte Analyst ond Modeling

- Ram — 512 MB or Higher.

Disk Space - 10 GB or Higher,
OS - Windows XP or Above.

2.4 Design and Implementation Constraint

- GUI only 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
 noqulroments Analysis and Mn

2-22
1
nticnts waiting for available
■ iu --------- ._ . l crc are any P
- Waiting list : Monitoring to see i cCOinO avail*
Compon
assigning them to doctors and beds once
Use ci
Other Non-functlonal Requirements

5.1 Performance Requirements ilarly are done :

The performance of our sol two

- Password Management
- Regular Database Archiving
Virus Protection

SO,Cty
“ “ |yec jg o f common errors should be limited, e g -> (i) Use
Humans are error-prone, but the negative ene as ked to confirm their intent.,
should realize that a given command will delete a a, - Use
have the option to undo. - Alic
5.3 Security Requirements - To i
pro!
— It is
members use. - Exe
- The data in the database is secured through multiple layers of Protection.
- One of those security layers involves member passwords. For maximum Security of your
software, each member must protect their password.
5.4 Software Quality Attributes
-> (ii) Ac
The Quality of the system is maintained in such a way that it can be very user-friendly. The
- Ar
software quality attributes are assumed as follows :
Accurate and hence reliable. - Ar

- Secured. - Tc
de
Fast Speed.
- A
Compatibility.

2.6 Developing Use Cases (UML)

|Q. 2.6.1
- Use case is a term used in system analysis to d~t •-------------' ----------------------
requirements. etennine, clarify and integrate all syste® (iii)

It describes how user interacts with the system to achi

Certain
Use case consists of three basic element goal,
factor, system and goal.

Scanned by CamScanner
 Software Engineering (MU - Som, G • Comp)
r
~nr '11 "■ ■— —— mmL— 2-23
A uso case diugrnm dcscril)cs vnriolM Analysis and Modelling
>ut by a system.
Components of uso cnso diagram

p ------------ ------------ — wiupunc

1 Component of ub« CBM|

(*) Use caso

(ii) Actor J

(iii) System boundary |

use case
(i) Use case

Use case of a use case diagram represents various business activities performed in a system.
All discrete business activities of a system 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.
It is represented by an elliptical shape labeled with use_case name
Example,

Update account

Fig. 2.6.2 : Use case

(ii) Actor
- 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 case diagram.
- 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.

Actorjiame

Fig. 2.63 : Actor

(iii) System boundary

- System boundary defines the scope of system or limits of system.

- It is representation of entire system as described in problem statement.
- System boundary is represented by solid line rectangular box.

Scanned by CamScanner
 2-24 Requirements Analysis andM-
IfrP Software Engineering (MU - Serrh6_2_Comj

Use cases are drawn within system boundary whore as actor is outside of the system boa
LfeT Sottv/are Er

usecaso
_ _ System boundary
- Her
(Hi) Genera
Actor
~ It is
pan
~ It ij
Relationships In use case diagram
Examp'
- A relationship between two use cases is in general a dependency among them.

(i) Include

When a use case is represented as making use of functionality of another use case dia ..
relationship between use cases is called include relationship.
An include relationship is denoted by dotted arrow with arrow head pointing towards derind,
case.
Stereotype «include» is labeled on arrow. The I
Example,
A
d
Accept Birth_Oate 2)
1
«lndude3»
I

• Compute Age

Fig. 2.65
2.7 Re

Extend

The relationship between two use cases in which child use case adds new feature
functionality of parent use case is called extend relationship.
It is represented by dotted arrow with arrow head pointing towards parent use case.
Stereotype «extend» is labeled on arrow.
Example,

Compute
class
mot
! extends
(a) The

Calculate
percentage

Fig. 2.6.6

Scanned by CamScanner
 g (MU - Sem. 6 - Comp)
2-25
13
of student.
(iii) Generalization

It is parent-chili
use case is an underlying process of system but it enhances
parent use case.

>w
Example,

Sloro customer
.records (paper files)

3deriv Store customer

edm, rfiPArrta fnomn J

Fig. 2.6.7 *

The Use Case Model

A Use Case Model describes the proposed functionality of a new

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.

Syllabus Topic : Requirement Model

Requirement Model
I---------- - - - - - :
-- - - - 7” ~~ (10 Marks) |
Q 0 71 Explain requirement model. (Ref, sec. 27)-------------------------. --------- -----------------------------
3 t0 cxistW
- Requirement modeling is implemented after the requirements and constraints have been

;
. X— ‘ — '■ “*• * ■* ■" “■ “

suitable approach is depending mode Ued; some of the most common requirement
vonuirenients can ue
There are many ways

(a) The Domain Model respective things (Domain Concepts

- The Domain Model manipulates from a business perspective,

e 1 68
“deals with”, i- - rep "

Scanned by CamScanner
 =— r— r-— - - VJVIII. _ —

- - - an(i often properties and their

The information captured for a Domain Concept is a desenp
relationship to each other. , ...
mi purpose of the Domain Model is to establish a common
The „ uno
understanding of the static aspects of
the business domain among all the stakeholders. #

The Domain Model supports the creation of quality requirements by es on

vocabulary across all stakeholders reducing ambiguity and redund V
As a result, the following guidelines should be considered :
o The contents should be written in the business language of the domain and avoid
implementation specific or technical aspects (such as operations or actions, winch £0Oe

presentations do not rule out): Use good business names!

Stakeholders should be comfortable with the chosen representation of the Domain Model m
order to be able to provide feedback. As a result, multiple views on the domain model may be
necessary for different stakeholders.
The domain model is developed in iterations where necessary details are enriched over time,
- An obvious way to identify Domain Concepts is to identify nouns and phras in ted j
descriptions of a domain. The information about the Domain Concepts can come from
documentation, industry standard documents for a specific domain, and output from
requirements elicitation. M
- The Domain Model can be represented in different ways. The representation is dependent oifl
methodology and the formality employed in the project as well as the experience of the
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.

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 or
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
 S' software EnqingedngCMu , Sem _
====== ===s=s ==a
q “ ==® a5=_2"27
e Ot er mm,els = = ef uirfttT>f
°“ used to ° ~* ' ' n i s Analysis and Moding
Unrt
(«) Lifecycles “>“'>ty include: --------------

These are descriptions of the valid »

hd statcs
relationshins >n
b- legal transitions). along with the
It is important to no
system as a whole,
world). the mteracti
' " ™ of the system thc

(d) Business Process models

The use of Business Process Modelling (BPlvn ♦

M re
alternative approach for develn • Present the functionality of the enterprise is an
deveIop
in a tnnl JL , software as fundamental concept. It t is to develop the model

attaChed 10 80 U ttt be
used as tapZXtZX"’ “ “

(e) User Stories

In agile projects user stories are used to capture requirements, these are short descriptions of how
a particular user wants to interact with a system, in the form “As I want to, so that”.
The user story includes a set of acceptance criteria which describe the boundary of the story and
defines when it is done.

(f) Traceability Matrix

- To fulfill the need for traceability a traceability matrix can be produced.

- This can be as simple as a table which cross references the requirements to the software
component that fulfils it, however this can become very hard to maintain, so it is more common to
use a requirements management tool when this level of formality is required.

2.8 Analysis Modelling

|Q. 2.8.1 Write importance of analysis modeling. (Ref, sec. 2.8) ------------------------------------------------------(5 Marks)J

- After the Requirement Analysis, as output gets the specification regarding software’s operational
characteristics, designates software’s interface with other system elements and set up constraints
which the specific software must need.

All the way through analysis modeling the primmy focus of software engineer is on what and
how.

k
.Tl" ”* - - *• —
engineering tasks.

Scanned by CamScanner
 2-28 Requiremonts Analysis and Mocfofti,
L3ZJ** Software Engineering (MU - Sem. 6 - Comp)
Software Eng: nr
Establish models which describe user
ns it is transformed. o The

Ensure
There are throe primary objoc
o Ea
Describe customer needs
Krepti
Establish n basis for the i
o Dr
3. Define a set of roquircmc
o In
The analysis model fills the gap betw een a
functionality as it is accomplished by Um process of applying software, hardware, data, hu m , n Element
and other system elements and a software design which elaborates the software applies
architecture. ,Q. 2.3.2

That means Analysis model plays a role of link in between the 'system description' and th. Scenario '

’design model’.
A Bridge
Exar
Class ba
System
The
description

Analysis ltd-
model

Design ,
model

Behavi:

Th
Fig. 2.8.1 : Analysis Model

In this model, information, functions as well as behaviour of the system is defined and all of the Flowc
elements of ’design modeling* are translated into the architecture, interface and component level
Ir
design.
It
2.8.1 Analysis Rules of Thumb
E

The model must concentrate on requirements which are

- Each and every element regarding the analysis model must be added to an overall understanding
of software requirements and supply insight into the information domain, function and behavior
of the system.

Delay consideration of infrastructure and remaining non-functional models until design.

For example, there may be need of a database, but the classes required to implement it, the
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.

Scanned by CamScanner
 Software Engineering (MU -Sem. 6 -Comp) 2-29 Requirement

o The level of interconnectedness among classes and functions must bo minimized.

- Ensure that the analysis model offers value to all the relevant stakeholders.
o Each constituency has its own use for the model.
Keep the possible simplest form of the model.
o Do not introduce extra diagrams if they do not provide any now information.
o Implement only those modeling elements which have values.

2.8.2 Elements of Analysis Model

5 Mark*;
Iq.2.3.2 Explain the various elements of analysis modeling in detail. (Rel. 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

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

Flow oriented elements

- Information is transferred via a computer-based system.

- It shows way of transforming data objects when they flow between the different system functions.
- Example : Data flow diagram, control flow diagram.

Scenario-based elements Class-based elements

• Use-case diagrams • Class diagrams

• User stories • Collaboration diagrams

Analysis Model

Behavioral based elements Flow-oriented elements

• Sequence diagrams • Data flow diagrams

• State stories • Control flow diagrams

Fig. 2.8.2 : Elements of Analysis Model

Scanned by CamScanner
 Requirements Analysis
ware 2 30
~ Engineering (MU - S c m . O - Comp) - _
S
Syllabus Toplc£Sconaiioj>osed Mo

Scenarlo-basnrt Model

2
- ‘ 2.9.1 Write note on Scenario bar.od model. (Hof, soc- Q

Use-cases arc simply an aid to defining what existi

bo performed by the system (use-cascs)." Ivar Jacobson

language from the point of view of a defined actor.

2-9.1 Writing Use-Cases

We have already seen how to develop use cases. The important aspects are .

-V (1) What should we write about?

I* 8! (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

- Users can play a number of different roles for a given scenario.

2.9.2 Developing an Activity Diagram

Safe Home

' Access camera

surveillan via the Cameras
Internet

Configure Safe Home

home owner \system parameters

Set alarm

•*-« PingActWtyDiagram
What are the mam tasks or functions that
316
Performed by the actor?

Scanned by CamScanner
 Comp)
Whttt
astern info,
2
r*** at *-*-*-. n b
formation does th ° Ut chon
8<« in tl

unc
’ I* Ct« 1 d>.>D( . M7

Enter password
and user ID

Valid passwords/ ID Invalid

-s. passwords/ I D
Select major
I function

other functions I -------------

may also be | Select surveillance

input tries
remain
No input tries'
remain

thumbnail views Select a specific camera

Select a specific Select camera

camera-thumbnail icon

View camera output

in labeled window

Prompt for
another view

Exit this function See another camera

Fig. 2.9.2 : Developing Activity Diagram

2.9.3 Swimlane Diagrams

The UML swimlane diagram is a useful variation of the activity diagram and allows representing

the flow of activities described by the use-case and at the same time indicates which actor or

analysis class has responsibility for the action described by an activity rectangle.

Scanned by CamScanner
 onquirements Analysis and M (MU-c
Aii,
2-32
Engineering (MU - Scm. 6 - Comp
tbat The problem state]
llcl segments
Responsibilities are represented as pnra
Interface For isolation of po
■ lanes in a swimming pool.
Camera Identify each and
Homo owner
Identify operator
There are numbe
( Enter password External e
I and user I D
information
Invalid
Valid pjsswordsrfD
passwords /ID Things su<
Select major function
informatior
Prompt for reenry
Occurren
Other functions Input tries
may also bo
regarding i
remain
selected
Roles ant
Select surveillance with the s
N< Input tnes
remain
Organiz;
Thumbnail Select a specific applicant
view . .camera
Select camera Places s
f Select specific
icamera-thumbnai icon respecth
Structv
output objects <
wiew camera output One can ext
. in labelled window ,
See another
problem.
camera
After the p
Exit this The list ge
function considered
Each and <
Fig. 2.93
To detenr
Syllabus Topic : Class-based Model measured
Reta
2.10 Class-based Model only

Nee<
[q.2.10.1 Writs note on class based model. (Ret sec. 2.10)
hav
- This section describes the process of developing an Object-Oriented Analysis (OOA) model. Mu

- The generic process described starts with guidelines for identifying potential analysis classe’ als'
rej
suggestions for defining attributes and operations for those classes, and a discussion of the Cla»
Co
Responsibility-Collaborator (CRC) model.
th
The CRC card is used as the basis for developing a network of objects that comprise the obj
relationship model.

Scanned by CamScanner
 software Engineering (MU - Som, 6 • Comp) 2*33 Requirement Analysis and Modc-Hini

2JO-1 Identifying Analysis Classes

The problem statement should be examined to identify analysis classes.

For isolation of potential classes a "grammatical parse* can be used.
tify each and every attribute of all tho classes
y operations which load to manipulation of tho attributes.
- There arc number of wnvo
ouHfjncn iiHUlJlcyi ;
o
T be C9
info Z t i o n ? to r R" Cb by
referred
n n S0VWB1 Bystc,ns dcvices
a computer-based -system.
flnd
people that generate or use
rpj • 1- *
o
informntin ri
nuation domain ° r tho
• for ’ displays,
respectiveletters and signals which are considered ss part of the
problem.
Occurrences or ovonf« cnnK
M a
iwrorrT u movements that take
gnrdmg robot Property
place withintransfer or the
the context finishing
of system point of a series
operation.
o
manQ er
with the s t ’ en neer
and salesperson played by individuals who need to interact
o S ’ onal units such as division, group, and team which are basically relevant to an
application.
such as manufacturing floor or loading dock that establish the context regarding the
respective problem and the overall function of the system.
tures such as sensors, four-wheeled vehicles, or computers which define a class of
objects or related classes of objects.
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 mcreased 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 :
o 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 RA, 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.
o 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
 Suftuam i oq’noi'ii' 1 - ----------i 7 ZTor»p<’ r
"“ 0 "" r,,r th0
-----------aiU --""Tu7Z*’ •” *** '„.«>«•.< -f "“’ cl,, "“-
o CVmnuwi oprrotiu** < applied *° n s n the problem npnco .
these ,UB..r.l •’I’.'"'" 1’"" " ( e „, Hi ..w whirl, for the nmpreti, -
K nfid Requirement*
or ..so InfonnhUon lbc „.q..lrv..«
■.l«AV«l->‘"''”’ w , n " C'“

2.10.2 Specifying Attributes l b c class within tho cont

whirl, complo'
Attributes nro sot of data objects
problem space. * of attributes for an analysis class, a
_ _ _ _c?
For tho purpose of developing a jueantngfu s c bo ] o ng to the class.
„„ revio. a ™ «»d d — «•* I ID
; d(ltn itcms fully dc(inc
tocaiZm

panAr#
ZoornGe

d'j*%rrr.j
translate
Class namo di pia/.
-------- System Attributes di'.p’a/
d'sp'ay;
SystemlD
voriricattonPhoneNumbof/'
systemStatus
dolayTlme
talephonoNumber
mastorPassword
tempornryPassword
numborT ries ___________

program ( )
display reset ( )
query ( ) -------- --------------
modify ( ) Operations
call ( )

Fig. 2.10.1 : Specifying Attributes 2.11 Behavl

2.10.3 Defining Operations

Q. 2.11.1

Operations which define the behavior of an object are divided into 4 broad categories : The!
1. Operations which manipulate data (adding, deleting, selecting, reformatting.) events or

2. Operations which carry a computation. Following

3. Operations which inquire regarding the state of an object. 1. Eva!

syst
4. Operations which monitor an object for the occurrence of a controlling event.
2. Ider
spe<

3. Ger

4. De’

Scanned by CamScanner
 • Scm. 6 - Comp) 2-15 Bwuwnwo Analyst-1 nnd

Floorplan
typo
namo
outsit leDirnon-.lom
dolorminnTypo ()
ponltlonFloorpInn
scale 0
change color ()

is placed within

Is part of

Camera

type
Wall
ID
location type
fieldview wallDimensions
panAngle
ZocmSetting determineType ()
computeDimensions ()
determineType ()
translateLocation ()
display ID ()
displayView () is used to build is used to build
displayZoom 0
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.
2. Identify events which force the interaction sequence and recognize how these events relate to
specific objects.
3. Generate a sequence for all of the use-cases.
4. Develop a state diagram for the system.

Scanned by CamScanner
 nnquiromonts Analysis and
Engineering (1/
2-36
(Uofl consistency. th® Software Spe
-------------— -------- ---- f nCCU racy as
5. Review the behavioural model to v
0
State Representations nrn two import
there are v
In the context of behn
should be considered . the system Pc r
9
o The states of all tl 10 outride” *
- — - cl l as active charactcnstics.
The state of a class considers both passive as « attribu tes of an object.
A passive state is nothing but the curre sWtu9

The active state at an object represents th

.„„ c r«rmfltion or processing. timers lockedTime

locked
Specification G
timer > lockedTime

Layered fo:
password = incorrect
and numberOfTries maxTries ________ Consistent

comparing J numberOfTries>maxTries All acrony

key hit Compulso

reading
password do:validatePassword Style shoi
entered
password=correct

selecting

activation successful

Fig. 2.11.1 : State Representation

The States of a System

o State : It is a set of visible circumstances which characterizes the behavior of a system
given time.

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 f orC1
behaviour.

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

Scanned by CamScanner
 Evoryono know exactly
what had to bo dono *
until someone wrote It
down!

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.
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...

□□□

Scanned by CamScanner
 - Sam, B - c
assisting to attract, grow, T
of their software developmi

- Enterprises which attain 1

Probability of carrying effi
•4 2. The Product
Module 3
Product is nothing but
development of produc
Syllabus consideration of subst
constraints must be do
: COCOMO U Mods., Spec.., teM - If there is lack of th

SoOw.w P~|«< Estimation . LOC. FP. BnpW * estimates of the cost,

T qvas. „ W*. TraCW
" 9 ' he controllable project s<

™ . -W.1- «• “ « __________________________ 3. The Process

Value Analysis.
— A -software process
complete plan for S
- There are differed
3.1. Managemei
assurance points ■
(5
with the function
team.

At last, umbrell
project successfill.
any one framew
- IU fccua is on the three Fsf People, Product and Process. Here, the manager of the project hn»
control all these Fa to have a smooth How in the project progress and to reach the goal.
- We will see all of those three P’s of management spectrum in detail.
3.2 Process and
Management
spectrum 3 P's
- It is possible
1. People on a regulai
- Measuremt
2. Product
quality coi
3. Process
- At the ent
Fig. 3.1.1 : Management spectrum 3 Ps the quali
project d
1. The People
- In the i
- 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 I

developCTS a
PM-CMM(P - The ci
Software
enhance the readiness of software enternri. t T Engineering Institute t time.
nte,PnSCS 10
more and more robust application '

Scanned by CamScanner
 BIT Software EnqjI
'aggfing u. r
- Corn

re, arid Track

- -‘"““ —-...,r,m.._

‘ S=ESS constraints must be done. '

£X .JXS=t
=<■ identffiealion of letbmud and ma»agera(!M .
- If there ia lack 0{ thJs ,t
estimates of the cost, an efficient est" ‘ P°SS1 to define reasonable as well as correct
a on
controllable project schedul K K °f risk, a practical breakdown of project tasks or a
W c
->. „
3. ~
Ine Process h provides a meaningful indication of progress.

A -software process is used to provide 1

complete plan for software development. to establish a

There are different elements such as different tasks, milestones, work products, as well as quality
ance points which help to enable the framework regarding activities to be made compatible
with the functionalities of the respective software project and the related necessities of the project
team.
At last, umbrella activities handle the process model. Umbrella activities are not dependent on
any one framework activity and are carried out throughout the whole process.

Syllabus Topic : Process and Project Metrics

3,2 Process and Project Metrics .

- It is possible to apply measurement to any of the software process for the purpose of improving it
on a regular basis.

CO!

- The collection of process

time.

Scanned by CamScanner
 jr—
[J Software Enginoenng (MU * ** q in<licatorH which results jn k)T. Xi
riM of pr
. 2™ 2 <■ « p-o” • - 'S
soft wan? process impiovcmcnt. .
- rm J Iv l .uelrie SC nnbl»« n » n m p m j e o l m „ n n Ker o

o A«rs« the vtatu. o f " " o

o Track potential risks - It if

rnai
O Uncover problem urea. before they E o
der
- Re
so
Pi
s
iq, 3.2.1 Write note on Process ivieu — ----- ------------ - I

- The unique efficient method to make improvement in any process is the measure of p5[
.. . ui- me yiuwuu, cr-----------
attriDULes
+a Ki;«h a set of significant metrics depending upon
.
these att.' M«U,
and further use the metrics to provide indicators which will resul in the strat
improvement.
The important factor is that process is considered as only one of several controllable factor
practice of improving software quality as well as organizational performance.
Fig. 3.2.1 shows that the process best fits at the center of a triangle in which three factor .„
connected which have deep impact on software quality as well as organizational performance.
The skill and motivation of the stakeholders is considered as
quality and performance.
There is significant impact of complexity of the product on quality and performance of the tea
- Also one important factor which has significant impact is the technology (methods and toc\
regarding software engineering).

Product

characteristics.

Process

People Development Technology

environment

. veienninants for software quality and organizational effectiveness

o Development environment - integrated software tools,

Scanned by CamScanner
 0 9 (MU - Sem. 6 • Comp) a 4

.Project GcheduVnq and T racking

I C US r SS CO,
‘ d,t, "" B - bu«ne»

- ............ ....... - —

— Results or outcomes
WhUh h
software, defects which have been dolV* T*” * Ve bcen found befoTe rc naa
' ’n « the

products which have been del’ d( CFe Urt er re

Port«d by the end users, work
s urtiviw
““ ~. andou j:~ ’ — spent, duration expended,

1
particular software e taee Xata. ™ 18 °f meMurin
« the
characteristics regarding

measure the
implement
unplementmg the umbrella activities as well effort
as the and time
generic whichengineering
software have beenactivities.
exhausted in
Grady (Grady Booch is an American software engineer, best known for developing the UML
. argues that there are “private and public” uses for different types of process data.

metrics gathered on personal basis, these data is expected to be private to the respective
individual and work as an indicator for that individual only.

• component), and bugs found in development process.

approach.

It is recognized that the beginning of software process improvement must be at individual

Private process data is considered as an important aspect in improving the software gin
approach.
Some procss metrics are private to the software project team bat rorpfat be public W

X and LOG (Lines of Code) or FP IFrmotioa Points) per — •

These data are reviewed by the team to get indicators W improve teampsrto™vmCs

V.npiiypubBem.tdc.bm.rp.t.Ud.U.iddr.dT--.™-" .

teams. . , aasociate d information are gathered and

Defect rates a. -■ ot “ ettm " “ —

evaluated for the purpose d F

s c of te •< — !*

Scanned by CamScanner
 pro|oc< Schoduting an

PFT Spftwnro rngln< rir>(] (Mt > • Soo1 P • Cnfnp '

like nli other metrics. .j >1
tbnn n they BOlVC. A Additionally,
However.
which niltx»oinr.
may lends • - of ino
generation pr0 |,|ein« t"'" for ttx>
x)th mana g PrH „
fluJtflbIo
As there is t
done for the
pmedtioX ns they organic a process sensitivity in the process of approach co

o Make use of common sense as we 1 The aim of

schedule h
, ...... ....................— — — — possible p
Second, i

Xn. He. .. *• ' needed, i

Communicate with practitioner and team, tn cstab _ As there

will bo helpful to achieve them. viduals or teams. the ami
todi
results
Don’t refer metrics for the purpose o ghou ld not be taken as “negative..
Metrics information which specifies a p
.. .. _x..„ ... -v, indientor for process improvement.

3.3 _ _softv/<
As the enterprise becomes more compatible with the gathering and use of process metrics,
iQ. 3.3.1
of simple indicators provides means to a more precise approach known J
Me
Essentially, SSPI takes reference of software failure analysis for the purpose of gathering we
regarding all bugs and defects found as an application, system, or product is developed and usaj
II
3.2.1(B) Project Metrics

|q.3.2.2 Write note on Project Metrics. (Ref, sec. 3.2.1 (B)) __________________________________(5Mark>jj

- Dissimilar to software process metrics which are helpful in strategic purposes, software project
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
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 original
estimates.

The data is used by the project manager to monitor and control progress.
As there is beginning of technical work, other project metrics started to have importance

Scanned by CamScanner
 Software Engineerin
[MU Som. 6 • Comp)
3 1
- Ad.l.tion.my, errors f„ u n „ ln

done for the

-«ign quality and t <’ eR ' n ’ Sphering nt technical metrics Is
ion and testing PT°vide indicators which will impact the
The aim of project metrics is twofold. First th
te
schedule by the way of making the adjustment” Tt" ** development
8 W
possible problems as well as risks. *Ch arc iTOP°rtant to avoid delays and lessen
Second, project metrics are helpful in as
sess
needed, make changes in the tech n ; n i >ug product quality on regular basis and, when
a approac
As th
there
a ■ •
is improvement in quality def t h t 0 enhance quality.
7

S &Te re uce 33
the amount of rework which may
h ”” ’ there is reduction in defect count,
_ e necessary in f.Hp nrnioM _____>

Software Project Estimation

[q.3.3.1 Explain Software Project Estimation in detail. (Ref, sec. 3.3) (lOMarkM~\

— Measurements in the physical world can be divided into two categories : direct measures (e.g., the
weight of a product) and indirect measures (e.g., the “quality” of product).
- In the same manner, it is possible to categorize software metrics.

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

In the indirect measures of the product the elements involved are function ty, q

The cost and effort necessary to develop software, the number of lines code
other direct measures are comparatively simple to gather, as long as p
measurement are set in advance.
However there is difficulty in assessing and measuring directly the qu
functionality of software or its efficiency or maintainability. produ( .t me trics,

When the software metrics domain is partitionedimto usuaUy

it is observed that product metrics e software team.

The consolidation

But what will be the way

individuals or projects?

Scanned by CamScanner
 Project Sch Odu|in |
3-7
Software Engineering (MU - Som- 6 - Comp). eparate project
Software Engin
- To understand this we will take a simplewhich cxa
™ arc ci P >g the software pr
- As per
and make categorization of all the errors
• further com on project
- Those individual measures can software process before release T
o E
- Team X eueountem hundred erwrs dunng the . .
encounters seventy errors. efficient in searching errors through o I

- Being everything is similar, whic comp lexity of the projects, we cannot J

process? Since we do not have knowledg
answer to this question. The
- However, if we do normalization of the measures, it is probable to generate software pro
which enable comparison to broader organizational averages.

3.3.1 Metrics for Size Estimation

3.3.2 Un?

May 15. Dec. 16, Ma ,Q. 3.3

[q.3.3.2 Explain size oriented software engineering metrics (Ref, sec. 3.3.1) I

Size oriented software metrics are and/or

If a software organization maintains simple records, a table of size-oriented measures will be

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

$168,000.
Table 33.1

Project LOC 1 Effort $(000) Pp doc Errors Defects People

alpha 12,100 24 168 365 134 29 3
beta 27,200 62 440 1224 321 86 5
gamma 20,200 43 314 1050 256 64 6
3.3.

further mfonnation shows that the size of documentation is of 365 pages.

Before the release of software the count of errors was na mv n
Within the first year after release to
was 29. The number of people involved in development was
three.

for the purpose of metrics development which i.

jects, as
metrics from various projects as our normahzatton
our no r k value, the Line of code
assimilated withwill be selected.
other same types of

Scanned by CamScanner
 Software Em

PaEe30fd<>C
~Ho DpcrI{LOC
The Siz
d
process. are not c„
the bert KluU<)n for the

Q. 3.3.3

(5 Marks)

WHe counting the number of source instructions, lines used for commenting the code and the
header hues should be ignored. ~
Determining 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
— In order 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.

Syllabus Topic : Function Points (FP)

3.3.3 Function Points (FP)

(MU - M a y 17)

May.1.7; 5 Marks

0. 3.3.4 Explain Function Point Estimation Torhnig. .» in detail. (Ret, sec. 3.3JL
measure of the function.

11
:: - * ““ “
necessary to derive it indirectly. by Albrecht. A measure the
The concept of Function-orient ne

function point is suggested

Scanned by CamScanner
 3-9
6 -Comp
ji-YT .Software Engineer

Is the upd;

Z— -X — uro — - — ore Is there is

tO. Is there ii
berofu .npois. o.orinput.houMhe re.
11. Can the <
Q
Numborof user outputs : Hearts, screens, error ntossoges, cte. 12. Is there

Number of user inquiries : An on-line i/p which results on on-hne o/p. Is the r
14. Is t h e e
- Now all th
o Number of external interfaces : Data files on storage media.
The const
Once these data have been collected, a complexity value is associated with each
applied tc
Organizations that use function point methods develop criteria for determining wh '
particular entry is simple, average, or complex. Nonetheless, the determination of compi - As soon
somewhat subjective. measure
Weighting factor Errors j
Computing
function points Measurement parameter Count Simla Average Complex
Number of inputs | | x 3 4 6

Number of user outputs x 4 5 7 3.4 Empiric

Number of user inquiries 3 4 6
Number of files Q. 3.4.1
X 7 10 15
Number of external interfaces | | The
x > 5 7 10
the
Count total --------------------------------
Ifs
Fig. 3.3.1
Ev
in
used :
FP = count total [0.65 + 0.01 Z(Fi)] *T
(where count total is the sum of all FP entries) b
Expert
given fourteen questions : allies depending upon responses to the following

2. Is there any requirement of communications?

3- Are there distributed]
processing functions?
Is performance critical?
5
‘ Will it is possible to exi
6.

in
put transaction to on-line data entrv I
screens or operations? a entry 80
to buHd over multiple I

Scanned by CamScanner
 Software En
-Ipomp)
3-10
’■ ujxuuon or m „8 l „ ,
hcrci
,n '“'"p 1Mityln ’

.....-

and ,n
h the sy n, deC XToX" ' t “ , ”UOn in

Now ar, qUMtiona m Meo eba„ B o M d eaM „f „ M hy

ValUM Which rc
— p rc soT ' 1 W ' t h t l ’° h !,,
' ’ ' ’r a ’ C, ' 1 ,’ 1" tht ’ '’ 0 - r--
to fo
“ so ” ™“«on baSCd and the
n th fMta weighting factors which are
°n as the calculation of W ° ° -
th<
measures for th e * used so .. to nonaaht,
Ware
otsperFP, Defects per FP, $ „ er pp p ° Productivity, quality, and other attributes like
=============== S
===— — _ £ °f documentation per FP, FP per person-month.
----- Syllabus Topic :

Q. 3.4.1 Explain the Empirical estimation technii

iques, (Ref, sec. 3.4) (5 Marta) \

.P estimation techniques are usually founded on making a studied guess regarding

the project parameters.
imiJar products are developed previously, then that experience is always helpful.
Even though the base of empirical estimation techniques is common sense, several activities
involved in estimation have been formalized over the years.

There are two frequently used empirical estimation techniques namely : Expert judgment
technique and Delphi cost estimation.

Expert judgment technique

- In Expert Judgment Technique, an expert analyzes the problem in detail and makes guess
regarding the problem size.

- Usually, the expert makes an estimation of the cost regarding the different components (such as
. .... „f the resnective system and then integrates them to find out the over

estimate.
errors. Additionally, it is likely that the expert may miss
Yet, this technique is exposed to human
few factors accidentally.
lack of experience as well as knowledge

and user interface components but may

not be conversant regar

Scanned by CamScanner
 n ,neenng
Project Scheduling andT >? ' r sotwereE g
) 3-11
— ___** 1
**"*"** 1
Ji f nrm nf nvr -4. . "*** 3. I ***7rable 3.4.1 st
EUTsoftwara Eng na (MU • Som. 6 - Comp, ------------— nS more rem.v............. - juag ’ i 'The multiple
- Esi.-n.micn .undo by group ~ „f fomilin rity w W a apeeifie MpMt mg, I
1
vi individual oversight
- It minimizes factors hko mdividun
the project, etc.
<*■ Delphi cost estimation expert judgment approach are toed to re8 olve
Simple
the shonconu ~ " a coord inator takes part.

In this approach a team which involves a group o exp fication (SRS ) document to aU , Moderate
The coordinator gives a copy of the Software Requir their cost estimates.
the estimators and a particular gubmitted to the coordinator.
- Individual estimates are completed by all of the es rteristic retrnrA-
• +■ anv unusual characteristic regarding u. t Embedded
- In individual estimates, the estimators point out y
product which has great impact on the estimation.
ne coordinator then makes and hand outs the summary of the cocc
estimators, and incorporates any unnsual rationale that may be noted by any of the estunators. stand
By considering this summary, all of the estimators re-estimate. This method is repeated t„ To ts
several rounds. to so
However, estimators cannot communicate with each other regarding the estimates. The reason i9 C0(
that the estimate of more experienced or senior estimator may influence other estimators. ere;
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 Model

(MU - May 15, Dec.16)

/q.3.4.2 Explain COCOMO Model, (Ref, sec. 3.4.1) |"" ' . 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 formulae link the size of the system and product, project and team factors to the effort to
develop the system.
- We can select to use the COCOMO model for number of reasons :

1. It is well documented, accessible in the public domain and supported by public domain and
commercial tools.
2. It has been widely used and evaluated in several organizations.

- COCOMO 81, first version of the COCOMO model was a three-level model.

- The first level presents an original rough estimate.

The second level modifies this using a several a

detailed level creates estimates fordifferent stages ofthep j “

Scanned by CamScanner
 Software Engineering ( M u . SnrT ,

, Table 3 . 4 . 1 nhow 8 the

- n.e mul t ipIi „ M ---------------

_ _ _ Proj
r.q

Project
Tnl nrnCU3ri
”c 3.4.1 M.k.

Of

COCOMO 8! thinks -------------

“ take dthese
To
PrO8r
~* >
modifications a ges ae»
into ♦
be d
->°Pea a
C C M0 model
to software development like prototyping ° ° P identifies different approaches

COCOMO II helps in development a • ,

SP1T model and
create the whole estimates. embeds number of sub-models that

Fig. 3.4.! shows COCOMO II sub-models as weU as .

Application Used Prototype system

on
composition -for. developed using
model scripting, DB
• programming etc

BcisGei Used Initial effort estimation I

Number of < _on_ Early for based on system |
function points design model requirements and I
design options I

Number of lines ofl Based Used Effort to integrate

„ on for» reusable components or
Reuse model
automatically generated
code

(33SGd Used Development effort

Number of lines of t on Post-architecture for based on system design
source code model specification
-

Fig. 3.4.1 : The COCOMO H model

1. The application-composition model components, scripting or database

* nre generated from reusable
- It supposes that systems are gene
programming-

Scanned by CamScanner
 Software Engineering (MU - Sem. 6 - Comp)

PM = 2
- “ — " - Where,
M =
. "x:. X— — „
The reuse model
a standard estimate 01
Reuse mod
that are ax
— Programmer .
For COC(
of the CASE tools used to support development.
without Y
- Table 3.4.2 shows the levels of object-point productivity. black-bc
Code th
Very low Low Nominal high v
/ Developer's experience and. «yhigh~' develop!
/capability work ac

Very low Low Nominal high Very high The for

/CASE maturity and capability
13 25 PMAul
PROD (NOP/month) ___________ 4 7
Where,
Therefore, the concluding formula for effort calculation for system prototypes is :
AT - Perc
PM = (NAP x (1 x %reuse/100)) / PROD
ATPROP
Where,
For example
PM - effort estimate in person-months.
NAP - total number of application points in the delivered system. - If t
aul
%reuse - estimate of the amount of reused code in the development.
ge:
PROD - object-point productivity

The early design model

T
This model is used at the time of early stages of the system design after the requirements have
been established.
Estimates are depending on function points, which are then changed to number of lines of source

agreed.
Depend on standard formula for algorithmic models.
Effort = A x S i z e B x M

pmeess characteristics thaTfluZ

needed. These characteristics used in the early design Z **
model r
complexity (RCPX), reuse required (RUSE) 1 tr P «iurt reliability and

<PDIF) PerS
(PERS),
™ . personnel
■ experience (PREQ, schedule e (SCEW
' S C E D) and
and support facilities’ ° Dnel
(FOIL)
ca
P abiUt ?
This results m a n effort computation as follows- '

Scanned by CamScanner
 cnolneerinci (MU• Som. 6 • Comp) 4
l»5oftw2J2i*=====r;5:= "“ ----------- ■
pM = 2.94 x SizcB x M

WhcrC ’
M = PERS x RCPX x RUSE x PDIF x PREX x FCIL x SUED

US0
Th 'T’ Od0 '
9.
ReU se model is used to calculate the effort needed to integrate reusable software or prop*™
that are automatically created by design or program translation tools.

without having knowledge of code or making changes in it. The effort regarding development f

code. Some
Code that has to be adapted to combine with new code is called white-bo
** j kgforc can
development effort is needed to reuse this because it has to be known and changca
work accurately in the system.

The formula for effort estimation is :

pMAuto = (ASLOC x AT/100) / ATPROD

Where,

- Percentage of adapted code that is automatically created

TPROD - Productivity of engineers in integrating such code.

f’Or<*ample
d 40% of this is
If there is a total of 10,000 lines of white-box reused code in a system am
automatically generated, and ATPROD is 2400 then the effort required to integr
generated code is :
(10,000x40/100)/ 2400 = 1.67 person months

The other component of the reuse model is used when a system contains some new co
reused white-box components that have to be integrated.

Therefore, if 30,000 lines of code is to be reused, the new equal size estimate might be 6,000.
Essentially, reusing 30,000 lines of code is engaged to be equivalent to writing 6,000 lines o ne
code.

- This computed form is added to the number of lines of new code to be developed in the COCO
II model.

o ASLOC : Number of lines of code in the components that have to be adapted;

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

- The below formula is used to compute the number of equal lines of source code:

ESLOC = ASLOC x (1 x AT/100) x AAM

Where,
AAM is nothing but Adaptation Adjustment Multiplier.

Scanned by CamScanner
 abbreviated-
Here we will see two specialized estimation techniques .

3S.1 Estimation for Agile Development

Since the requirements regarding an agile project are set by user scenarios, an estim
approach can be developed which is informal, reasonably disciplined, and meaningful
environment of project planning for each software increment.

tb
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 he nece
3sary to
develop it
3a.

3.6

. Code), function Point), or in W

4a. Estimates of all the tasks are combined to set an estimate for the scenario
4b . a y, historical data - to the yoiume i

every scenario which is to be implemented for a provided

m m . ’ eposes are served by this estimation :

05 WhiCh COnsidered
confonnstX X' e LT “ the increment I

2) To set a basis for assigning effort as the increment- a , i

3.5.2 Es»maftonforWeMppProject8

Scanned by CamScanner
 Cornp'i

wl
input. mv n„thi ng b “ >-n •><!«„„
P-en. «teh tab(iruwd <-P» l .e .............
m
Outputs are cvorv n, cm or .
Page,
o Tables arere ev ery, ,l og ical t ° . .
evnw *Po n
rt b pp n R* . * n P t ,( B u c h a , w
D
o Interfaces P- erve their ,,„ r . “ every X M , ...
m,t
U und X “" »• -a. nl e, ni,
o Queries are the «« iue record formats) into the
. one whink
interface such as DCOM or PrvK< publ «hed cxtc
vx
mallv>. nr < «P
M ext
Function points (FP a ) ernal references °f a mes9a
« °™ art «’i
« is possible to dotoXTo or , Ot a l i n < l i ' at 'J r O r ™, " m ' f “ - « - k App .
variables”) allied with th ° f a W *bApp bv rmtK •
characteristics of Web * appUcation (such as paee Cnng mcasurea (known as
“Predictor
Page su 8 COUnt me
nhnmr+ •
ctens tics of media (such
( ch as natm P ’ dia count, function count), its
°®Plerity, linking complexity , graphic complexity),
length, reused code length). Nation), and functional characteristics (such as code
- These measures help to establish emu* ■
eStimation mod
media authoring effort, and scrintin<r off L els for whole project effort, page and

S
yii a b u s Topic . Project Scheduling —

? 6 Project Scheduling

technique that decides the sequence of tasks to be done and assigns

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.

Syllabus Topic : Defining A Task Set for Software Project

Defining A Task Set for Software Project

(5 Marks)

oTTi Fvnlain the Work BreakDown structure in details. (Ret sec. 3K1)
Q 3 6 J
----------- - ---------------SZ jects to simpler and manageable work items is called Wk
- The process of dividing complex projects to
Breakdown Structure (WBS).

Scanned by CamScanner
 !22 nQ
T_rr.„ tia r i j ' - nf7
-scntfl
. o f w ork item is creating a datab
Task- Exampl® of
- Work item io also collet ns "I
ion of prOJ in
■ dam. mr simpM< r . \
co this technique for s » j tcr these items are . % The Fi
- Inject mmwers use h items a n d a Ca
as lly . I.
arc broken down to smaJie ip createt
Desigr
CMC field. methodology can bn used for I Decon
- WBS is not limited to a specific I. q 1
management. prese
cornn
3.6.2 Reasons for creating a WBS In A Project
Th er
Q. 3.6.2 Explain the importance

(Ref, sec. 3.6.2)

Do accurate project organization.

o

Do accurate estimation of the cost, time and risk involved in the project.
Illustrate the project scope.
o Plan the
WBS Construction

to different levels. One can break down one can

brokeil
same in 20 items. can break di

Project Name

Task 1

Subtask 1.1

/ / | Work Package 1 1 i

-- --------J
Sk2 Ben
L kageTzz

b,ask
-------l_____J2 fe&2iT
p. -------------------
effe 3
c«veD e s s o
37,6 WnStrUCtUrecan
WBS providesthe decide t he s

ailn
ing, cost, effort estimation.

Scanned by CamScanner
 Cf

L s ern. r .
Th
- 3.6.2
A by b reiUUDK _
N De siCTelc . -n u, c wwk (( Wns rw

“ Of H Decomposition ia the n '?Co " 1 Position > 8uch

present a t t] l e j /’ of bre aki Ma , ket ;; t
8 cal, Wn the iUrr
commercials are n i l ’ ed as r ° >s int

which «
,n lhe
’ i n g and
St
” , , ° ll ’ e P , ’ MSa
” r — =»a BTOnl .
._ New Toyy
For 5-9-year olds

Market 1.3
Research Product
Design Product
Development Production
Planning Marketing Project
Management
Focus =- 13.1
Groups Design Bill of
-- Production
Materials - Marketing
Design
1.1.2 " Strategy
Surveys • 13.2
Research - 114.2
Initial 152
Evaluation - Production — Marketing
Prototype . Testing Plan
'1.1.3
Research 1.3.3
Design 14.3 " 152
Analysis Prototype
Production
Document Testing Marketing
QA Design
Collateral
1.3.4 1,4.4
Market Concept L- 1. 5.3.1
Research Production Production
Models Brochures
Devel Plan
Findings
Sign-off Sign-off
_ 15.3.2
1.2.3
Advertising

Selection
1. 5.3.2
Commercials

Fig. 3.6.2 : Example of WBS

Benefits of WBS

1. Project budget and schedule can be easily calculated.

3. If project is falling, the work breakdown structure can find out the major deliverables impacted.

3.7 Scheduling Technique

(5 Marks)

0.37.1 F in the Scheduling in softwareen

planned project time interval b>

Scanned by CamScanner
 3-19.
I' ' ' J**

It is very important to note « „ r( .Hminnry » Kca of projcct

P nni,,
nV<,IVCd ll I rOjW1
M.™~or.e od-lol- •’ Xn" <•»’ ' " ‘° ’ - X
m
schtxiuk will always identified » mncr(W ,cO pic schedule is develop .
14
As the project proceeds, each task on tJ ident ified a n d schedule. 1,
schedule. Here, specific software i n Boftwaro engineering.
There are two primary scheduling tech q
1. CPM s Critical Path Method
2. PERT : Program Evaluation Review Technique.

3.7.1 Critical Path Method ____________________

/q.3.7.2 Write meaning of CPM? Explain with example. (Rot- sec. 3.7J) --------------
- In a project, various activities are executed in parallel by different teams.
— Some activities are dependent on others and hence cannot start before another task ig — Following
For example, team A cannot test database connectivity unless team B updates the sam There an
ed
H- ■
- When all the activities along with dependencies are documented, one can determine n 1. Activity specif
the
that would consume the longest duration. •
— Work Bi
Considering this longest duration, all other activities can be executed in parallel with this 1 and her
(An activity which takes longest duration to complete). Critical Path is longest — While s
activities in a project plan which must be completed on time for the project to co methoc
date. C0na
Plete j mainte

2. Activity seq
M
■" - ■" - - * J -- The a
— Folio1

“• — - - «-
occurs then
o ]

o
achieved.

Network c

Once th
C n
"“ »uPo™CoXXdUCed M venture between Remington Rai: Estimate

l-Wenacalpath thod This is

31,6 OrigI na, mana8mgPlantaai Wentitic

■ Path method was de

construction project. Now the CPMcan* - F<

Scanned by CamScanner
 r»
TasRi
UPjTS]
T
«ska CS)
' \ g ‘ tfyusi
2 CdY _ _ ,
T• a s k g\5
V 3
J

E '8sk4

T
ask7

Eart tCo,
' etiorrn ne
' P'etio?

We

the CPM
Activity specification :

(W
and henZ e BS) is
CPM WhiCh volved
While specifying ' ” "" “ “ «“
Of
d6taiU Privities are selected for critical path
e 7 b
“° me more
implex to understand and
Activity sequence reorganization

- The correct srttrit.

recognized.
Following are the steps to rec.
Identify the task that tak 2S

en 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

- For this, there is need of determining 4 parameters of each activity of the network.

1 Earliest start time (ES) - When the earlier dependent activities are completed, one can start
the earliest time of an activity.

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

Scanned by CamScanner
 |Mt
SlT Software —
"it
------------ ........
ttepreW- ily duration.
4. Lateot *tert lime lUi) * act

5. Float Time - ES-LS Le delayed wlU dC

'“ y
1
- D „H„ e <he nee. Urao. - st path of lbs respective network dl
e
- The critical path is considered as path on the deadline of t t

- nm is impact or -he en the project will aiso be delayed. %

there is delay in an activity of this P
- If the project management needs to ge
should be reduced.
Numbered r
Advantages of Critical Path Method
Directional
Visual representation of the project activities Diverging .
- To calculate Project deadlines. Dotted lint
- To track the critical activities.
The Possi
There ar
Io. 3.7.3 Explain PERT. (Ret, sec. 3.7.2)

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 U.S. Navy' ■
1950s for the purpose of managing the Polaris submarine missile program.
- A PERT chart is a graphical representation of project network diagram that will consj
- In tl
numbered nodes.
Followir

TO
task. Th
- • In the Fig. 3.7.2, the tasks between nodes 1, 2, 4, 8, and 10 have to be completed in series.J ret

2.
C S odes 1 d 2 d
n7d enende t T “ ” “ >“ 1J
G
be Started
parallel or concurrent teU simultaneously . These tasks are A t

3.
d<>eSn reS0UrCes o r com
called as an event dependency. These are * PletioD ®' i';
denoted with
are known as dummy activities. the help of dotted lines with arrows

mtes „ d 4,s.termed as dummy

.
activity.
I

Scanned by CamScanner
 Software Engln eor jn o i M U .

Cr
eate
schedule Pfograi
'"iming
tosi

10 20

.5 10
’lining

'warn
5 15 s
5
,ns,a,
lation lrnrn
7 activity
Or|
Verslon
Number re eta„ glesare
re
Directional arrows m Pre «ent evP <•
Diverging arrow di
lr6Ct
Dottea.CZ ° 11S e
‘®' and mUSt COm ) ete
'' 'l Be
auentially.
P Sslbly
wate dependent tasks that d " ° “noun-ent tasks.
ThePo ssibiUti « 8 3 2 ° X treqUirerea ™-

There are three esf =

Estimates Involve in Pert

1 • Optimistic Tii

In this way, a range of tune is given for each activity with the most probable value, TLIKELY.

Following are further details on each estimate :

TOPT
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.

TLIKELY

’ Generally project managers are asked to present one estimate utum

that case, this is the estimate which goes to the upper management.

TPESS
Hired to complete an activity. It is assumed that many things
This is the maximum time req need to do resource
related to project estimation is derived.
unavailability is considered tv

____

Scanned by CamScanner
 Project Scheg. ,ti.
1-23
Sent. 6 - Comp

Tuneune chart
Planned tim

Actual time u

IO. 3.8.1 Explain the 2, Forecasted t:

I _________(Ref, sec. 3.8)

- The project schedule is a road map which de

and controlled as the project proceeds.
s - Project
signifii
With 1
- Tracking can be done in a number of different way . memho
deadli
. ___ meetings periodically in which each. team .ember
— The d
of assignments/tasks.
and]
Evaluating the reviews during the software engineering proces
- Usu;
3. Setting the tentative project deadlines that have been completed by the scheduled date3

2.
5. Meeting can be taken informally with resources to obtain their progress on the g>.
assessment. 3.

All of these tracking techniques are used by experienced project managers. - With th
If things are going well (i.e., the project is on schedule and within allocated budget revie show he
progress is also going well and milestones are being reached), control is normal. — It’s pos
But if the problems occur, project manager has to control them as quickly as possible After the
3. Timel
problem has been identified, additional resources may be focused on the problem areas, staff
be redeployed or the project schedule can be changed. ’ - The ti
highly
delivt

- If an

schedule is preceded for each incremental delivery ' Pr<>CeSS U tol£en lnto
consideration, and i i 2.

3.
----------- ---------- ------------------—
TimeUne Charts 4.

- Ti
------------------— _______________-J
- G
Timelines are very importantTZ~~~~ ---------- ----------------------- - ---------------
act.nt.es, organ i 2ation of dead] ® J’6 ' 3 " 86 *ey help to visualize time-re I e;
to de&
n.ed, agram s are useful for managers mb * delays. i Purpos
an Want
y time-related activities. ° * got a high-l evel 1 ■ J
l°°k at their tasks or to •

Scanned by CamScanner
 -- 3-24
B M,SaEaa
Timeline chart helps to visualize t k * ====E« Project

l,D
Planned time * >eframes :

Actual time in-progress that shows how iO n

. j .. f* th° tasks hn v o been in progress.
forecasted tune
2-
— j------- — u6 t;1 B nave knowl i
rC8ar<linB l,lat
significant and challenging co,.,. sotting expectations for delivery time is
anagOn,Cnt
With the help of timelinen Md 7C arta il 8
deadlines. ’ > Possible to avoid low-quality releases as well as

The diagrams add the transparent • a c . ancc

and plan the future t° analyze what happened in the past

UsuaUy, managers use timeline charts for :

1. Projects and tasks planning ‘
2. Road mapping
3. Task management

— With the help of timeline chart*? nenro i j

’ sers can plan many targets to be achieved on one screen and
show how they can be connected with each other.

_ It’s possible to 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.

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

1. The set of tasks and objectives to be completed;

2. Approved dates and deadlines,

3. Dependencies between tasks,

4. Expected duration of tasks.

- Timelines are in many forms, but the most popular and powerful option is Gantt Chart.

- Gantt Chart includes horizontal bars which represent the duration of tasks. It really provides an
easy visual depiction of the project.

Purpose for the TimeLine Charts

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

Scanned by CamScanner
 Project
3-25

BIT Software Engineering ( M U - 6 Cor having

l e y Elements of E
considered as better
Timeline charts
i Planned Vi
time or much effort to form a chart. Gan tt charts as t ese
The allocat
Online project timelines are same os
concerned with time and events. Scheduled (

2. Earned "V

The budgi
3.8.2 Earned Value Analysis 3.8.2) Work Per

Q. 3.8.3 What is Earned Value Analysis 3. Actual <

Earned Value Analysis (EVA) is t The ach

The purpose of Earned Value Ana of Work
Of a project based on earnings or money and scM u , Tools and te
EVA used to estimate the progress
calculated on the basis of EVA. There are i
In simple words Earned Value is a measure 1. Sched

3.8.2(A) Features of EVA 2. Plani

3. Risk
- Earned Value Analysis’s objective is to measure project performance in terms of scope,
Win
tide*
— EVA is used to evaluate project health and project performance. Pri)
Earned \
- Earned Value Analysis is also used for monitoring the progress of a software project / team
involves tasks allocated to the Project Schedule. Cc
— Total time required to complete the project is calculated and each task is given an Earned Vaht ei
based on its estimated (%) out of the total. A
c
3.8.2(B) Need for EVA

EVA provides the measures of project process of different tasks associated with project, so it is a Ste]
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
following :
2.
1. Time to recover
3.

Then at this time, situation is needed to be taken care by finding out the reasons that are
causing delay and by taking the required corrective actions.

2. Request for additional funds/re sources

While there is time to recover, the need for extra resources

or money can be calculated
an early warning.

Scanned by CamScanner
 ' ■
1
• ■ ■

6.
Key Elements of EVA

Planned Val U I , n>V)

The allocated f
U1<J
Scheduled (BC\VS)
j. Earned Val Uo (EV)

The budgeted valUe o f n ,

Work Performance n > °
, ........ ..........

The actual costinv(>1

ofWork Performed
s w
j- Tools and techniques °th. u was previo
There are several soflwar(!
aVai
Schedule maker ‘ abl<! whi
A am listed am M Mtow ,.
2. Planisware OPX2

d 3. RiskTrak
Winsight
5. Primavera
cr Earned Value Analysis - Example

eight months with costing of $10,000 per month.

— After two months, you get understood that the project work is thirty percent completed with
costing of $40,000. Now there is need to determine 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,

Budget at Completion (BAC) - $10,000 * 8 = $80,000

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

3. Planned Completion = 2/8 = 25%

4. Actual Completion = 30%

Therefore,
i Han (%) * BAC = 25% * $ 80,000 = $ 20,000
Planned Value
Earned Value
= 0 6
Sl ,p 2 : --• ““"Zc = $24,000/ $40,00° -

C,« E > / PV ’

Scanned by CamScanner
 3-27 &
SomyargEngineenng (MU - Sem. Compj ----------------T (C pl) is less than one, this mea
6
~ Interpretation : Since Cost Performance cents’ worth of performance.
over budget. For every dollar spent we are getton project
~ Because SPI (Schedule Performance Inde ) Ha
schedule.

is need of corrective measures. ' . '

Besides computing the CPI and SPI, it is possible to calculate the earned value cost and sc
variance. Additionally, earned value forecasting formula.
Cha
Pter

Scanned by CamScanner
 Softw are Design
Module 4

Syllabus

componenneve. Design - Cohesion and Coupling, Architectural Design

4.1

Q. 4.1.1
Wjge note on Software n n ,F
Once the requirements document regarding th (5 Marks)
B

The requirement
problem domain

entities such as the customer, business requirements and

formulate a product or a system
there d SUCh as
' whiiZ help “a software
which engineer“ to model“ the system or prodnct
of principles,
which is to concepts
be built. and practices,
The design model is assessed for quality 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.

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, components,
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
 -------— and procure,
—
J i e set 01 P "
■ Software design enwrap -'. pr „| u ct. applied.
A d
development of a higl.-quoMX ’> design practice, a • gn shouia
Design concepts mast be understood befo mentation, of the saftw c«=>p.„ent ..

Design practice itself lends to the crootmu pctivity foll „„ s .

Design Practices serve ns a guide for the slructur es, architecture,
The design model provides detail .yptem. 6
- A
' fe ” ro ”-Mle rttoK
components that are necessary to P -software design manifesto- jn «■ Ad
«'W«h .
W!1Inlv>

Mitch Kapor, the creator of Lotus 1-2 3, P

Journal.
He said :! Good software design should exhibit
A. Firmness : A program should not h
M.
B. Commodity : A program should be one.
4.1.1 Qualities o ! Go o d D *

Software design mode! consists of 4 designs

There are number cf
1. Data/class design 2. Architectural design
3. Interface design 4. Component design

Component-
Scenerio-based Flow-orinted
Level Design
elements elements ______

Use cases - text Data flow diagrams

Control-flow diagrams -
Use-case diagrams
Activity diagrams Processing narratives
Swimlane diagrams
' Interface Design
£ AnalysisModel .—

Architectural Design
Class-based Behavioral
elements ; elements
Class diagrams State diagrams (1) Innovative
Sequence diagrams Data/Class Design
Analysis packages
CRC Models Innovative d
Collaboration diagrams — Design Model
New design
product.
Fig. 4.1.1 : Translating Requirement Model into Design Model
(2) Functions
Design Guidelines
Good design I
1. A design should exhibit an architecture that : product by oj)

(a) Has been created using recognizable architectural styles or patterns, (3) 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 elements®
subsystems.

Scanned by CamScanner
5

Software £n
£erir
sJMu ,
' ob
h
“-»Po„ ents ° U1 '>
A desi
en sh
X
„ % —
AdeSigO81 O C,
>ould 1 ? " that#
6. ‘ nUrf . and

C bil
”“ Md C|
A d Si 1 e Vir0 t 1
' «™ sh 01 7‘‘ '' " t '’'' ■*»*. th. e' Wn<lenl *■**»«
"■Mh, ch.
dUri b0 C m
» 8 sSof
„ ft , «Wve,
nve ) ° *S t y < ,t t „
* hvar e . d u sifi
8. repe een C0TI1
’gnqh emejjtg atabi e i»ner Jt>
80 Sho Dleth
W be ren Vsis. «d th a t i3 d ■
4.1.1 Qualitie,
o.;r— ——
-tivelyy € rnm
0B
• ““»lM«it 8II ,eMtag
S£
!SlS!5fe 0,
§22dsoftw
numberr o fof
, qualiti (

Marta)
Qualhi88 of
good 8
°ftware
design

0 ) Innovative

(2) Functional

(3) Honest

(4) User - oriented

(5) Correctness

(1) Innovative

Innovative design can be either completely new design or redesign of existing product.

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

(2) Functional

product by optimizing its functionality.

(3) Honest
J J . . hnnest An honest design expresses the functions and values it offers. It never

•*

Scanned by CamScanner
‘f

(4) User - oriented use ,and intended to Methods rep

— Good design is developed based new techndl
USer
for the proc
* lo<5 well as material va
- User-oriented design gives intellect However, t
user’s satisfaction. the same. r

ac
hi(

required functionalities as per SRS documen ----

--------------------------------------------Svilabu: Topic

4.2 Design Principles

(5
Q. 4.2.1 What are the desigri principles? (Ret, sec. ---------------

Following are important design principles :

1. The design process should not suffer from ‘tunnel vision .
2. The design should be traceable to the analysis model.
3. The design should not reinvent the wheel.
The design should "minimize the intellectual distance between the software and the problem
it exists in the real world.
5. The design should exhibit uniformity and integration.
6. The design should be structured to accommodate change.
(A) Abi
The design should be structured to degrade gently, even when unusual data, events, or operating
conditions are encountered. Q. 4.3.

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. 1

10. The design should be reviewed to minimize conceptual (semantic) errors.

Syllabus Topic : Design Concepts

4.3 Design Concepts

Information hh

Scanned by CamScanner
 ~*£GEEEGG— -

u abstracii
~~~~~ °"

22
E) Concurrency

F
) Verification

G
) Aesthetics

F
...... *8- 43.1 fundamental design concepts
(A) Abstraction

— i
I (Ret sec. 4.3(A))
-------- — —— -----------■ - ■ ■' * ___________(5 Marks) |
Abstraction refers to a process by which software designers consider components at an abstract
level, at the same time as ignoring the implementation details of the components.
IEEE 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.

As a process, abstraction refers to a mechanism of hiding irrelevant extra details and

representing just the important essential features of an element so that one can concentrate on
essential things at a time.

As an entity, abstraction refers to a model or view of an item.

M all the steps are accomplished via several levels of abstraction.
hi the software p outJine to problem while at the

At the highest level, onefan g *

lower levels, he/she will get the so

Scanned by CamScanner
CamScanner
 For
example. in the requirements analysis phase. hingung< is m
problem anti ns one jlvetis during .he software proraM. the abstraction lov H
source code of the software is generated at the lowest leve . *\ ' I <c>
bi general three abstraction mechanisms used in software design arc functional abstr ,
abstraction nnd control abstraction. '4-
• iiii'iiunnsniR Help io control i.iic r
bstract design model nnd ending nt concrete design model in n systematic manner. ,
• Functional abstraction : This typo of abstraction includes the use of par*
subprograms. Functional abstraction can be created ns n set. of subprograms
groups . in these sets, routines are exist which may be visible or invisible. The nsp \ '■
routines can bo done within the containing groups and also within other grer- ’
invisible routines are hidden from other groups and are allowed to be used in the I
group onjy.

which describe the flower object clearly. In this abstraction mechanism, represe .'X <Cs' I
well as manipulation details are ignored. .
Control abstraction : This type of abstraction states the desired effect, without cc-
e exact mechanism of control. For example, in programming language like C, if I
ments are abstractions of machine code implementations containing rnn I
S
instructions.
(B)
Information Hiding

te < Ue
modules in such aZyttatthZod'ul ’ °f encapsulatiD
g soft
design dedsat |
inner workings; thus each module is a MaXLC to 0 '
SyStem
ininnnation hiding is an imnorta t need of
“ '
and maintenance phase. “ modifications during the tesq I

’ - HHurmaiion aiding
Results in low coupling,
P«t. emphasis on communication by controlled interfaces

Reduces the possibility of adverse effects.

the 4, „„ te

Results in higher quality software.

Scanned by CamScanner
 te

1 * Software EnoIn
t N — saaaoiMu...,
■* <C> Stru T - O wnp)
Xd
- Son ‘ooturT ----------

’
Add
- i«onaJly . neera i n thoI e Process
pr of
8 lps th
Showing ta sks ° ° ''° o S on wan) „ . " «"aWn K th, „fi ware

as handling riakn.
a
keholderg which h i
SP
° °‘ Nearly design doc ..

t2
°U
(D) Modularity ........ these
- - O]
eomp ?”“* - — . . - ■
2
cti

!o
$al Modulanty can ~ ~
_____ _ _ _ _(10 Marks) |
named ad dr essabaDIe
V * “ of divi.
a compl - -These components components which are
e

anner that
“ one °f diKrete modules
“ such a

After U es
development is completed the di ® ”° “dopondent of each other.
- ... »
becomes easy to handle the software but i u es a system is divided into increases, it
Iso increases the effort required to integrate the
modules.
The process of modularizing a design helns

.d,„. ly **, O.

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 is important to utilize the resources efficiently as much as possible. For this purpose multiple
tasks must be executed concurrently.

Scanned by CamScanner
 Software Engineering (MU 1• Sem. 6 - CqgL
—— " rtan ronCCp
* ' ■* of t hc impo
- This aspect makes concurrency one manner that it
— Every system should be designed in
execute concurrently. . „, n l t i n g f
‘hesy8ten>m . |
r o r exampie, n m e
able to execute any other process i
(F) Verification • - ’ « » nnrl
. . m of confirmation by cxammmg and giving
- Verification is described as a mcchani . soecifications. %
thorn is no mismatch in design output and the design input s P
- Design input can be any physical as well ns performance requirement wh.ch used M
for the purpose of designing.
- Design output is considered as the rei
is a basis for device master record.

(G) Aesthetics

— Aesthetics is the philosophical study of beauty and taste.

- Software engineering is a largely creative design discipline, where new designs (both grapV\_.
design models as well as code) are created from scratch.
-
— Compared to art, there are many targets (e.g. desired functionality) and constraints (e.g,
quality attributes) that the software engineer must adhere to, but these still leave aluv
infinitely many ways to create a model that fulfills all those requirements.
In addition, for essentially the same model, there are many ways to represent it. Since mode’,
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 tV
product.
- Ifs a well-accepted hypothesis that the aesthetics of the artifacts produced during soft™

«'* "" “ — "■ «?- ;

Syllabus T
°P |C :
Effective Modular Design

4.4 Effective Modular Design I

------Write note on effective modular design, (R e

- Afodularity can be defined as dividinT Z ----------— ----------<122

components, which are also called as modules. named and addressable [
A complex system flange pmgram) is divided into r ' I
SUch a that
module can be developed independent of other modXs “ '

Scanned by CamScanner
 Main

i
■
1I
J
n
- Modularizing a d esign ®’ 44J !
“larity

Advantages of Modularization
Maintaining smaller components .g

According to the functional aspects

As per the requirement, the level of abstraction can be carried out in the program.

Components with high cohesion can be re-used again.

Concurrent execution can be made possible.

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 ______

fo. 4.4.2 Write note on tenelionindepenitenos. |R9l SBC

- 44 a
.(Hjgal

_' n , OTC . p, . f tactinw, ted.po.to-. “

(te cnoopte of “*

Scanned by CamScanner
 Software Enpineerii MU - Scm. 6 -Com of developing module
Functional independence is cxtremc common.' nation with other modules "'X
minded* function and an *a versio cach mo dulc is concerr

In other words, wo need to design softw interface when seen f ro

. ntirl nossefl only ««

parts of the program st ructure.

is important. Software having efficient rn

that is. independent modules, is simple to develop since function may be compartment, ,
simplification of interfaces is done (consider the process of rami a team
development).

- It is simple to maintain independent modules (and test) since there is limitation in s*

effects which are generated by design or code modification. Also there is reduction ip
propagation, and possible to reuse modules. (i) <

As a result functional independence is a key to good design, and in turn the respective design;
the key to good quality of the software.

There are two qualitative criteria to measure independence : cohesion and coupling.
(u)
Cohesion is used to measure the relative functional strength of a module where as coupling jj
used to measure the relative interdependence in between modules.

Syllabus Topic : Cohesion

Cohesion

Q. 4.5.1

(Ref, sec. 4,5)

,q h u
— . “ "“”"
4.5.1 Different Types of Cohesion

Q. 4.5.2 Explain different types of cohesion.

D e c . 1 5 . 5 Marks

Scanned by CamScanner
 Software Desiq,

»ty,

cts
55?===:
ry
Jr
(i) Co-incident . oo 84
alcohes
' r
- An unplanned coh p c •
s

- Typically these of whes -aued eo-incidenlaI Program into smaller components

never
4 (ii) Logical cohesion accepted.

- When logically classified element,

en,ents are
cohesion. combmed into a smgle
sinrf. module
a . then it is called as logical

contribute to same systemoperaUon .

i0
” ° CCUrS When COmP
° nent °f a SyStem
porfonns more than one tunction and

- It is generally found in initiation and termination activities.

■fr (iv) Procedural cohesion

When components of system are related to each other only by sequence then there exists
procedural cohesion.

(v) Communication cohesion

, — A-ffprent functions but each function accepts same input and
- When elements of modu et p e j . communicatioDal cohesivc .

u .,» ‘
- It is sometimes acceptable ir n

Scanned by CamScanner
 4-1
Engineering (MU - Sem. 6 - Comp) -

<vi) Sequential cohesion

A module is said to bo sequentially cohesive if its functions a

n
of one function acts as an input data to other function.
This type of cohesion is easily maintainable. I
/;

>Q
If elements of module are grouped togei then
module is functionally cohesive module. x
4.5.2 Advantages of Cohesion
4.6.1 T
cohesion among system components results in Better program design.

(Hi) High cohesion components are more reliable.

4.5.3 Disadvantages of Cohesion

(i) Low cohesion components are difficult to maintain

(n) Low cohesion components cannot be reused.
w cohesion components are difficult to understand.

(0 Di
Syllabus Topic : Coupling
4.6 Coupling

What is coupling? Explain different forms of it. (ii) (

-IL-MgyJJ. 5 Marks

* — - ■— — ' (»i)’

Gv

m3

4.6.1 : Coupling

Scanned by CamScanner
 gsoftwareEngin

He
nxod u I e n i
“ 3 faUs i win , 'Jepen dcnt on
11 Qlso ni0
- But
But m fail. <’ule8 m
and rn, n “nd m r
m d funtl
Thus success or f ° ul e s th ’ ’onaliiz i e if
r fai the f 7 one r,f m
T _ Iure f
O nn y do nol . * » ■«»

-■ .................- ...........

een
■' mdevoiA systAm
P
4.6.1 Types of Coupling “ e '“ cou
' Ili - s » a i Ways

amerent tyPes
pes „.f
-— o coupling (Ref ■> (MU-D-c,15)

u Dec. 1 5 , S M a r k »
C° Pling types

Data
coupling Common
c External
oup|jng Stamp
,, coupling
,, coupling
Control
Concept
coupling Message
coupling
coupling

Fig. 4.6.2 : Coupling types

‘J
(0 Data coupling

system whm they pass data u each ou,cr by

■ f
A component becomes difficult to maintain if too many parameters are passed.
\ *
00 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

- Common coupling is also called as global coupling since in these coupling components of system
communicates with each other by using global area.

(Iv) Content coupling component then those two components

n t refers to the internals of the other
- When one component refers™ I
are said to be content coupl • fMuplingitghou idnot be used in designing.

- As content coupling is worst OT® 0

Scanned by CamScanner
 ate ggWare
Engineering (MU - Sem. 6 • Comp) 4-14
( v ) External coupling

components of system share an externally imposed d

ice interface then they are said to be externally coupled.
rnal coupling refers to communication between system components and external t<>ni o
13
devices. Or
v
( 0 Message coupling

otiDliri <y
communicnM with
uu each ° CCUrS betwccn two
components
other via message passing. of system when those compo n e n t15

, .. & opponents are independent of each other; thus it is low type coupling.
tvii) Stamp coupling

tW com
arguments usincr Q ° P° nents of system when data between them are passed by
s p ig elements which may or may not be used.
"“
4.6.2 Advsntr fTo

w
■ • X'"'; “"“'‘— •nents.
" . d_
M With low coupling a m „ n „
g among components, system can bui
4-6.3 advantages of Coupling faster.

w nt3gos „ Hw Cohesion ana Low Crao||ns

(MU - Dec. 17)

---------------
befits of high cohes ££ j 7 , 4 Marks

6 a 8mgle m
Reusability ; Classes that hav °dule.
have
fictions. ~trated functional
les not polluted
Benefits of low coupling
with useless

S1
- .■ W* J, " '

' •• c ->» «« « <.

Scanned by CamScanner
 A1U . ~

BlH QSesbetw
to
CoJ

parameter on
o„ Softwaro Desii
Sing.
ncept Col> C
°h ou
esioi l
catei
12 ' °«shi
presents Coh
esion te . , uuph
nK i n d .
j th o f a I! sent8 u r nct
i ntwo,
pegree ’onni
Itisade L
*n r' '-
modules.
h
y jligh or Low 11 is
a degree t
therrno
22 design.
Low Cftlinl: _

4.8 Architectural Design

------Exp'ain architectural .
sec. 4.8)
- Requirements of the softwar
[10 Marks]

80 architecture that describes the

- xz
ec
which software can be developed tural design which acts as an initial ’blueprint' from

components and their interfaces

system. This framework 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 :

1. Structural model : Demonstrate architecture as an ordered collection of program

components.

2. Dynamic model : This model illustrates the behavioural aspect of the software architecture

. ib a rhanee in the external environment.

d h
3* Process d
model .i •. m.
inis muu '* ” ”"
Which must be implemented m t hierarchy of * system.

Fume

Scanned by CamScanner
 —j varB-Enqinperinq (MU - Som. 6 - Comp)

5. Framework model : This model ties to recognize repeatable archi ®-ign Patt
which are found in same types of applications. This will results in in in the leve y
abstraction.
4.8.7 Functions of Architectural Design

1* It describe an abstraction level at which the designers can state the functional and perform
behavior of the system.
2. It estimates all top-level designs.
• It acts as a guideline for improving the system by illustrating those features of the system
can be changed easily while maintaining the system integrity.
4. It dev elops and documents top-level design for the external and internal interfaces.
5. It develops initial versions of user documentation.

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.
e software models consist of static model, interface model, relationship model, and dynamic
process model which illustrates how the system is arranged into a process during run-time
tectaral design document provides the developers a solution to the problem defined in the
6
Software Requirements Specification (SRS).
In addition to ADD, other outputs of the architectural design are given below :
I. A range of reports including audit report, progress report, and configuration status accounts
* C UUL -
La
2. Different plans for detailed design phase, which consist of following: '
(i) Software verification and validation plan,
(u) Software configuration management plan,
. (in) Software quality assurance plan,
(iv) Software project management plan.

4.8,3 Architectural Style

(MU -Dec. 15)

Architectural styles describe a set of systems whi h • Dec. 15. 10 Marks

mternaU
share structural and semantic properties. ' y ed with each other and

Scanned by CamScanner
( Software Engineerin,
!KMu
In short, the pu
6
P«sent in a s ™ * usi

basic c hanges in th ‘ Ur6 U to b Software Desian

By applying cert ' of

hi s .etione ural

We
A eom P ute r . based - apow , Wo
dUfc
available architect ® are is ”“** "“ •
8 es Part of
Every architect,
arC1Ute ‘ this
11,8
etural s ty] e lcni )
Ues a 'rotC3 one of the several
Computational We™ fv
P
system functi 0n ” nen ‘s di following;
d databaSe
2. A collection of connector, m. “ *° eMcut<! 11,0 ret
l“i ' e d
Pr
to Offers communicatio ° cedur e call e
databa P
3. Constraints to describe « X. " " rt0C °1S ' ““

A -antie model, wbich " — to form a 8ystcm .

regarding the system as a wbole hy' “> - to recognize the characteristics
Studyine thfi
Following are the common archite

Architectural styles

1 • Data-flow architecture,

2. Object oriented architecture, J)

3. Layered system architecture, Jj

4. Data-centered architecture, |

5. Call and return architecture.

Fig. 4.8.1 : Architectural styles

Data-flow Architecture

The purpose of data-flow architecture is to accept some inputs and transforms it into the required
outputs bv applying a sequence of transformations.

filter transforms the data and sends this transformed data to other
Each component called as of conne ctor called as pipe.

filters for additional entityj it is not focused on the filter which is

Every filter operates as an

generating or consuming the da . received one end to the other end .

A pipe is a unidirectional delivers the data to the filter on the receiver end.

It docs not change the data m anr

Scanned by CamScanner
 Iittor

f innf
f iltof

f llfnr

(n) Plpoti nnd filter®

Filtor )-»f Hltor

(b) Batch soquontlfll

Fig. 4.8.2 : Data flow architecture

In this system, a batch of data is accepted as input and then a sequence of sequential f u
applied to transform this data.
Example of this architecture is UNIX shell programs.
In these programs, UNIX processes act as
filters and the file system by which UNIX
communicates act as pipes. Process

Advantages of data-flow architecture

1- ft supports maintainability, reusability and modifiability

2- Concurrent execution is supported by this style.

advantages of data-flow architecture

atch se
fiuential system.
2
’ The application which
3
- It is not easy to coordir

Object-oriented

- “■ *• ■” te " d
-“ “ d
”m “ - * -
•key communicate with each other

Scanned by CamScanner
 rgsoflwgroEnnin
Mj. Cm
/Idvantagos O f MO
1- , t n " OW-10 BlBn( "'” ,, ' O ' ' « r ch „ <ic
U r
2. Tho im P ie divid(J °
affecting o th * tion deu •. Pr ° b, eiu
Software Do,i,

arc
hitect.
,nn
K*l without
nnothei

Vl
’ ,Wh Pon meWTO

■ j n layer
~ a°ng ~

Proce
ea
'Sgggo - Jysical layer

2§r r

wcn 18 flayer which i8]

' " Seated below it.
as a client to the

[S that des
cnbe a set of rules to be

8 3
International OrganizationtsZ on XX

Data-centered Architecture
A data-centered architecture has two unique components:

Centra] 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
ch’ent software performs various operations such as add, delete, update, etc. on the data which is
stored in the data store.

Sometimes the data store permits the client software to access the data independent of any
changes or the actions of other client softwar

Scanned by CamScanner
 Softwaro Enpinoorinn (MU • Som. 6 ■ Com 4-20
to clients can be added » 4
In this architectural stylo, now componcn change i n other clients.
components can be changed easily which docs no *1

Additionally, the information can

components.

2. Clients work independent of each other.

3. Addinc new i

easy.

B- R
'ard.

Client software
Client software
Client softwan

4.9
I Data store
Client software
1 (Repository Client software
P x bjackboa rd)_

i Client software
Client software

Fig. 4.8.4 : Data-centered architecture

5.
Jture

h,teCtUre aU WS J
n«2XlsZr ° ■ get such a program structure where
This architecture sty
8rouowin
A- Mainprogram/subnro™ "" & two sub-styles.
” architecture

e main program contains and

other components.
components may in turn execute

Scanned by CamScanner
 Controii
sy®iiwr A PronrA
Pplic atfon

orum
P<icatlon
Jbproq farn

Fi A
8. 4,8.5 : M
a n pro
Pplicar«Gn
Remote procedure ca n ' er W SUhn
S bl,r
d. r th . rt ““ teeture " ™
In this style, con>poaents
main
network across number nf Prom-am
Outers which can b ” architecture are distributed over a
e ss e d
remotely.
Syllabi

Component - Level Dgsi gn

Q. 4.9.1 Write note

~~ 222£21Jeye[design ,
The main VV1UU OI comp [10 Marks;
<e ne s ruc
characteristics as well as communicati hires, algorithms, interface
meC an Sms or
which are identified in the phase of h*t he present software components

, . P component level design is expected when the data, architectural, and interface
designs are completed.

represented Dy the component-level design in such a manner which lets the

designer 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.

Design walkthroughs are carried out to observe accuracy of the data transformation or control
transformation which has been allocated to all of the components in the earlier design steps.

Component Definitions

- As per object-oriented view a comp° * res y e s in the software and serves one of three.

- As per traditional view, a compon

roles as follows .*

Scanned by CamScanner
 4-22
Software Engineering (MU ■ Scm. 6 - Comp|
,tnpo
"ent,
'’“‘Otoe,
o Problem domain components implement
the functionnlity required t0
o Infrastructure components implement
processing needed in a domain application. |
- Process-Related view focus on building systems out of existing components which
f n a catalog ofreusab.o components as a way of populating the nrch.tecturo, J
Object-Oriented Component Design
- Put emphasis on describing the domain oriented analysis classes as well as the defi
infrastructure classes. "S,
- Comprehensive information of class attributes, operations, and interfaces is neceg 3 a
beginning construction activities. ’

Principles for Designing Class-based Components

- Liskov Substitution Principle (LSP) : It should be possible to substitute subclasses for the’
classes.
Dependency Inversion Principle (DIP) : Depend on abstractions, do not depend on concretions
Interface Segregation Principle (ISP) : Multiple client oriented interfaces are considered u
53
compared to one general purpose interface.

Release Reuse Equivalency Principle (REP) : The granule of reuse is the granule of release
Common Closure Principle (CCP) : Classes that change together belong together

; m
SZ *“* ■a — ■“ " - not b .

Component-Level Design Guidelines

!• Components

Establish naming conventions

ames of Architectural in theshould
components phase be
of architectural
meaningful f modeling.
th r. '•
f r the stakehol
- Names of Infrastructure ° ders.

Interfaces

ompared to formal UML box and arrow

For the purpose of consistency, ft
component box. UlterfaCes should
be from the left-hahd eide rfU»
Display only those interfaces which

Scanned by CamScanner
 4
S?
*st- Softwanj fc

Su Depende ncJes
o
To
" Pro v
inh
'Ht«ne of _7«i tyil

%
ndo,1
Cohesion ci P8 I (Parp
c
°n)i’ ’ Mc| mftd * , , U >n l
ri n, m tol
”"" ‘ In h, **’- '‘' ''” ‘- 'Wn <M
»C ~“‘“y co .
***«. ,,,.
“•« „
-
POn, nh
- Z
Kocedu ‘ ■ 0Opcr 0lions
'“"’ In .
the n
pr»e edin ° C 0ni p 'onied „ul 10 r " -» e.t.
«» °ne Wa °nent 8 a m eflCct n ” r ’»
Com
- nicationai e«ned l„ 0 “ »«h., iOT „
Se As ,: tpM
' 1 nt ia l Co . ‘°' Opor ati „ °" ’inB d al “ P t “ ' el
one be called ’
*s e
™ . c,... ■-

e
tej

Data COU
P1 .■ .
ta
componeats. ke s place

g 0 arguments
Stamp coupling - Th- are passed between
‘ K...„

p
S • This coupling takp« rd
a
component to another. “ ““ «« Aagu are pa8scd „ by om

w s
with any 7 of the infrastmcfeX Xe 7 “ ““““ " '“

11 8 P aCe a global variable is used

component " **“ ' hy multiple

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.

type use coupling : This coupling takes place when a data type defined in one component is used

by another component.

Inchtsion or import coupling : IMs coupling takes place when one component imports a package
or uses the content of another component.

Scanned by CamScanner
 4-24
-Software Engineering (MU - Sem._6_ ££23
!gl (MVJ .

Program De.,igri >

K
1. Identify nil of the respective design cJn- - re co details.

2. Identify nil ef the respective design clas. , reusable components. program Dn gn Language
. . I, nrf! not acquired as
3. Elaborate all of the design classes w ’ "g collaboration of classes or
' Predetermine 8yaU
a. Specify details regarding the message w
b. Identify suitable interfaces for all the componen which are nece - Free syntax of natui
c. Elaborate attributes and define data types an jt - Data declaration f a
implementation. - Subprogram defiir
d. Describe processing flow of all the operations th S Design Notation Asaes
4. Make the Identification of persistent data sources such as databases an and reCOgni
- Modularity ; Het
classes which are necessary to manage them.
- Overall simplid
5. Develop and elaborate behavioral representations for all the classes or components.
- Ease of editing-
6. Elaborate deployment diagrams for the purpose of providing additional implementation detail,
— Machine reada
Factor all of the component-level diagram representations and consider a " es.
— Maintainabili
Object Constraint Language (OCL) procedural de
- Complements UML by permitting a developer to use formal grammar as well as syntax f Or — Structure enj
purpose of constructing unambiguous statements regarding design model element. — Automatic p
~ Parts of OCL language statements : — Datarepres
1. A context which indicates the restricted situation in which the statement is considered as y . Logic verifi
valid.
— Easily con
2. A property which represents few characteristics of the context.
3. An operation which manipulates or qualifies a property.
Keywords which are used for the purpose of specifying conditional expressions.
4.10 User Into

Q. 4.10.1
Each block of code has a single exit at the bottom.
Q. 4.10.2
Only three control structures are required : sequence, condition (if-then-else), and repetition
(looping). User
- Reduces program complexity by enhancing readability, testability, and maintainability. tons
Use
Design Notation
int(
Flowcharts : Arrows for flow of control, diamonds for decisions, rectangles for processes.
No
Decision table : Subsets of system conditions and actions are associated with each other to define te<
the rules for processing inputs and events. U
s
I

Scanned by CamScanner
 programDesien
- a g e (PDLr S t r
details. ' • ucti

- Predetermined 8yntax

- F ree SJ®*®1 of
natural language for definilion8
'
- Data declaration facilities for sim ] se of describing processing features.
coniplex
_ Subprogram definition as wii . data structures.
asmvocat
..... . ion facilities.

- Modularity. Notation provide su

F eVe Opment m
_ Overall simplicity : Easy to 1 °dular software.
arn> eas
r r j-h y to use, easy to write
- Ease of editing-. Easy to make chan •
m dGSlgn repreSentation whenever
- Machine readability : Notation required.
TOmputer
- Maintainability ; Maintenance * ' based development system.
C n gura on
procedural design representation. ' ° general engage maintenance of the

- Datarepresen tation : AbiUty to represent local as weU as global data directly.

- Ugic verification : Automatic logic verification improves testing competence.

Easily converted to program source code (makes code generation quicker).

4.10 User Interface Design

Q. 4.1 0.1 What is user Interface design process ? (Ref. sec. 4.1 0)
Dec. 16. 10 Marks
(1 4.10,2 Writo short note on User Interface Design. (Ref, sec. 4.10)
May 18. 10 Marks
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 software 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 mannpr 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.

Scanned by CamScanner
 So areEnglneedng (MU - Sen.. 6 - Comp)------------. --------7 Meo based. It is usually depen T
- The form of UI can be graphical, text-based, audio- p
underlying platform (hardware and software com in
~ The popularity of software depends.upon following P
o Attractive
o Simple to use
o Responsive in short time
o Clear to understand
o Consistent on all interfacing screens
UI is 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 communication with computers in previous days.
- Now-a-days also CLI is the first choice of number of technical users as well as programmers.
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 instruct!
0118
and feeds to the system.
Here there is need for the user to remember the syntax of command and its use. In previous d
CLI were not programmed to handle the user errors effectively.
A command is considered as a text-based reference to set of instructions, which should k.
executed by the respective system.
There are several methods such as macros, scripts which make it simple for the user to operate.

° f C° mputer resource
“ b
y ‘be CLI in comparison with GUI.
CLI Elements wait *»
total Uffl
7
Staff »4 Jul 2 29D .
staff <K Oct 24
1 Wai staff 15244 JUi
1 Wai staff 54*42 Jal
1 W*1 staff 134215 Jal
i Wai staff 25?5J5 Jal 2
i wa« »i*t£ 15912U Jal 2
1 <W»1 •vatf U 3 K K Jal
1 W*i staff 44MS Jal 2
1 Wsl staff 12)241 Jal 2
1 Wai staff K12 Wr-sl.ju
Jal 2 2viJ
i wai staff WO3 Jal 2
1
Wilt Jal 2 Mr i
1 staff * *-**Pi‘j*r
1 Wai 2
staff W Jal 2
2 s*** f * * J » fOMtf staff J i ? tc' ‘ rcts ar
1 W*1 •taf* «=*---*fr=Ma
1 W*i staff 4 I < » Jal 2
staff lcrc
1 W*1 2 ,2. s'-aie a - f r
124904 Joi
• wa* 2)2J1 JaJ 2 :::?
Uneat-mu.jax

Command Prompt

Scanned by CamScanner
 I .tfenltwaroEnfllneorin
I r T here are fon owill

ie
Cursor : It i s tc
°‘ gen ' Oo
«fier
—
,n
cc . Software Design

b
represent posi tion »r>zonlal ’ "* "Hally <«,,
har U>0 context where the uaer
moves when User acter nt »r „
8 r del
Command : a Con ° ” til ’10 of typin'”' ,har W| U< the hel n.
"te 3 , e5C
Hnana 18
• t- Cursor U Uno. It is used to
parameters to it. Out nothin,, b u t >» bhnWng « . n
command prompt is set ‘ U? 1. instm
to the d,ap|
. , , ,, next 1J 0V0d inlinn ™ ’thw « »>e one lir mme
raphlcal User l nterface the screen.. After displaying output.
4.
Graphical User Interfa
can be combination o f W h T 8taPhical ®ean s to (K
ha U8e for
software. rdware and interacting with the system. GUI
Using GUI, user is able to interpret the
In general GUI is considered
latest advanced technology, the projJX'" 11'06 as compared to CLI. With the help ot
esigns w ch perform with better ffi • mers designers' are able to create complex GUI

“er effictency, accuracy and speed.

4.10.2(A) GUI Elements

or
e purpose of interacting with software or hardware.
AU of these graphical components give ways to interact with the system.
Following are some important elements of GUI :

*• ' - l T C

rAvo*nts

QOirtw
OocuH'frti. AWCkwww
Q O9*ftkMMft
( J MuW**

0 ftctyrei AutOWMW
Cifa/4«K

Status-

tents of application are displayed-

a
. .Itistheare in w b i c h C ° n displayed in the fa
o Window:w It ps , h e Window contents can be

To represent file struct .g very easy for user.

Scanned by CamScanner
 f*W
4-28
Window preride fadlity to resize or maximize. It is possible
° n the screen. A window may contain another window (child window) of the 8amQ JX
inside it
Tab
° s •• *"ben an application executes more than one instances of itself, then tho .
appear on the screen as separate windows.

same window.
■M ay ,

° Menu : Menu is considered as an array of standard commands, combined tog ,

located at a prominent place (mostly top) inside the application window. It ig a]3o posa’k * I
prog tom the menu to appear or hide on mouse clicks. 1
Icon :
° Aa ’con is small picture which is used to represent an application. These
clicked or double clicked to open the application window.

° Cursor : In GUI cursors are used to represent interacting devices like mouse tonrk
digital pen, etc.
In almost real-time, the instructions given by hardware! are followed by the cursor. Cursors
are also called as pointers are used to select menus, windows and other application features

UI of an application contains following elements .*

Application Window : Most of the application windows use the constructs provided b
underlying OS but some have their own customized windows to contain the contents I
c
application.
Dialogue Box : Dialog box is a child window which has message for the user and request for
some action to be taken. For Example: A dialog box is displayed by an application to get
confirmation 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 selection. Only

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 single control. Multiple items can be selected.

4.10.2(C) User Interface Design Activities

Several activities are carried out for designing user interface. The process of GUI design and
implementation is same as of the SDLC (Software Development Life Cycle)

For GUI implementation there are number of models available such as Waterfall, Iterative or
Spiral Model.

Scanned by CamScanner
 Follow
8te
develop ment Ps shXX*"*' ------------- Software Design
bc
filled by th
e model used for GUI design and

GUI \
®quirenient
Specifications .. orGUI
Us
Analysis

' GUI
Testing
GUI
Task Analysis

GUI
Design and

quirement Gathering : The designers need the list of list of all functional as well as
non functional requirements regarding GUI. These requirements are accepted from users and
their existing software solution.

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
knowledge as well as competency level of the end user.

If user looks to be techno savvy then advanced and complex GUI can be developed.

■- For a new user, more informative data is included regarding how-to of software.

o Task Analysis : Designers have an important responsibility to analyze the task which is to
be done by the respective software solution.

. a„ «. .rm, » B w
hierarchical manner consrdenng one m j

sub-tasks.
Rare provided by the tasks.
- For GUI presentation, go teis decided by the flow ofinfomation among sub-tasks.

o cm o. »- w ,e ””7X»— ■ *■* “

Scanned by CamScanner
 an>Eng Jneenng(MU -Sem 6 >Comp) 4-30 rttware

•fesign i„ to togmto the GOT with currently working or any dummy aoftw 7

Testing- • There are several ways

4.10.2(D) GUI 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.

The code is modified by the designers for software customization.-

There are diverse segments of GUI tools in accordance with their use and platform.

Example

Following are some tools which are used to build GUI :

FLUID

Applnventor (Android)
o LucidChart

Wavemaker

Visual Studio

4.10.2(E) User Interface Golden Rules

+ (MU - M a y 15)
are the features of good user interface? (Ref. sec: 4.10)
M a y 15. 5 Marks
R;4.1ft4- Explain user interface goldan rules. (Ref, sea 4 jQ) ■ '

M
■ zr

Scanned by CamScanner
 MU - S o m . 6 - Comp) 4-31
Engineering

User Interface golden rules

1. Strive for Consistency

feedback

3. Match between system and the real world or |

Design dialog to yield closure 1

5. Error Prevention and Simple Error Hand g|

Recognition rather than recall

_J 7. Enable frequent users to use shortcuts

i, and
recover from errors

10. Help and documentation

Strive for Consistency ons me an the same

thing. Do not confiise your user keep words and actions

Use “The Principle of Least Surprise .

Example: Car Climate Control

insistently. For example a certain style

- In other words, use all elemei
of button should always do tl
in hierarchy.
Consistency of :

o Workflow /Processes
o Functionality

Scanned by CamScanner
 4-32

Appearance
Terminology

i ohml t what is going on. Through apDr

The system should always keep users informe UfJer w h a t ’a hap peni / •t*
feedback in a reasonable time. Don’t keep the users guc g,
Example : OS Installation status *

El Capitan

Design
About 25 seconds remaining

The user wants to be in control, and trust that the system behaves as expected. It could be even

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
(use words, phrases and concepts familiar to the user), rather than special system terms.

- Example : Payment proceeding (by Ramakrishna)

Scanned by CamScanner
 lu

- Explicit completion of an action.

- Well-defined options for the next step.

4. User control and freedom or Permit easy reversal of actions

- Shneiderman puts it nicely “This feature relieves anxiety, since the user knows that errors can be
undone; it thus encourages exploration of unfamiliar options ”

Example : Document History

historyor njcirr
0
H

Scanned by CamScanner
 Software Engineering (MU - Som. 6 - Comj ... Clearly mark an
ldredo functionality.
to go through an ex

— Reversal of actions
o No interference with workflow
o More freedom for the user
o Single-action undo and action history

Error Prevention an d Simple Error Handling

Users hate errors, and even more so hate the feclii mb
wrong. Either eliminate error-prone conditions or
before they commit io the action.
Example : Password Enter

Your password must have: Redu

G 8 o r more characters
© Upper & lowercase letters
O At. least one n u m b e r

Strengthrstrong
.... r, nr., r r ,

Avoid passwords that are easy to guess or used with

other websites.

If an error is made, the system should be able to detect the error and offer a simnl.
comprehensive mechanism for handling the error. ' *
Error Prevention

Error prevention over error correction

Automatic detection of errors

- Clear error notifications

6. Reduce short-term memory load or

W
. N ., rather than recaU
As Nielsen says, recognizing something is easier th

~y load by making objects, actions, and options

- The user should not have to remember inform, f '
Instructions should be visible. “Nation fro
- Example : Ring/Silent switch

Scanned by CamScanner
 Soi

S
°O1
b
°ut

U
- “ iconography
to help the returuin al ain
ngUs
era G n Hd 4K S 8 U c h a s t } 1 d col
fteduce memory l Oad ftinctionn r +. <*in
uu
aiities. acerr.ent of items
w 8tr
uctur e
“Recognition over™,
recall’

- Visual aids

4 7. Enable frequent users

8ers
t
t o u Seshortcuts
- ’"“"'to tailor (manipulates .
PerS
- Abbreviations, Junction keys Wdd ° Dali2e) fre< u
J “‘ actions. .

• “ "■» „. lpw „ „
- Example, Click Commands and Shortcuts

i New Window • SN

New Tab «T
. Open File... 380
Open Location.. 38L

Shortcuts

Keyboard shortcuts

“Power User” features

Action automation

Scanned by CamScanner
 4-36

Minimalist doesn’t mean limited. AU information should be valuable and relevant.

Example : Simple Interface.

Module 5

Syttasus

pts.k kjertfeatc
SOM process.

PPort user Risk M

tasks,
9- Hein u
errors
Error messages should be expressed in plain language (don’t use system language to describe
w t the system is doing), precisely indicate the problem, and constructively suggest a solution *" Q. 5.1.1

Q. 5,1.2

Q. 5,1.3
Message text No title

■ ■ J. . ,x \..' Q . 5.1.4
Secure Empty Thish permanently erase*
i r- th* Hems In the Trash. Are you sure you Q . 5.1.5
App ,con W3nt
to permanently erase them? ■ R
Informative text ______________-
;
TfMh
- >xw
‘ a*”’* er! * 5$ Y«vV« backed them up using Tsne
re
I
Kwhki# or Another backup t o the
j Cancel delays

iJJI"
bw
■ -* “« “ - «■• '■-« — «...
10. Help and documentation

h
” “ » -W - «
Any help information should be easy to search, focused
and not too large.

Chapter Ends...

□□□
Scanned by CamScanner
 5 Softyy

Module 5 uality Assurance

Risk Identification, Risk A

SCM process, Software Quaiih, a ’ Section, Rmmm SnfK> ,o -
(FTP), Walkthrough. France Task and P| a n Met ■ ° nfl9uration management, SCM reposrtories,
ncs. Software Reliability, Formal Technical Review

Risk Management

Q. 5.1.1 (MU - May 15, Dec. 15, Dec. 16, May 18)
r (Het. sec. 5.1)
Q. 5.1.2 May 15. 2 Marks
scuss
ihe different categories of risks. (Ret sec. 5.1) Dec. 15. 5 Marks
Q. 5.1.3 Explain different steps in risk management with sultabk
iram.
(Ref. sec. 5.1)
Dec. 15. 5 Marks
0. 5.1.4
Dec. 16. 1 0 Marks
Q. 5.1.5 Explain Risk and its types. (Ref, sec. 5.1)
May 18, 5 Marks
Risk is the possibility of suffering loss. In the project development, the loss illustrates the impact

delayed completion, or failure.

Schedule
risks

Operational Budget
risks risks

Categories of
risks In software
projects

Other
Technical unavailable
risks risks

Fig. 5.1.1 : Kinds of risks

Scanned by CamScanner
 52 Risk. Configuration Mgmt & Qua.ity
Qsof areEnqineoring(MU Se 6j_Comp)_ -----“*TTZZntare as follows :

Various Kinds of Risks Associated with Software FtQj

Schedule / Time-Related / Delivery Related Planning egS ential time-related risks,
These risks are related to running behind schedule an

Some of the reasons for such risks are : schedule.

- Incorrect Time Estimation, and consequently an i
— Improper Resource Allocation.
— Underutilization of Resources.
— Superficial Understanding of Project Complexities.
- Unexpected Expansion of Project Scope.
- Incorrect time estimation may occnr because activities may have external dependencies such
client approvals, subcontractors etc. and a delay in a critical path activity as a cascading
on the entire project.
— Resource Allocation may be improper / underutilization of resources may take place, especially if
resources are shared between projects.
— A silo approach of members in various teams in a project may lead to an isolated superficial
understanding of project complexities which may result in delays in subsequent stages e.g. when
different development teams work on various aspects of a software project and run into issues
during system/integration testing. ■.
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. ■

Expansion of Project Scope.

Improper Tracking of Finances.

n
° f XT
b a“hecit becomes
Because
eSPeCia
" y haPPe “ S
difficult to effprtivolv
WW reS
. ° Ur “ 3
shared H
between projects
resources a
productivity may go waste. & “d certain amount of

lead to ’budge; overZ"T *”* '' ““ °f may

Ot ha
estimates. “ - factored into the original
Delay of projects may also have certain penalty costs
projects. associated with them e.g. construction

Operational / Procedural Risks

These are risks which are associated

with the day-to-day operational
activities of the project.

Scanned by CamScanner
 Software Engineering ( Mu .

These could bo due .u

any of fl i £3 *
. imprope,, p rcns „n a ;
cn)
. Silo approach follo 'Uion.
? n
Conflicting ™ ro devd ,
nt
LnCkOfC0O
•'»"» „„ nicu
fli c t Solution,
Lack parity h. -Plrit.

ninconim,
rLackk ofr sufficient “ i - i-
training

Effective team comxnunic . n 18 .

projects such as softw ** essential j
is a
a setup for escalation, a conn- J ’ strong neerf J- ------- and in j>
Ct resoIuti estab,ishctl
employees need to be tr»* on pr0cp „o communic«
in making use 0Pf t SS ' CStabl -hcd p prioritiM and
Prcccsse3 with the
rochnical / Functional / Performance »• “ organization.
4. ,,ce
Hisks
These are technical risks assort.,..,
software performance. ie
or with respect to the
In order to compensate for e
ov
sometimes reduce the functionality f th erruns and schedule overruns, companies

Software testing is a downstr

so wai
falls behind schedule downstr ‘e development lifecycle and as the project
dateS
’hich results in insufficient softXeXtffig a'""’

response tune by mmumzing and eliminating unnecessary add-ons from the software).

In order to maintain the purity of the software development process, while simultaneously
catering to the customers’ needs, a mutually agreed-upon cut-off date should be determined, beyond
which “expected software functionality” would be frozen and any further 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 a rival company,

o Loss of contracts due to changes at customers end.

Scanned by CamScanner
 n - k coo nuration Mgnrt a Quality
n .4 softwam R'sk - conT!qu
.Software Engineering (MU . Sem. 6 - Corn
with processes, methods, and torji.
Risk Management is a software engine
managing risks in a project. It provides a

Determine what risks are important to deal with (risk prioritize ion
o Implement strategies to deal with those risks (risk rcso
QS
Risk Analysis is series of procedures such risk m

Risk Assessment
Risk Identification
Risk Containment

Syllabus Topic : Risk Assessment

5.2 Risk Assessment ______________ _______________e ______

Q. 5.2.1 Describe the following with respect to Risk assessment :

(i) Risk identification (fi) Risk analysis (Ref. sec. 5.2) (5 Marks)

In Risk Assessment, mainly following elements are there :

Risk Assessment

(A) Risk identification

(B) Risk analysis

(C) Risk prioritization

Fig, 5.2.1 : Risk assessment

(A) Risk Identification

Produces lists of the project-specific risk items likely to compromise project's success.
(B) Risk Analysis

Assesses the loss probability and loss magnitude for each identified item, 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
 gftwareEngineg ,..
too]
,5*5
'e ■—
R,sk ,den !!2!l<)urnilon Mgmt ft Quality Assurance
.1 tfflcat | O n
Q. 5.2.2

It JS a process of s t n f .
ma (5 MafUa) |
risks -v occur «h •
problems faced by p ° «•"» project ra """
PTOjcc
Study the project D > Propcr,
‘* "y be
'“W.
the other type of risks X and ■-
0
possible areas that arc vulnerable to some or
The best way of Qna|
B pr
essential areas. “ °joct plan i s by
converting it to a flowchart and examines all
It is important to conduct few
W u
bra .
can affect the nmmnt.
jec
instormin£»
* sions to identify the known and unknowns that
Any decision taken related to ted •
factors should be evaluated property ° Perati ° nal - political
. legal, social, internal or external

8 ment We
identification. have to define processes that are important for risk

Current project

Assess the
Review the past Come up with
practices that.are
project history ■ being followed in creative Ideas tor
the present project future projects .

Fig. 5.2.2 : Risk identification

All the details of the risk such as unique Id, date on which it was identified, description and so on
should be clearly mentioned.
There are in general two types of risks : generic risks and product-specific risks.
Generic risks are considered as a potential threat to each and every software project.
Product-specific risks can be identified only by those who are having a clear understanding
regarding the technology, the people, and the particular environment in which software is to
be built.

For identification of product-specific risks, there is need to examine the project plan and the
software statement of scope, and an answer to the given question should be found out: “Wch
particular characteristics of the respective product may threaten the associated project plan.
•a i« tn senerate a risk item checklist. This list helps in nsk

- — - — - - “•*

or
O Product size : Risks related to the
customized.

Scanned by CamScanner
 5 ,„ RB*. ConUguratlon Mgmt & Oo aWy *.»„.
Software Engineering (MU - Scm. 6 • Comp) — ——
o Business impact : Risks related to constraints wh
the marketplace. jca tion of the i
■1

i - minted to the availability as well as quality of

Development environment : Risks rela

Technology to be built : Hit

o Staff size and experience : Risks related to the overall technical as well as
experience of the associated software engineers.
- There are different ways available to organize the risk item checklist.
- Questions which are relevant to all the respective topics can be answered for each and every
software project.
The answers to these questions help to calculate the impact of risk.

5.2.2 Risk Analysis

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.

priority 0 rt* the ma

“ aSerS to decrease the
’“certainty level and focuses on risks which have high

manageme t 38 P ssible the

' faltl cosT time,
like cost, r “ and procurement.
scope, quality “ ° “ P et. It can impact on different
The inputs of qualitative risk analysis involves :
o Risk manap’pmpnf' ninn
o Scope baseline
o Risk register
Enterprise environmental factors
o Organizational process assets

o The output of this stage would be

o Project document updated

Scanned by CamScanner
 ftvvare Engineering

„ It IS the process of
n,br
purpose. ' rn icnl|v f Qualify A-.nitnrrn
V nn,
. *I
To minimize imp ninR ,h
* <im
fT
»r»»ct of

Ri8kman >T r U r h j ,
° ‘» PIttn
Cost
o “«n« SCrePntplnn

SChCdU
° ' O,na " '-nt plnn
o Risk register

Enterprise environment
pro CCS8 a ssets
o And output will be
o Project documents updates

$3 Risk Containment

□.5.3 J What is Risk co.

(5 Marts)

•_ fk • track of noticed risks, finding new risks, mcnitcring

The inputs for this phase are :

1. Project management plan
2. Risk register
3. Work performance data
4. Work performance reports
The output for this phase are :
Work performance information
2. Change requests
3. Project management plan updates

4. Project documents updates

cess assets updates
5.
Risk ProMon

(5 Marks)

Scanned by CamScanner
 R k configuration Mgmt & Quality As .
5 soffw»vt ]
3P9 Engineering (MU - Sorn. 6 mpta to rate each risk :
(or
There are two ways by which Risk pn** <'f‘h n ’ a t l ° n )

• with the risk, anou.o -------

o The consequence of the problems projection atepa.
The project planner, managers, and technical staff per prioritiznt ion.
The intent of these steps is to consider risks in a m«nnte r
lKn c
Be prioritizing risks, the software team can a *
most impact.

Risk Projection/Estimation Steps

1) Establish a scale that reflects the perceived likelihood of n nsk (e.g., 1- low, 10 high).
2) Delineate the consequences of the risk.
3) Estimate the impact of the risk on the project and product.
4) Note the overall accuracy of the risk projection so that there will be no misunderstandings.

Contents of a Risk Table

- A risk 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.
o Impact : (1) catastrophic (2) critical (3) marginal (4) negligible.
o RMMM : Pointer to a paragraph in the Risk Mitigation, Monitoring, and Management Plan.

Risk Summary Risk Category Probability Impact (1-4) RMMM

Developing a Risk Table

List all risks in the first column (by the help of the risk item
each risk. checklists). Mark the category of

Estimate the probability of each risk occurring.

’Assess the impact of each risk based on an averamno- „r r •.
P g f the four nsk
overall impact value. components to determine an
Sort the rows by probability and impact in descending order.
Draw a horizontal cutoff line in the table that indicates the •v v
ke nsks
attention. • that will be given further

Scanned by CamScanner
 A s S esslng Risk lm Pact
5- 9
jSpftW;
,e conse >nfi(
quc n <- —rat '2 n Mgmt & Quality Assurance

Itss hc
_ co Pe : T h i s c »rob lenis
(how much was s ty of UkcIy ifthorisk

timwg s <how
the

c
urren Ce fo
the cost to
C = the project
J e c t ck ,
should theri
k
sample dually occurs

? = P abiUtythat
Total
C = «ostof developingi8 . re
C mP nCnts is $25
RE = 0.80 x $25,000 = $20 000 ° ° .«00

(MU - May 15)

up orgener< (5 Marks)
The mam aim of all of the risk analysis related activities is to guide the project team in forming
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.

If proactive approach to risk is accepted by a software team, avoidance is considered as s

the best strategy.

This is accomplished by setting a plan for risk mitigation.

For example, consider that high staff turnover

history and management instinct, the likelihoc
percent, rather high) andthe impact „ r 0I1 projecl cos t and schedule.

It indicates that there will

. i can be devi
To mitigate this risk, a strat gy
Among the possible steps to be taken ■asons for
Communicate
to the project starts.
low pay, competitive jo
Mitigate these reasons

Scanned by CamScanner
 ‘1

>gwy> rn gln<w ,<np (MU , , Cpmp) fl . 1 0 flpftww HI.K, Conf lfl ur»tton Mfl mt A Quatity
f->/ftv
° After rommenrrmrnt of project, assume thorn will be occurrence of turnover and lr riaka
<s
IcthniqurN to tnJco cere of continuity when peoplo Jenvc.
Mo-et
° °nrnni«o project trams to widely dieperao the Informntion regarding each *l<wc|Opjn and '
activity.
° Define work product standards and set system to assure that all the respective model* Aft*?
documents nro developed in expecteil time duration. step
AI,ncntti Rial
° n backup staff for all the critical technologists.
Hie factors are monitored by the project manager which may give a aignnl of whether th Rial

(1)
1
tho case when there is high staff turnover, tho common attitude of team members dep (2)
upon project pressures, communication among team members, potential problems v . l
h
compensation as well as benefits.
Si cs monitoring these factors, a project manager has also responsibility to monitor i t (3;
efficiency of risk mu;™*: _ _ _a _ _ .

Sot
products 81111113 8 1111(1 mechanisms t0 assure that there i8 no time
delay in
development of

to ttat each can stand on ita _ that each th — ™

newcomer were forced fn;n;r, +k„ _x.- ____ « . . . e S 3 entialif a
Risk management and contingency p Project.
efforts and that the risk is really occurred. ion

cution of is goiDg y
’~ 7"?7:x “
W<
documented,Z'Z“e .7 “

(and manage the pr

’ eWCOmers whose ° ject s
“
the team is necessary to “get up to speed » *“ introduction in

341011 m<>nitOring and

willdefmitelymcuradditionXrojertco ’ ’ management (RMMM) steps
5.5.1 The RMMM Plan

« to introduce a risk management

m 6 S vare
regarding the risk management can be planned intn ° Pro Ject plan, or steps
S separate Risk
Management Plan (RMMM). , Mitigation, Monitoring, and
The RMMM plan make documentation of all work carried *
3 Part
referred by the project manager as integral component 71 the overall“ project
ponent of ° f ™ k analysis and
plan

Scanned by CamScanner
 f Software EnginoP,r[n
IMU.Som 0 . Comp)
Software tcn n , o
Softwamnj , conf,
not "traiion Mqml A Quality Ansuranco
Prefer ( o
,y w i t
* h | * formal RMMM document. Instead, the
“” d '“try. priority 0*T
bn8
° RysU?t n is used n
l n r rrnnUon
° (RI8).
After docum entati( f.» searches,, tain the m3 Ro information generation
steps starts. »r hmmm „„d tlw "»» >» ™iiy.
s begun, risk mitigation ns well ns monitoring

RiSk Probl
i8 XX‘ ' m “ V ° i d "“ nCUV y
“ -
(1) To assess whoth(a . J " activity h o v i n ( , , b m , ;

(2) To make sure that risk

and are defined for the risk are applied correctly;
(3) To gather the

US Topic : Software Conflguration Management

Software Configuration Management ' '

Wrile
°~ SCM Wjben _____________________ (10 Marks)
Configuration Management (CM) is the process of identifying and defining the configuration
y em, controlling the release and change of these items throughout the system
lifecycle, recording and reporting the status of configuration items and change requests, and

Configuration Management is practiced in one form or another as part of any software

engineering project where several individuals or organizations have to coordinate their activities.
While the basic disciplines of Configuration Management are common to both hardware and
software engineering projects, there are some differences in emphasis due to the nature of
software products.
Software Configuration Management (SCM) is a system for managing the evolution of software
products, both during the initial stages of development and during all stages of maintenance.

A software product encompasses the complete set of computer programs, procedures, and
associated documentation and data designated for delivery to end user.

■ All supporting software used in aevmupuic ,

should also be controlled by SCM.
Benefits of Software Configuration Management
5.6.1
c nefits to all projects regardless ofsize, scope, and complexity.
SCM provides significant ben SCM disciplines

Some of the most common "Xstem.

described here are possible beca

Scanned by CamScanner
 ,. Tt
(MU Som 5 ., 2 so- - M*. confine Mgm.a o-w
th
Provides a snapshot of dynamically changing software to help :
E
° Make decisions based on an instantaneous view.
D
° determine status at modulo and system levels.
r<
° Make better decisions about the future of a software project.
Tracks concurrent development of modules or components of the overall system to : I
o Prevent different developers from making changes to the same module at the same time, 1
o Allow for the overall system progress to be faster,

° f o'ide visibility of the entire software project to all developers.

Organizes all concurrently developing code and associated documentation to :
o Save overall project time.
ocus each phase of the software product development to be organized and executed in a
documented, prescribed manner. .

5.6.2 SCM Disciplines

of y
documentation).
“““ -
68
Hnds of 'software ’rdeveZedT " ““ "
W ( g com era
manufacturer). " “ embedded, original equipment

deVel
■ The
j-ue use oi interartiva
use of int „ ----- j “Pment
, . J
rations, and maintenance) will also vary.

VeneSSOftheSCMsyStem
’ “ activities
- erphet part of the nonnal day-to-day - Proper
o f th vuciu ilh disciplines are
es
and maintenance efforts. of the software development
- 2 hn ihi scm

lhe Software Configuration Manaeem ----------- “•

Pr0Vides
requirements and procedures necessary for th "nation on the
so wa
re engineering project. configuration management activities of the

8 Planned
be performed, when the actinTfos be * ties, what activit’ will

Scanned by CamScanner
fgoftwaro Enginoorjng (MLH
Bom. g -
Comp]
Tho first step i n the 5-13
9y8lCm ia
the project progresses to identifv - -----
ent
Elements to be corn n ' >fy the structure of o'hC Conr,gurntion
ntermcdi to be controlled and, a3
ntrolled will norniallv • , * «‘« or complete software products.

u „ entS , COUld incl

ude Teouirr. ____ ' lhe
° R awnr
o <®de and associated documentation.
POcifications, designs, user guides, test suites, test
Baselines are defined and
lifeCyC, Crc
°-. ' >t' d aCC,,rt
“«> «nh th. SCM Han and the phase ot the prop's

Specifics configuration Hems

Configuration Identification of software items

Identification to be controlled

Baseline Configuration record at a point

in time
Definition

Control of change and libraries

Configuration
I Control
E
W
S Criteria and authority as defined in
No New. Configuration Management Plan
. Release?

Yes

Fig. 5.6.1 : High-Level View of Software Configuration Management

A baseline is a specification or product that has been formally revieweu uuu r

serves as the basis for further development, and can only be changed through form
control procedures.

A baseline is like a snapshot of the aggregate of software components as they

completed and accepted

to,h. .« — .to to— “ d *-■ nge, and is subject

. .......... - «*”■“ “» —”'

identification. Each of e
software development. establishe d during the life of a softwar.

The following are typical co S ur

project.

Scanned by CamScanner
 goj areEngin ringc
ApPen dix C p
or nppr0 val ol the software or disciplines.
BET Software Engineering (MU • Som. 6 -..Bstablished
Comp), by the acceptance complct ion of tho aoft
__ This list cai
Functional Baselm • . iiv corresponds complexity c
M
r
specification, This
i n is baseline typically
r i h o software requirements specify

SCM Repos
o Developmental Baseline : Batubfiobod documentation of M
deCao., the functional and detailed design ponds to tho time Qj> 6 -2 EX
P
databases for the computer software). 0 critica i design review. _ In the fii
spanning the preliminary design review product specification following was don<
o Product Baseline : Established by ation Audit (FCA). cabinets
completion of the last Formal Functional o configuration control provides a
_ This ap
Once configuration items have been identified and
system to initiate, review, approve, and implemen prop a formally identified (1) Ge
Each engineering change or problem report that (2)
configuration item is evalu; (3) B
verify that the change was correctly
Approved changes are imp. a
red as a result of the change, and the
(4) I

- The discipline of Status Accounting collects information about all configuration management I
Tod:
activities. I*
Wei
- The status account should be capable of providing data on the status and history of any '
ace
configuration item.
In
- The information maintained in Status Accounting should enable the rebuild of any previous
de
baseline.
hi
- Audits and reviews are conducted to verify that the software product matches the configuration
A
item descriptions in the specifications and documents, and that the package being reviewed is
complete. a

- Any anomalies found during audits should be corrected and the root cause of the problem 1
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
The PCA is performed to determine if all items identified as being part of the confi guration 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
 lUJOorir
tfen
th e
fit’ll.
Appendix c n
d Plinoa.
sments 8] i JS
Tl,is C l,li
catfon «st e.a ' ' l «r.
P bo ****2SS«
d
®e o ( a t ] . oo '
. ........... ..... tr
,Or 'l with th* ha»jc
»a| a M !
to the SCM Re
time
5 6 .3 PoS | t 0 d e s «0b! n8pp
qjrct. V,U
*" th
"t
Pic
O. 5.6.2 Ho
?a 0 fO
" ° g
W sd0
‘" th of
Paper
cabmen. doCu '"Cineeri
B 010
77118 a
PProach Sited in
- file
’f u
of
Pr bfe
<« Gettingg a c “ ®atic f orr ’
■ anv m ’ and 5tOT
in m en»i
co
ect
ge
’ th e
,When
and oPofan . andhv v
na e W
& ment (4)
w Narr k
Narrating a, sting“ “PP
a , . tion °m
was
Was
dually tough,

C 8 d
PoX" °“N« relaljonsh . ps “ — P-=.
of
any TOday,SCIS
'Software C0nfi «» respect configuralion

vfous aocumX?X° ,ainS a PR,jeCt

■ In early dav= ' g or

P ers °n thought Of net a
eag
’ntion developer) who had fo „ “ eeri ng, the reD os i

ed i s had to recall the data th”t w T ““ 1<>Cation of entire but

“ deed a
Person (the
DOt n ted d software
Although this a ° “ instruct inf om Z *? ““ Project, who

fem

Wbich works
both accumulation as welL storage re Xg Xa en as the center for

The SCM repository is the group of mechanisms and data structures 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
available software tools. It helps to manage the flow of the software process, and can implement
uniform structure as well as format for software engineering related work products.

Scanned by CamScanner
 ELsofh%-are Enuring (W 6 ,'c p) 5-16 Software Aisk. Configuration Mgmt & Quality
To get these abilities, the repository is described in terms of a nwta-modol.
The meta-modei is used to identify the way by which informntion is kept in tho repository, q
way by which data can be accessed by tools and seen by software developers, how well
security as well as integrity can be maintained, and how simply the present model cflri j
extended to fulfill new requirements.

To understand the features and contents of any repository, we have to see it from
perspectives: what are the content which are to be stored in the repository and what are tt°
M,0C Se services
* which are provided by the repository.
A comprehensive breakdown of sort of representations, documents, and supplementary
products whinK 1 . - «*iry Work
Use case
Analysis model
Scenario-basede diagrams
Business rules Flow-oriented diagrams Source code
Business functions Class-based diagrams Object code
Organization structure Behavioral diagrams System build instructions
Information architecture Design model
Architectural diagrams
Interface diagrams Construction
Business Component-level diagrams content Test cases
content Technical metrics Test scripts
Test results
Quality metrics
Model
content

content
Project
management
content

Project estimates
Documents j p rO ject p ,an
Project schedule
SCM requirements J SCM/SQA plan
y
Change requests System spec
Change reports Requirements spec
SQA requirements Design document
Test plan and procedure
Support documents
User manual

ie repository

There are two different classes of servic, r

W The similar types of services which m °° UStre ‘o ly :
re<IU,red S PhiSticated DB
(2) The services which are specific to the eLnr o ° MS and
Ar
- epositoiy that serves a software engineering ie

(2) Support particular rules which go ment functions,

ma SCM
intained inside the
1
reposito “ tion and the inform t -
z3 ) Pm ., . . formation which is

e
“Bering, and

Scanned by CamScanner
 l<)
“" "°"8' ■'"""' *"• •' ■”l«“« *. *•“ “» - «*

- 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 configur atl0n ’

( 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 configuration evolves over
time.

_ A process which is able to achieve these objectives need not be technical or heavy, but it must be
characterized in such a way that it should enable a software team to solve all of the complex
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 version of
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 :
1. Identification,
Software
2. Version control, Vm.n
3. Change control,
4. Configuration auditing,
5. Reporting Version control

Change control

Identification

SCIs

Fig. 5.63 : SCM Tasks

Scanned by CamScanner
 5.6.4(A) Configuration Identification ------------- --------- --------------— i

[q.5.6.3 What is Configuration Identification in SCM ? (R«f- 5 6 4

(£)} . — I

- Tbo fimt stepof tbo

specification in the SCM .ysUm
management I. theresponsible
authority Identification of the
for each Ito items
. to bo

- Ibis is a critical step in the system since the identification scheme is employed throng I
lifecycle of the software product.
- The levels of authority assigned responsibility for each configuration item will vary depen.fi I
the complexity of the software product, the size of the development team, and the mana I
style of the responsible organization.
- Configuration identification consists of selecting the configuration items and recording I
functional and physical characteristics as set forth in technical documentation such aj
specifications, drawings, and associated lists.
— The following are examples of items managed in the SCM system. s

o 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
o Data dictionaries and various cross-references
o Source code (on machine-readable media)
o Executable code (the run-time system)
• o Libraries
o Databases (data that are processed and data that are part of a program)
o Maintenance documentation (e.g„ listings, detail design descriptions)

Xzzr ““ -

Changes to these items also need to be defined

86S thePr
baselines specify the evolution of the software product. “ ’ °iKt

e
doranwntati on aU ° ftheentitie30ftIleSOftWarePr0llUrtasweIlastheirva rious representations in

me entities are not all subject to the same SCM disciplines at the same time

Support software is the class of software that may or

m&y DOt be delivered wit the
product, but is necessary for designing, enhancin software
r
the product. & ° the changes made during the life of

Scanned by CamScanner
 oftware Engineering

- Support software ni £19 _

URer ___
off-the-shelf -fum-1 8 , 1
cd, dev ,
Welo
gfoiWttion Mqmt & QunliV/ Assurance
_ In SCM, the fOCUs Cno . • P*l in . ho .. ilca!,ed
IS on descHl • ’ from a vendor, or purchased
bl 8 tb
- Developers and maint • ° ° ne<*s*n
Ion B - the softwan> prod *™.■>«< to cnsuro * ««d u m . n n w
- Whenever a production b ‘ ’* US°- ° RUppnrl anflwn
«-o * available for use for as
and support tool, w >»» '« 'KaMi. ,,
Pr Ucl On irnportant to
_ Software tools used in d ° ° ’ code archive all environmental
configuration control"' T'ont, Mpcci.Uy
lr
release. entities and ver ' middleware, should be placed under
r8,
., . ons are included in the baseline data about each
_ Consideration also needs to be •

system. There are several difTerentwav fr 1110 hi

” archy of
cnlitic, managed during the SCM
- One way is a three-level hier h ° 8tructurin g this hierarchy.
ls m
_ Another way of structuring the B of configuration items, components, and units.
being developed and the other *** 1617115 of the interrelationships between the software
&Xe en ea use<
support software, test softw during development and testing such as
A «. A «• ’ a”d fte Opcratia
8 system.
UlmS
process of building “ °f intermcdiate
products generated in the
modiflable entities (e B
test data); compilation entitfe T - sour “ “de, document,
' •£•> compilers, support software); and configuration items (e.g.,
eren representations created in the process of producing deliverables).

- An important aspect of configuration identification is the use of a formal naming convention for
each entity.

This 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.

Consistency in the application of this identification scheme is critical to accurate tracking of the
software engineering process.

5.6.4(B) Change Control (Configuration Control)

(MU -Dec. 15, May 17, May 18)

Dec, 15. May 17. 5 M a r k s !

Q. 5.6.4 Explain change control activities in SCM. (Ref. sec. 5.6.4(B)) Marks J

- Changes occur at all phases in the so defide ncies are identified in the design or
necessary if requirement
implementation approach o changes in the code or the design and requirements.

- Testing may uncover d e f ectsthat q

Scanned by CamScanner
 10 Mgml &
Software Engineering (MU - Sem. 6 - Comg
520
-----------
software RisKCogSlff " °"aB
- Changes must be made to the right version o associated documentation
change and the integrity of the remaining so K

the deve,opment proces3

<
operation and support of the software product. md

1
This mechanism should extend of t he software.
change requests into a new version and n
Generally, no single procedure can
approval levels.
The minimum activities needed for processing changes inc u

o Defining the infonnation needed for approving the requested change,

o Identifying the review process and routing of information.
o Describing the control of the libraries used to process the change.
o Developing a procedure for implementing each change in the code, the documentation,
the released software product.

Baseline Definition
■----------►
s Modification, improvement
Propose Change T or fix for error
A
I T Identify components to be
Identify Definition U changed
S
I Impact assessment of
Review and Evaluate A change by authority as
Proposed Change C stated in Configuration
C Management Plan
O
Approve U
No
Change N
T
I
Yes
N Code copied to
■* Implement Change G development area

Module and system test

Verify (test)
Implementation

No Accept
Change

Yes

Revise Notify users of change

Configuration
Records

Form New Baseline

Fig. 5.6.4: Configuration Control Process

Scanned by CamScanner
 29 (Mu.
5tation

i ior Mqni aualrt ssuran

Ports, r
q. 5.6.6
- «d dn
( M U - Doc. 15, May 17, May 18)
S22
_ Version control i nte LfRef.
Dec, 15. May 17. 5 Marks
Peni
ent versions regarding T'"** thl! Procedure
CODfl May 18, 5 Marks
process. Suration ob , W “ h tool > tor the „
,, . Jects which Purpose of managing different
. Following are the im port „ , '""crnind throughout the software
straightforwardly inte X i eh a veraj
Con ro B s
o A project database ( ° y tem implements or is
W ch
o A version mana Mds all th
HPPrOpriate
object, Sement capability whi h k ° configuration objects,
versions of a configuration
ui version of the softwar, ® “ get all respective configuration
°n, and bufld a

- Additionally, version control as

1 6 ntr0
tracking capability which be s eT' ’’? “ ‘ syste “ s anally implement an issues/bugs

. z of t : — °f 1118

necessary to build a PartiX X are

It is possible to identify various
< iailBe sets or
building a version of the software > application or system. This helps in
7 mentl nmg the
to the baseline configuration ° change sets (by name) which must be applied
A system modeling approach is used to accomplish it. The system model contains :
(1) A template which contains a component hierarchy and a “build order” for those components
which gives information regarding how the system must be constructed,
(2) Construction rules, 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

(5 Marks)
Q. 5.6.8 What is Configuration Audit in SCM ? (Ret sec. 5.6.4(D))-------

ECO (Engineering Change Order).

Scanned by CamScanner
 Software Engineering (MU - Sem. 6 -

- What wffl bo the way by which a software team moke it sure that the change has t,,
appropriately implemented?
t The answer has two aspects :
(1) Technical reviews and
(2) ’ The software configuration audit.
- The focus of technical review is on t
modifications are done.
- The 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 changes.
- A software configuration audit in general complements the technical review by the way Of
assessing a configuration object for characteristics which are usually ignored in the process of
review.
The audit asks and answers the following questions :
1. Has the modifications mentioned in the ECO been made? Have any additional modifications
been incorporated?
2. Is there any process of conducting technical review for assessing technical correctness?
■ 3. Has the software process been followed and is the application of software engineering

date
'
Has e i3 implementation of SCM procedures for recording *

6. Has there is proper updations in all related SCIs?

8
audit aeparately, °t™ aetmly. Us quality "■.; , r ,.i r „ e p | ( ( . configuratbn

This formal configuration audits also make it sure that the

with the
5.6.4(E) Status Reporting

Configuration Status Reporting (CSR) which is also knn

StatUS acco
that gives answers of following questions : “ “nting i s an SCM task
What happened?
2. Who did it?
3. When did it happen?

Scanned by CamScanner
 f2 ftware Engineering (Mu .
TO 5-23
4. >«»'»ewUl beilfrect<!<J? Softwm
, ACSRentayismad« when(JVM

A CSR
' 'vhonever U Ca >■ t» SC.
Wbe er a conll euration .& hango Control Authority) approve a change.-
0Ut
. It is possible to Rep th(j ou . ° - the reeullo arc reported a, part of the CSR tank.
CSR
wi H be easy for s„ft ware - «n oni.no datab.ee or wcbs.to, irtcauae of which it
ca egory. support staff to access the change information by keyword

- Additionally, generation of a CSR

rcport
information regarding i mportant ch w done regularly and is intended to give latest
C
_ es to management as well as the practitioners.

laj
1
l _ _Write note Uuallt
---------------------------------------------------------------------------I
? V Management. (Ref, ser 5.7) (10 Marts) |
_ Software Quality Manair • ~ -------------------------------------”
1S a method
achieved, so that the users that guarantees that required level of software is
are satisfied by its performance.
- The process involves quality assurance, quality planning, and quality control.
This concept provides a complete understanding of Software Quality Management and illustrates
the various steps involved in the process.

" Software Quality Management will make sure that the necessary level of quality is achieved by
correcting the improvements to the product development process.
— The main motive behind the SQM is to develop an ethnicity within the team and it is seen as
everyone's liability.
— 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.

5.7.1 Activities of Software Quality Management

Activities of Software
Quality Management

1 . Quality Assurance

2. Quality Planning

3. Quality Control

Fig. 5.7-1 : Activities of software Quality Management

1. Quality Assurance

QA .to. .< « »•“”= ”>

Scanned by CamScanner
 Som. 6 • Comp) 5-24

choose applicable procedures/nctions and standards for a certain project, changes can bo
squired to develop n quality plan. ' ’’
8
* Quality Control
11
will make sure that most excellent practices and standards are followed by the
development team to maintain quality products.
Quality of software will refer to software which is realistically error or defect free and
ich .
delivered in time and within the allocated budget.
It also meets the requirements and/or expectations, and is maintainable.
In the software engineering term, software quality will indicate both the functional qualit-
?
structural quality.
The different activities which are involved in the Software Quality Management are as follow

It indicates how well it satisfies a given function/design, based on the functional require™e.
Dt3
specifications. °T

5.7.3 Software Structural Quality

It handles the non-functional requirements that maintain the deliverance of the -functional
requirements, such as robustness or maintainability, and the extent to which the software w
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 products.

5.7.5 Software Quality Control

Software Quality Control (SQC) is a set of activities to guarantee that the quality in software
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 significantly over the past two decades.
- The reason behind is that companies are using new technologies 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.

Scanned by CamScanner
 • Engineering ( M u . Q

7110
I ' quality ottribuu. x. A—umncg.
041
aTL
Atth WlyBU
n,Pn,
' Ur<' d i n trrm '’ of * UMhUil
y. ratability cannot be ncrurnUly
- ! »* of project
hnppcn that
quality cx’i
oxpec™ tations . •"> ronr' H ” 11 **
«<»ftwnrn lb ,
defln
* * software specification,
thcir

„ ’ u,rce main catcgorii

(2) Quality planning.

(3) Quality control

‘e Quality Management
(I) Quality assurance

and standards that leads to high quality software.

(2) Quality planning

The selection of appropriate procedures and standards from project framework and used, for a specific
software project.

(3) Quality control

— It defines the process ensuring that software development follows the quality procedures and
standards.
- Quality management provides an independent test on the software and software development
process. It ensures that project deliverables are consistent with organizational standards -and
goals.

5,7,6 Software Quality Challenge

5 Marks)
Q. 5.7.2 What are the Challenges In Software Quality Management ? (Ref, sec. 5.7.6J

In the software industry, the developers win never guur ~

• whereas industrial product manufacturers can give guarantees about their products. Tins deference
is due to the following reasons.

- Product complexity is tne u opera ti o ns with different combinations of its machine

industrial product permits few mo es o

settings. pHnnel possibilities. Therefore, assuring the operational

- Software packages allow mflhons P, industry.

potential correctly is a major task

Scanned by CamScanner
 ftv/are Engineerinc

Software k-Configuration Mgmt & QuaKty As SQA practit

Software Engineering (MU - SgrrhSj ComP
_ SQA incor
(b) Product Visibility
than even
quality in
Also the absence of a part in an industrial product can With SQ1
level com
5.7.7 Process Quality Product
SQA gei
[q.5.7,3 Explain the concept of Quality Products m details. (Re ____ Dro ducts P quality j
' --------------— ------------------------ZJTT ctly affects the quality of delivered products. For
- Quality of the developed produ _ lculate d and the process is enhanced till the Once t]
reason the quality of the product can tasks :
quality level is reached.
l6n t based on this approach. (a) Tc
(b) C
r r ■ • J there is a clear connection among production process and product
— •- - - tr |t includes 1
In addition, it is hard to detennine software quality attributes, like maintainability, reliability, (1) Proc
usability, etc., and also to tell how process characteristics affect these a us.
(2) And
rr it h« R shown that process quality has a considerable demand
(3) Gui
on the quality of the software.
Process quality management have the following activities . tr processe

(1) Essential process standards. (1) So

(2) Monitoring the development process. (2) Pi
(3) Reporting the software. (3) C
Define Develop Assess product
product quality (4) I
process

(5)
(6)

Improve no Qualit\y es
. Standardise CD
process OK?/
5.8.1 C

Fig. 5.7.3 : Process based quality assessment

cl
5.8 Software Quality Assurance
(1) Pr<
Q. 5.8.1 Explain the concept of Software Quality Assurance in details. (Ref, sec. 5.8) ________________(5 Marks) |

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
(2) (
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
 S S ei
epr< ' QA Pract icG8Q
’ x=ess8. - SQA iOco
th 2?
“-e ' ate8 a»<l l n i I > 7 O,
»«
K '■HgEon Mgmt ft_Q,. a | iTy Ms.jrancr,
ZZ '
111,80 Mll
With SQA “fcievel olb,"’ ‘ "S ...........*«”•>««.
,6toi
tho
* ** lh' -*-• the
K
SQA gen eraU Squired n'T m ** ***
°r th
ar
,G
i® present/prior

been . ..... M
‘ ‘ ’ ,St '» b “iWins 3on„ are
pr daadta
°<iu ct d , Qua|
durance has the following
eC a th
. .. ‘ - ? co
68s 10 'Presses
It Includes the follo win „ nst antlv .
n Uyunpr<>v
9 activities ' e t he i ) „ n
(1) Process definition and "
n d aCC0
and (2) Auditing “P ‘ent
(3) Guidance
<r Processes could be
Soft
(V -“re D evelopmentmethod
(2) Project Management
(3) Configuration Management

(5) Estimation
(6) Software Design

(7) Testing, etc.

SQA system always combines a broad variety of SQA components. These components can be
classified into the following six classes.

(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) Components of project life cycle activities assessment

- The project life cycle is composed of two stages: the development life cycle stage and the
operation-maintenance stage.

Scanned by CamScanner
 Softwc

r..?n configuration Mgm Ouality

Software Engineering (MU • Sfn. 6 - Corn]
, ja-ntify the design and programming flaw>
’n P fuib-claRsoH
"7 Reviews, Expert opinions, and 4

components arc
tCS<inK
’ • h nnoration-maintenancc phase include Bpeci

for functionality to improve the maintenance tasks

The main aim of these components is to remove or at lease — on

organization’s SQA experience.
D€
(4) Components of software quality management (2)
This class of components deals with a number of goals, such as the managing the development M
maintenance of activities and early managerial support actions that mainly avoid or d5CTsa .,
schedule and budget failures and their consequences.

- These components adapt international professional and managerial values within the institute.
- 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 a general scale.
- The different standards can be categorized into two main groups: quality management standards
and project process standards.
(i)
(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 mam aims are to make the first move and maintain the implementation of SQA
components, defect deviations from SQA procedures and methodology, and advise some
z
improvements.

5.8.2 Pre-project Software Quality Assurance

Q. 5.8.2 What is concent behind th« (

sec. 5.8,2) ......... Jgfcjlarks) |
COmPODentS he
indues “ 'P to improve 4116 groundwork
taken before starting a project It
(1) Deal Review
(2) Development and Quality Plans

(1) Deal Review

- Software is developed for an agreement negotiated with « r A

internal order
up a firmware to be fixed within a hardware product °

Scanned by CamScanner
 < S2SaneggSaiMu
SjUjc
In
these cas
bu
<lget and scL s>
e<lul
ar, the project t e. une *c '
ject tena ri e>
faft
Specifi call ana tho *’ *oya i t _______
C1 QCt
Iv ° arificati activi ’° n s ust T functional
’’location,

th e

"’’obligation,,,
- -■“■no Quality p )ans

uid After signing the so ~

e deVel
ise the same organiz ation . ° Pnient
Vel contract with an '
activities are prepared.’ ° P ® e "t ,
o f t h e nProject
Z i ' and its or an internalquality
integrated department of
assurance
These plans consist ofe
Partlc
provided the base for th e ulars and required
.. . . .. current proposal and contr *evislons based on
Pre ™us plans that haze

contract. Duj
lase, resources t** 6 ® the contract submission and the signing of the
get changed. as staff availability and professional capabilities may

[eCt the
changes that occurred in the interim.

(1) Schedules

(2) Important manpower and hardware resources

(3) Risk evaluations

(4) Organizational problems : team members, subcontractors and partnerships

(5) Project methodology, development tools, etc.

(6) Software reuse plans.

(ii) The main issues treated in the project’s quality plan

(1) Quality aims -

(2) Criteria for initial and final project stage

of reviews, tests, and other scheduled co,
: Metrics

(MU -May 15)

5.8.3 Metrics May 15.10 Marks

___________—-----
w* j »riy

Scanned by CamScanner
 (MU - Som. 6 • Comp) 5-30 Softwaro Risk, Configuration Mgmt & Quality

Software metrics can be classified into three categories

Clflsalflcntlon
of Softwaro metrics

1. Product Motrlcs

2. Process Metrics

3. Project Metrics

Fig. 5.8.1 : Classification of software metrics

*• Product metrics
It describes the character of the product such as volume, complexity, design features nowT
011 ta
and quality level. ’ nc« t

2* Process metrics

the
sX development and maintenance activities of the
Project metrics

This metrics describe the project characteristics and implementation

number of software developers, the staffing pattern the
cost,

Some metrics belong to many categories. For example, the in-process

OZiS xx “r “■ •“ - » - .....
COnnected Wlth
metrics than with project metrics Process and product
Software quality metrics can be fiwther divided into following categories :

Other categories of software

quality metrics

1. Mean time to failure

2. Defect density

3. Customer problems~ j

4. Client satisfaction

Fig. 5.8.2 : Other categories of software quality metrics

Mean Time to Failure

It is the time difference between failures. This metric is genera
such as the airline traffic control systems, avionics, and weapons. safety critical systems

Scanned by CamScanner
 Engineering (MU » Seni 6 - Co m
5-31
pefect Density

L * easurCS C° d e qualit y P<* unit. This m 7 nrtkn,akd

** fun<:Um
’ ' '
Wd ,n man
’’ Customer Problems ° * bwine* goftware
S'
n pasmos the problems that customers r th'
C Unter when
stoker’s point of view towards the Dr H ° the product. I t cont«m
area
Rented problems together with the defect p ° be software, which includes the non

Client Satisfaction

(jj) Satisfied

(V) Very dissatisfied

- Satisfaction with the quality of the product and its specific extent is usually gained through man/
methods of client surveys.

- Based on the five-point data, many metrics with minor changes can be constructed and used.
For example
Percent of entirely satisfied clients

2. Percent of satisfied clients

3. Percent of dis-satisfied customers
Percent of non-satisfied customers

Usually, this percent satisfaction is used.

5.8.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.

5.8.5 Defect Density During Machine Testing

- Defect velocity during machine testing (testing after code is integrated into the system) is
associated with the defect velocity in the field.

Scanned by CamScanner
 >ftware Engines
Software Engineering (MU - Som. 6 - Comp) 5-32 Software Risk, Configuration Mgmt & Quality A-.
Fix back
— If the higher defect velocity is established during testing then it is a notification that the
has practiced higher error injection during its development process. Fix reap
- It is generally useful to monitor succeeding releases of a product in the similar develop percent
organization. Fix qua
5.8.6 Defect Arrival Pattern During Testing
Fix Back
Q. 5.8.4 What Is Defect Arrival Pattern ? (Ref, sec. 5.8.6)
Fix ba
Defect arrival pattern during machine testing identii

- The overall defect rate during testing will give the summary of the defects. _ It is a

- The different methods of defect arrivals in the project will give additional information about __ When
different quality levels in the project. orgar
- It includes the following : _ Back
The defect detection or defects reported during the testing phase by time interval (e.g., week) - If BI
Here all of which will not be exact defects. back
2. The pattern of applicable defect arrivals when problem identification is done on the reported
problems. This is the true defect. 5.8.10 Fix(

3. The pattern of defect backlog overtime. This pattern is required because development Fix
organizations cannot find and fix all the identified problems instantly. phi
If the defect backlog rate is large at the ending of the development series in the project and a - Al
lot of fixes have to be incorporated into the system process, the consistency of the system a i
(hence its quality) will be affected. pe
5.B.7 Phase-Based Defect Removal Pattern
5.8.11 De
This is an expansion of the defect density while doing testing.
- T
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.
- Because a large percentage of development defects is associated to design problems, conducting
formal reviews, or functional verifications to improve the defect elimination ability of the process
at the front-end minimizes errors in the software.
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 coverage 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
me defects « possible
ueiects as soon as ui with
-a.
outstanding fix quality.

Scanned by CamScanner
 .9 fix Backlog and B
, Fix backlog fa as 0
d
identified problems. *» ‘he VeIocjt

y<>fbU8Wri
' I t i s a S i mpIetallyof «<l ttle
ed Pr rate at v,hich
- When same is Used . °blems fi*es are done for
organizing the coni of a at th
Pr Wss 016 cbart h nth ach w k
_ Backlog Management ° - ' *'*’ can p '“ "“ ” ' " '
I dex (B r0Vlde SigniflCant
rr rnvrr 18• larger
If BMI
° Ml) is formation for
USed t0
- than loo i t ana ge th k
bacWo of
backlog is improved. ’ the backlo „ . ent and unresolved bugs.
“ mized. If BMI i s i e s g than 100> then the

$ g 1 o Fix Quality

- Fix quality or the

phase in the SQA.
maintenance
n ha io iiawuu ii it did not fix th ■
1
a new bug. For complex software' deS" r ”™' " “ S° lved the
° ngmal probl<im but

hamful client
percent flawed fixes is the percental r satisfaction. The metric of
g of all fixes m a time period that is flawed.

5,8.11 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.

- 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
fundamental software development model being used. In a broader category, SQA includes and
• implements software testing technologies to test the softwar

development until the software is phase comp hes with the required quality

into the next phase only once

standards. J stendaI ds that help in building software quality
011 one w
SQA generally vorls ® ~

g de ii„e S »a»'»““ r
Maturity Model Integra °

Scanned by CamScanner
 ££j_Software Engineering (MU - Sem. 6 - Comp) 5-34 Software Risk, Configuration Mgmt & Quality

5.9 SQA Processes

Processes include :
1. Software Development Methodology
2. Project Management

3. Configuration Management
4. Requirements Developmcnt/Managemcnt
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.

ask and Plan

(4 Marks)
assurance

5.11.1 Test Management Reviews and Audit

Management Review

Management Review is also known as Software Quality As

surance or (SQA).

Scanned by CamScanner
 It mainly focuses TTp)
e
_ Quality A SSUrance .
rf >nfi(
P ro ce S S w o factivitj “h C r t l lh n n
,n th O s o f l w ____________
In other words, d cn „ '.' tn nr rel0ted w
truarante ° °rk products.
right way. * franco
8y8t0ni l n t tH pr
QkeA ° - ° °J ect mnnngcr follows the
Audit : An audit is th BUrOt
TestM
SSCss <lnn8Gr iB d
“ P - ess ; h
a ; ‘( ° mont of H ° lng tho
things in the
Carri U1 Wor
e d o uu tt ° k prod
5.11.2 Cementation of th e ° ° r not P ducta
n n d n nn •
° Cmtcd dQt
« to assess whether
ssu
Q 5 mnce
‘ ' — — E*Plai ” the steps in

2f!2o ReUe c . 5 .1 1 2
(10 Marks)
quall,
222J!fance y
Step i
Dev
elopSQAp|an

Step 2
Pre
paratio

Step 3 __
Review the process

?>g- 5.11.1; step for SQA Plan

Develop SQA Plan
As testing processes
need Test Plan, similarly the SQA
SQA plan. Q processes need a plan which is called

are developed. make sure that products

J a,w
°”Z’; “ “
In the SQA Plan, the Test Manager should do following :
Identify the role and responsibilities of SQA team

List of the work products that the SQA auditors will review and audit

Create the schedule to perform the SQA tasks

■ ■

Scanned by CamScanner
 - Sem. 6 - Comp)

1.
Ability for the qui

person has to make sure their work meets tn

The SQA team is the group of. persons who ploys t

business will run successfully. Therefore, the Test M 8
of each SQA member in SQA plan as below .
to meet the QA criteria

Coordinate with management board and projec

o Design track and collect metrics to monitor project quality

2.

- The Test Manager should list out all the work products oi eacn
- Define which facilities or equipment the SQA auditor can access to perform SQA tasks such as
process evaluations and audits.
3. Create the schedule to perform the SQA tasks

- In this step, the Test Manager should describe the tasks to he performed by SQA with special
importance on SQA activities as well as the work for each task.
- Test Manager also creates the scheduling of those SQA tasks. Normally, the SQA schedule is
driven by the project development schedule.

- Therefore, a SQA task is performed in relation to which software development activities are
taking place.
Define the standards/methodology

To review the Management activities against the standards process, following steps are taken :

- Define the policies and procedures intended to prevent defects from the management process,

- Document the policies and procedures,

- Inform and train the staff to use these processes.

5.11.3 Review the Process

Review project activities are to verify compliance with the defined management process.

Scanned by CamScanner
 ==SSSSSS aB
In the m a 2 2C
ge r n ent / P)
(ce

U
"SQA.. . "

;i 2 Quality Evaluate

5.12-1Quality Evaluation Standards

uch as 111 the recent yeara
* . Software qualitv •
L,gettin
role played by software in .
mou
, e great importance
P ce n
mo- i u.
r day-to-day lives ’ y use of the very vital
- It is necessary to conduct evaluations of the softwe a

lecial this purpose and its core resonnaib-r* • Products. The AQC Lab was established for
blhty
ISOZIEC 25000 standard. * evaluating the quality of software products against the
Although numerous certifications for software quality exist (e.g., ISO/IEC15504, CMMI, etc.),
there is little evidence to suggest that compliance with any of these standards 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.

Consequently, the idea that software evaluations should be based on direct evidence of product
attributes is becoming more widespread. Therefore, a growing number of orgamzabona are

JX- .L. the - * — -— -- -

the processes.

5.13 Six Sigma (8 Marks)

4 Marks

narau b.
• afl very mucb
' HI which helps to focus on developing as weU as

Six Sigma is services-

delivering error free Pr0

Scanned by CamScanner
 ffilsoftware Engineering (MU - Sem. 6 ■ Comp) 5-35 Software Risk. Configuration Mgmt & Quality
5
13.1 Characteristics of Six Sigma
V»
Six Sigma's aim is to deliver the product with time nnd with greater efficiency, thereby by 4*
increasing the customer satisfaction and by delivpring what the customer is exactly expecting.
Six Sigma follows a methodology which is structured, and it defines roles for the participants.
Six Sigma is nothing but a data driven process, and it also requires correct data collection fOr the

processes to be analyzed.
custo
Six Sigma is about to put the results on economical Statements.
1
Six Sigma approach is business-driven, multi-dimensional structured which includes : _ 6-
o Improving Processes
o Lowering Defects
o Reducing process variability
o Reducing costs
o Increasing customer satisfaction
o Increased
o Profits
The main idea behind Six Sigma is if anyone can evaluate how many “defects” can have in a
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

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 . Stable Operations j

6. Design for Six Sigma |

Fig. 5.13.1 : Key concepts of six sigma

1. Significant to Quality

Attributes are most important to the customer.

Defect

Failing to deliver what the customer exactly wants.

Scanned by CamScanner
 S 61

3g
you
‘hereby Variation Sa
pecti
«g. tfhat the customer Sees
«sia=.., & Q,,a|,ty »ww.n | | C „
J
Pauts.
an
«. Stable O Perations ', ls.
tion ft
r the
insuring that the Softw
8h
customer exactly w . °u] d n

* Design for SixSigioa °

Designing to meet cu stoiaer ' «o improve whet the

~ -•-» .......
a
j Benefits of Sfv oc>i
---------------- igmQ
5.
Following are the benefits of Six Sig ie process capability.

Access,
- ' Sets a goal for eve
- Improves value to custo mers
in a
?cts” - Improves the rate of uu ’
- Promotes learning

5.13.4 Elements of Six Sigma

>ix Sigma :

Element of Six Sigma

(1) Customers

(2) Processes

(3) Employees

Fig. 5.132 : Elements of six sigma

The Customers
Customers mainly define quality.

The customer always expect performance, consistency,

j transaction and more.
service, clear and correc customers need to gain customer

This means that it is very unportan

satisfaction.

Scanned by CamScanner
 'Software Engineering (MU • Som, 6 - Comp) 5-40

2. The Processes

~ The central aspect of Six Sigma is to define the processes as

- In a software industry, the quality has to bo always seen from the customer's viewpoint.
- By understanding the lifecycle from the customer's perspective and processes, one can find

3. The Employees

Company can provide opportunities and incentives for employees to concentrate on their talCnls

The important factor in the Six Sigma is that all the team members have proper roles and corr
objectives.

5.13.5 Responslblllties/roles In a Six Sigma

Responslblllties/roles In
a Six Sigma

1. Leadership

2. Sponsor

3. Team Leader

4. Black Belt

5. Master Black Belt

L Leadership
A leadership team always defines the goals and objectives in the Six Sigma process.
2. Sponsor

and they understand the Six Sigma processes and

are committed to its success.

Team Leader

Black Belt

The person having this belt has gained the highest skill level and also he is
3
in vanous techniques.

Scanned by CamScanner
 ftgare Engineering (Mij
Se,
As per the Six Sig m
Pr
through internal tr»’ '“t -"n>, th
hoi
’'"‘iBneK "di
,ea
sure s . Master Black Bc lt 222212? Mqrnt A Quality A-.-urancn

A person who doni-

eaia . Urli b a , completed and pone
with th
r
“ “ d o ut - Thiamaybeequivu! ' te «>» or i,8 ,
_ At the conclusion of th ’ . ° r ° 1<s I>'«yC(1 b
1
*" - di
resistance issues ° des ’gn phn» y c
°ach f O r R1CTnher of
itaelf.
u
should knov, bnical and complex projects.
b G
°uld a | gQ customers or end-uaers are, their
* talents C nB
° trainta a nc j j Un(
lerstanding of goals and the
t
Syllabi

correct <4 Software Reliability

coverall quality of ( S Mark,)

Wnsidered
If there is frequent fail Ure perfom an i mportant aspect .
Unlike other quality factors it * Pro 8ram, it affects the quality of software,
measure
estimated with the help of historical u d Software reliability directly and
el
Statistically Software reliability * d fi ° Pmental data
-
M robab
computer program in a ° P W of failure-free operation of a
P d environment for a specified time”.
Now to better understand consider a program X is estimated to have a reliability of 0.999 over 8
elapsed processing hours.

That means, if there is need to execute program X 1000 times and needs a total of 8 hours of
elapsed processing time (execution time), it is possibly execute correctly (without any of the
failure) 999 times.

In software reliability one important question is: What is meant by the term failure?

In the context of any type of discussion regarding software quality and reliability, failure is
considered as non-fiilfillment of software requirements.

However, even within this definition, there are several aspects. Failures can be only ftustratmg
or terrible. mov need weeks or ever
Wil

months to correct.
omnlicated, correction made in one
Further if the issue is complicate
other errors.
, and Availability
roWlity tried to extrapolate
r
. in the aspect of software fsoftw are reliability-
Early work m the f the ca i c ulation
hardware reliability e0

Scanned by CamScanner
 lS£j Software Engineering (MU - Sem. 6 - Comp)
5-42 because of wear

- The prediction of most hardware-related reliability

instead of failure caused by design defects. wear s uch as the impact of
n re a e<
- In case of hardware, possibility of failures because desig ' failure.
temperature, corrosion, shock are more likely as conip failures regarding software can be
- Unluckily, the reverse is true for software. Indeed, all any scope of wear.
traced to design or implementation problems; since there failure) is a simple measure of
— In case of a computer-based system, MTBF (meantime b
reliability.
TBF = MTTF + MTTR
where
MTTF = mean-time-to-failure and
MTTR = mean-time-to-repair
Number of researchers consider that MTBF is a extreme useful measure in comparison with other
quality-related software metrics.
Straightforwardly, end users are practically concerned with failures, they do not have to do
anything with defect count.
Since each defect which has been contained within a program do not has similar failure rate, the
sum of all the defect count gives veiy little indication regarding the reliability of a system.
We will consider a computer-based program that has been in operation for three thousand

Several defects in this computer-based program may not be detected 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.

o piuuiemauc ror two reasons :

(2) MTBF can be misinterpreted to mean average lif o o „

Another measure of reliability is FIT (failmes-in-time). ft
ures a component will have over one billion hours of oper ti measure of number of
1
.Xt: " “ - -* “»« span of every billion hours of

a reliabllily ffleasure, one should also d., d „p

muy.

Scanned by CamScanner
 fAvgre Engineering i (Mi j .

Software avail abili .

?<?
requirements atog . v ; n" n o t hin8butt
of
Availability =

impact
Th"-sitivit yofMTB M. r t i w
of
, ne availability ‘
rn K
c measure of the ----- r
,
n be M'prp
«enslu
uro Of

15, May 18, May 17, May 18)

?wha,arete
' - EwnstopsinFTR .
other Dec. 15. May 17 10 Marks
- A formal technical review ; s
May 16. May 18. 3 Mark*
, a process Derfnrm
to do U
- Tto tesfng activity is done by eoftw durance of software quality.
eD8ineers d
_ The objectives of the Formal T l ™ "‘her persons.
> the

and
, Q. „ . fils the requirements for which it is built.
(3) To give assurance that software has been designed as per customer requirements.

of (4) To create software developed in uniform order.

(5) To create more manageable project.

or
The Formal 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.
d
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.

If Formal Technical Reviews is planned, controlled, and attended in correct way then only it
becomes successful.

5.15.1 Steps In FTR (MU -May 18)

May 18. 8 Marks

0.5.15.3 E

The review meeting considering the following constraints :

h
- Every review B

le
O Involvement of pe°P

Scanned by CamScanner
 iq
k 44 Software
== -- =-
Softvare Englneennc, (MU - Som. 6 ■ Comp) --------- ------------- ’\Z r but it should be very short. At

o Advance preparation : Advance preparation sho nr onaration

. ~ . rt rnn be Spent in this p f
ting snouia
walkthrough uro conducted for modules Or

for small group of modules.

- The focus of the FTR is on work product (a software component to be revie ) eview
meeting is attended by the review leader, all reviewers and the prod
- The review leader is responsible for evaluating the product for its deadlines. The copies of product
material are then distributed to reviewers.
- The producer organizes “walkthrough” for the product, explaining the material, while the
reviewers raise the issues based on their advance preparation.

Review Reporting and Record Keeping

During the FTR, a reviewer (the recorder) actively records all issues 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 techmeal review summary report is completed.

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 record and may be distributed to the project leader and
other interested parties.

The review issues list serves two purposes :

(1) Identify problem areas within the product and

(2) Serve as an action item checklist that guides the producer as

corrections are made.
An issues list is normally attached to the summary report.

You should establish a follow-up procedure to ensure that items

on the issues list have been
properly corrected.

Unless this is done, it is possible that iss.

cracks.”
Low-i

Scanned by CamScanner
 nro.Engineering (M ||

■ly short. At
Walkthrough
1* - -------------
& Quality Assurance
rs.

modules Or [gjaSJ— SiEiainWolkthrough

„ Walkthrough i s a Rey .
'he review "> (MU - M a y 16)
- Generally it is startea
° nlfr In3pmi0]
- In walkthrough, document '’° r < > f c »<Io. -•’Wn n , it1 . not
*: ------- Or CO J . a formal process.
of product 13
bv ,
°y authiw.
r n
Walkthrough is i nfo] nd others rn
•nnai Wnv write note on the defects and
riule the walkthrough. 1 to
sti n igy 80
there is
no nerrl r.e .
We can caU it as Open Ende . moderator while performing
of observation is not necessary ' 8CUSSion be
«>'
•re meeting and creation of a list
It is the informal wayJ of „
review
challenging task in walkthrough 80
it does not f 0(n 3
on documentation. Defect tracking is
iced. In

The following are theobjectivesofWalkthmugh:

O

O To explain information present in the document.

o To verify and discuss about the validity of the proposed system.

o Reporting the suggestions given by the others (other employees).

5.17 Comparison between FTR and Walkthrough

• and

May 1 6 . 4 Marks

I Walkthrough
Parameter
Walkthrough is a Review meeting hut it
Concept A formal technical review is a process is different from Inspection as it is not a
performed to give assurance of software formal process
quality ------------. ------------------
sen
This testing activity is done by software Generally it is started by the author of
the code o ‘
Performer
engineer Walkthrough, the producer
a
work product is in spected describes the product and asks for
Process comments from the participants
for defects y dit

thepersonjW -------------

Scanned by CamScanner
 Engineering (MU . Som . 6 . Comp) 5-46 Software Reconfiguration Mgmt & OuaMy A U;g

_ _ _Parameter Walkthrough
rm
Work Product A Work Product is any significant Walkthroughs generally help to examine
deliverable developed through the source code as opposed to design and
requirements, design, coding, or testing requirements documents. A n tep-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...

□□□

Scanned by CamScanner
 ftware Testing and Maintenance

Modules,

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 fulfilled 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
represents 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 te t
data is used to test the capability of our software modules to handle unexpected input

Scanned by CamScanner
 6-2

6.1.1 Advantages of Software Testing

Q. 6.1.1 What aro Iho advantages of Software i

There are” several advantages of software test ing . which leads to software
Testing reduces the possibility of software
failure.
2. Testing process removes maximum
software to customer.
3. Testing ensures
Testing allows us to verify and validate the so
the user’s requirements outcoroe

Testing enables the software to proa

system from producing expected outcome.

6.1.2 Types of Software Testing ____________________

00
| Q , 6,1,2 Write note on Manua! and Automation Testing. (Ret. s ~ 6 i

Software Testing is divided in to two categories :

Types of I
software testing |

-<»j 1 . Manual Testing |

■» 2. Automation Testing |

Fig. 6.1.1 : Types of software testing

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
 6-3
_■ Software
100
One important thing to know about q„ A ...mm**
-Ki ” cn nonrl wa
t r nt
»ut Software
possible so wo need to perform manual testin _ Testing is thnt “lOOC'o Autm"

|9 of Manual Testing

rfhe main purpose of performing manual testing in to give aosurnneo that our .oftw-* Pr o d u C t

joes not contain any defect and it fulfills all functional requirements of end user,
10 w and they m u , t
'fest Suites (i.e. collection of test cases) or cases, are designed in the testing pl
test all functionalities present in our software product.
d tester perform*
Manual testing gives assurance that reported defects are fixed by developer a
retesting on it after fixing the defects. software
Mainly manual testing verifies the quality of the software product and deploys
to the customer.

(i) Unit testing

4 2. Automation Testing n ou r test cases to find out

Automation Testing is a process in which we use automation tools to run
bugs from our software product. v on which we perform testing

„d» ■ „„„ „d -* ..
testing tools etc. make chang es in code and we
, After
requirechange in requirement
executing or occurrence
same test suite of error, we
again and again. nn

. w.t„ ,.«rf •»« ‘7X7.77777.7.. ual testing.

M “7a— ” I. <•
replace Manual Testing completely.
ire generation of test cases, test data and test script
- To perform ai '
reject if requirements. offnroiects
p J are stable at some extent

- Automation not frequently changing.

List of some automation tools

(ii) Mentis

(i) Selenium (iv) Buxila

..... Qu
(m) Quality Test Professional (QTP)Management)
Lifecycle
(v) HP ALM (Application Life y

Scanned by CamScanner
 .r0 En

cnftwaro Testing and Maintenanr„

Software Engineering ( M U - Son). 6 • Co If w

ld Automation Testing
(5 Marky def<
6.1.3 Difference between Manual am
6.1.3)
1 an
an<
mi and auton*** »o 0
O. 6.1.3 Dlfforontiato between man
Au Te
Parameter Manual Testing »_ m
T° rform Automationtomation
pc c Testing, testing
human we
interact
use too],
is
Human To perform manuni testing human is not required, in
interaction interaction is required for
execution. _____ —
T PO Ul tion tes ng 8aV 8
Requirements ° fTtoo°iB
To perform manual testing, we nee automation tool* °A “" “ . °
g
skilled employees, more time and
high costs. “Xt nZthen it can easily run test suit.

is used to test an application

tested Automated testing
Application to Any application can be first
whose requirements are stable at some extent and
Test automation testing mainly used to perform
hoc and monkey testing are
performed manually. _
ia rt which is of running same test
Execution of We cannot use manual testing while
cases repetitively
Same test cases executing same test suit. Repetitive
automation testing.
execution of test cases become (e) *
boring and error prone.

6.1.4 Principles of Software Testing

(10 Marks) (0
|q.6.1 .4 * Explain the principles of software testing. (Ref, sec. 6.1 -4)

There are 7 Testing principles which are as follows :

•, we require performing the best possible

Risk assessment is the process of guessing module where defects may occur and test that module
to find out those defects. Because we have not that much amount of time to test each and every
module from our software, exhaustive or complete testing of software is not possible.

(b) Defect clustering

- This principle states that about eighty percent of defects are found in twenty percent of modules.
Using experience, we can find out such risky modules.

But this approach has its own demerits such as if we run similar test cases repetitively, such test
’ cases does not find any new defect.

Scanned by CamScanner
 6-5
Ide parade

lf we use same test e M c s r e

' jefect- To solve this problem, M

8
and include new test cases to ....’J" '" *
festers cannot use
n M,,
' metl to find out more defeat X ’ " , ' lwn ’ ”« should fry to improve tho existing
i9 buB free
‘ r l Crfnr,ni
’ "K testing, you cnn novCT c | aim your product

ting ?hows Presence ot

detects
fe5

Testing process can show that tho defect 8 880

that there are no defects. Prc8cn t in tho system under tost but i t cannot proze

® hy a..., w „ fcm

(Hi) To ensure that system meets the business and the user requirements.

(iv) To gain customer’s confidence by providing them a qualitative product.

|e) Absence of error

- The software which is 99% bug free can be still unusable if it is tested for wrong requirements i.e.
absence of error does not help if system does not satisfy user’s need and requirement.

(I) Early Testing

- Testing must be started as early as possible in the Software Development Life Cycle (SDLC).

- Therefore any bug in the requirements or design phase are find out in early phases of software
testing.

It is less costly to correct that bug in early stages of testing.

- It is suggested that we can start detecting the bug at time when requirements are gathered.

(g) Testing Is context dependent .

Testing is context dependent’ specifies that the way tester test an online shopping site will be
different from the way he / she test stand alone application.

6.1.5 Objectives of Software Testing

(MU - D e c . 16)

0. 6.1 .5 What are the objective of testing ? Dec. 16. 5 Marks

(Ref, sec. 6.1.5) _______1-----------------

- Finding defects which can be genera

Scanned by CamScanner
 Software Testing and ndinE
>*pepe
6-6 1
. S o m . 6 - Comp) ' priority”
, for correction and aiw. --------------- - -e a *. the en

Software testing is don

end user. i tv software to our end user.
finds c
To eiv e assurance U.»t «o in rho BBS (Business
Atth<
To make sure that it sans “ ircm< , nt Specifications).
se
Specification) and SRS (System ty 8oftwarc pr(xlurt „ Wch C»
Inti
**•
user
Itii

6.1.6 Software Te

r
process ln 1W,
(J. o . »
_ (Ref, sec. 6.1.6) ------------------------------------------------ (V
a(

_ Software testing process is a sequence of vanou analysis , Test planning, Tea

_ Software testing process Tert cyd

development, environ) id exit criteria.
t») Test

Requirement I
analysis —I —
------- Test
! planning
Test case
development
Environment
setup y-
Test
execution —
- Test cycle
closure

Fig. 6.1.2

Entry criteria : Entry criterions of testing are prerequisite conditions that must be sat—

ErifcriUriaXt criterion of testing describes the conditions that must be satisM

testing is concluded.

cr- phases of Testing process

(i) Requirement Analysis

In this phase all gathered requirements of system (i.e. functional as well as non-func

Scanned by CamScanner
 Engineering ( M u .

Depending on re qui
priority of testing.

A t the end of thi 3 ph

Hcc
S x planning lUiren Cn
t T ri .
Of
rfC P should tn focua and
Mi
„ It is also known as te8t
finds out required Phos , R

_ At the end test pl ttn u '’“‘"'’ roat t,,. ,

n W,
„ . Pared u8 a 's eyste m . ’ ‘ , n * h i . phs.o maneger
hiCh
— the ” ’“‘wmo of s l ' ' ot.
■ P'anninj?.
In this phase nil te a t di
uotern *

pts qV,lrcm ................. .

are outcome of th- u « of teat C93<
18
environment set im Phase.

After completion of
Test
c ase
esult of smoke test are outputs of this phase.
TeS t Execution

plan and test cases.

These bugs are reported to development team for correcting them.

After correction retest is performed in order to assure that reported bugs are removed.

This is end of software testing process.

Ill this phase cycle completion criteria is determined depending on time, test co rag

system, cost of software, business objectives etc.

By using all these attributes test metric is prepared. or analyzing

isfied

sfore
Syllal

Scanned by CamScanner
 pnqineQ

cnffwaro Testing and M-iintong nf .

. , which will be a series of step, in rj em al

E* Software r-mrwjna (MU • Som. 6 • Cong! . software testing placed.
Hence a there is need to ‘ „„ well a" testing met f |ng characteristic, a iatlo n

which specific tost case design n v n i lnb1o from which

Validal
Tlicro are number of software testing strr
softv/a
expected : . _r „rtbetive technicn
o For effective testing, there is «' It can
errors before testing commences. (dfl «o u t ward n toward tho incorporation of th<J
depl°
Vah<3
whole computer-based system. o9 suiU ble for different software engineering

pltferc
approaches and at different points con ducts the
In case of small projects software
distinct activities, but it is necessary to
Testing and debugging are
accommodate debugging in any testing ra rai* etc
accommodate low-level tests which are
to
For a strategy of software testing it is import tree code segment as well as high-level testa
fOCUS
required to verify that impious fi ptions against customer requirements i3
which are used to validate mo:
correct.
.ctitioner (newcomer) and a set of milestones for the well

experienced manager. strate gy is done at a time when there is increase in

possible.
- — " -“ - "
Syllabus Topic : Verification and Validation

6.2.1 Verification and Validation

(5 Marfa]
|q.6.2.2
Inch
Verification

- Verification can be defined as a process of estimating the intermediary work products of a

software development lifecycle to verify that we are in the correct track of creating the end user
product.
Now the question is : What is mean by the intermediary products? The answers is the
intermediary products consists of documents which are generated during the development
phases such as requirements specification, design documents, database table design, EH
diagrams, test cases, traceability matrix etc.

Sometimes we can avoid focusing on reviewing these documents but reviewing these documents
can help us to find out most of the glitches. If these glitches are found at later phases of the
development lifecycle then it will be very costly.

Scanned by CamScanner
Jaced. in

grcharacten t.
s
°re

vare env-fn,,
nee .
n« g

ft2
2
Projects, th ere

’ necess.
Compare Verific;
•> (MU - May 15, Dec. 17)

5ts
hich are teter | May 15. Dec. 17. 10 Maries

gh-level tests
Validation
dements is j focus a
V to build a
system.

for the well definition Verification can be defined as it i 5 a proccss I „ .. . „

of estimating the intermediary work ““ “ “
process of evaluating the final product to
increase in
ensure that the software meets all the
s early as - to verify that we are in the correct track of
specified requirements.
creating the end user product.

Aim 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 the

Marks)
Validation contains testing such as blac
Inclusion Verification contains Reviews, Meetings

and Inspections.
j of a testing etc.
[ user
Verification is conducted by quality
Performer
the assurance team.
Execution of code is a part of Validation.
lent art of
Execution
ER Verification.
of code Validation piirocess gives explanation about

accep
Verification
its Explanation whether the outputs ar

or not.

Scanned by CamScanner
 Software Testing and Maintenance
J bonwan? E ngineering (MU - Som. 6 • Comp) —
Validation
Parameter Verification ______
Testing of actual software is done in
Processes Plans, Requirement Specifications, Design validation.
Specifications, Code, nnd Tost Cases etc.
are evaluated in verification. _

6.2.3 Software Testing Strategy - :

soc< 6
fo. 6-2-4 Explain ‘Software Testing Strategy" with suitable diagram. (Aof- ) —

- We have ahvady seen phases of software testing process. Now wo will see software process with
different aspect.
- The software process can be considered a s the spiral as shown in Fig. 6.2.1.
- In the beginning, the role of software is defined by the system engineering and proceed to
software requirements analysis, in which there is establishment of the information domain,
function, behavior, performance, constraints, and validation criteria for software.
— Moving towards inward in the spiral, we come to design and at the end to coding.
System testing

Validation testing

... .
.Integration testing
,>Z
' ' ' - '

Code/

Design -

Requirements

System engineering

Fig. 6.2.1 : Software Process

- It is possible to view a strategy for software testing 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 testing. Here
1

the mam concentration is on designing and building the software architecture.

which are set as part Tf ° D SPIr81

’ ° bSerVe VaUdation testin
S> “ which
requirements

whichhasbeendeZ; L “ "
-

At last we reach at system testing, where testin

-

g of the software as well as other system elements

—

is done as a whole.
_ _ _, - -
.. .

Scanned by CamScanner
 f j’or testing any Oxn
' v , Puter
.treamlmeewhid.
*u nce c |> \Vf, .

• :x;.“
2
........... ■
, In the beginning, tcsf g ’ - •* feu, .,„ . • '• ««*.« ,.r „ A __.
properly as a unit. C0nC6n
0„

„ Therefore, the name i 8 n 1,v r

Unit «. ' ' lua|i
particular paths in V Mt u
<>f teslin
possible error detection. • compon * « Uchak . . s ..
pOn
ent ta conr Actively hich ewreim
’mtire «*erage a s waR maximum

Re
quirements Hi
9h order
tests

Design
I integration test

Code . unit
test

Testing
direction

Further there is need to assemble or integrate components to form the whole software package.

Integration testing highlights the concerns which are related to the dual problems of verification
and program construction.

Test case design techniques which in general used to concentrate on inputs and outputs are more

as
.vider context o co

le £Uitaba?e
harlvareZoP ’ ' ' t’ C t the elements mesh correctly and the overall system

Syste m testing
erforin
function/p - -------------

Scanned by CamScanner
 Software Testing and Maintenance K-
6-12
Software Enalneerinq (MU - Sem. 6 - Comp B

6.3 Unit Testing

(MU - Dec. 15j
1
Un' ‘
P e c . 1 5 . 3 Marks
IQ. 6.3.1 Explain unit testing. (Rof- sec. 6.3J
•e
Software testing levels arc the different stag
testing is conducted.
There are four levels of software testing .

We are going to see the Unit testing in detail.

Unit Testing

Unit Testing is a are

tested.
The purpose is to validate that each unit of the software performs as designed.
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 I
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.

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 testers.

Unit Testing Tasks I Aspects of the software tested in unit testing

- Unit Test Plan

Prepare

Review

Rework
Baseline

Unit Test CasesZScripts

Prepare

Scanned by CamScanner
 pc view
pework
Pflselino
Unit Test
perform

ft Testing Benefits
Unit testing in creases
and if they are run overyT '' C° in
,
introduced due to the ehange ' «xi 0 is ' ining R

. Also, if codes are already ’ * iU

able tc ar* -written
mari
imP act of changes to any »‘Mep eMent
8 IUakeu
_ Codes are more reusable In ’ mtte8 t■ln g possible, the unintended
tes
means that codes are easier to «ng
P
Development is faster. Ifthe . need to be modular. Ih-3
unit testin
that fuzzy ‘developer test? tn? s in t>i.„ a ,
that hopefully hit the code and n h 0 ’*'’ "* S ° me potato ZITk™™ “ d ' “ d perforTI13
d hope that are all • ’ lre UP provides a few inputs
18 Set)
But, if there is unit testing in place d
10Per/tester
test. Writing tests takes time but the the test, write the code and run the
run the tests; there is no need to fire h C° mpensa e
by the less amount of time it takes to
tests are more reliable than ‘developer tests’ 6 PTOvide aU those And
’ aIso *
Development is faster in the long run too. The effort required to find and fix defects found during
unit tes mg 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. When a test fails, only the latest changes need to be debugged. With testing at
higher levels, changes made over the span of several days/weeks/months need to be scanned.

Stubs and Drivers in Unit Testing

Q. 6.3.2

Driver

r —
Module Test
Cases

Scanned by CamScanner
 Engineering (tA

Xt makes use oi
Incremental ai
S oftwa ro Testing and Maintonancft
0-14 »yhe main ob
Software Enofnperi (MU - Scm. fi ■ Comi
integrated ur
(1) STUBS lulo c Mo d u l e A i s ready and wo n
0 n
Assume we have 3 modules. Module A. Modulo which nr °t ready, so develop
to test it, but module A calls functions from M returns values to module A. This
will write a dummy module which simulates B
dummy module code is known ns stub.

(2) DRIVERS
J . - t Mo dule A which calls functions from Module B
Now suppose we have Modules B and C rea y for Module A which will return
and C is not ready so developer will write a dummy pi0 •„«_
values to Module B and C. This dummy piece of code is known as dn •
fohowir
List of Errors Detected by Unit Testing
A Modi
,Q. 6.3.3 logic m
Following is the list of errors which are usually Unit Testing can detect So,
Local data structure efficie
Boundary conditions VZhih
Independent path Viet
Error handling path of sc
Local and global variable The
Incorrect initialization bet
Incorrect symbolic representation of an expression Th
Incorrect arithmetic precedence
T1
Global variable naming convention
F
Mapping error
Log and exception handling « 6.4.1 Tyi
- ; Referred different data type in the code and database
- Necessary input parameter not trim during the saving in the database.
2.
Syllabus Topic : Integration Testing •1
I

6.4 Integration Testing

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

0) Bk
Q. 6.4.1 Explain integration testing. (Ref, sec. 6.4)
Dec. 15, Dec.-.i6. 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.

It is always done after unit testing is applied.

It mainly focuses on testing data communication among all units of system

Scanned by CamScanner
gdMaintenan

31,(1 We
n Ged
50
develop
uIe A
- Thi s

m
<xlulo LY
1 I ] Modulo
\ / 2
Module B
d11 r
eturn
F|
8- 6.4.i
Following are reasons for performing bite
tCSti ;
A Module is developed by software de "«
Marks) !ogic roay not. be same as of other suftw.;: » f Ending and

from
So, while performing Integration Testing w P ro M te 8 m . ’
te chcck
efficiently with ether modules or not. Aether software modal.

ffe may not perform unit testing B for this new

Iortlus new
• g ” req< “ re!nents by 016 cheats
-
_____ _ _ _ _u . j requirements and so ___

. rnere is possibility that interfaces (through which operations on database are done) present
between software modules and database may contain error.

_ There is possibility of error occurrence due to external hardware interfaces.

There is possibility of raising issues if exceptions are not handled properly.

For all these reasons we need to perform integration testing.

6.4.1 Types of Integration Testing

1. Big Bang Approach

o Top Down Approach

o Bottom Up Approach
Combination of Top Down and Bottom Up
o Sandwich Approach -

(1) Big bang approach lte d first and then they are combined

- In this strategy, all modules o so

de 1’ to ‘Module T
together and whole ,o«w U . I- »•“ „ •«"“

- Eaantpto of Mg b„, «««“ '* ‘ at-

are combined one by one and

Scanned by CamScanner
 Softwaro Enginooring (MU . Som. 0 ■ Comp) 6-10 Software Touting and Malntono..-

Modulo 1

Modulo 7 Modulo ?.

Module 0 Soft wore Modulo 3

Modulo 5 Module 4

Fig. 6.4.2 : Big bang approach

as cause we test whole software at once.

ere are iota of interfaces which needed to be test.

d tested
Priority basis because all modutes are sLTtime" “ »

basis. ‘ hat re
' ated mth user
interfaces are not separated and tested on prio
(2) Incremental Approach

’ “ — “• - - — - « « M , (h„ _ are

'
procedu
™ continues until all of th. s /

d
™ - - - ■».» - h
r
re. JT ,_ '“o™ as Stubs and

modules
A Stub .s dummy program which is called K .u -
ace 7 6 Mod
called module by stub. on which testing is
nver is dummy program which calls an nth e

Calhng module is replaced by driver. “ ule to be tested by

Scanned by CamScanner
 Engineering (MU -

Perfo,
(a) Top Down (b)
Bott< , 'fig *
hi Up

Integration

6
are present at the bottom’;"*"’ ** formed fr

In top down approach, stubs t™ " M u ’'

•which

Module -I

Module 2
Module 3

Module 4
Module 5
Module 7 Module b

approach

Critical Modules are tested on priority basis so critical designing defects could be found and fixsd
early.

Top down testing requires many stubs because for replacing lower level modules there is n.ed
stubs.
. Modules present at lower level are tested insufficiently because oflack of tune.

■
Drivers are used
Ood wnu p
while performing bottom up

Module!

Module 3
Module 2

Module 8
Module?

Bottom u P approWh

Scanned by CamScanner
 ppqineerii

Usabil
Software Testing and Maintenai
- Som. 6 - Comp) 6-18 comp*

Advantages Bottom up approach ftet com

Ther
8 spec
ZZXZX. forallraodu|
2. A vj
Disadvantage Bottom up approach jjefore s
Critical modules which are present nt the top
critical modules.
of software are 'There i

Qonf’ l S u
6.5 Validation Testing Conti’
the r
Q. 6.5.1 Explain Validation Testing in detail. (Ref, sec. 6.5)

When integration testing ends, Validation testing begins. After completion of independent
The
components, the software is completely integrated as a package, and interfacing errors have been
found out and corrected. Alpha
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-
recognizable from the system.
There are number of ways to define validation, but a general definition is that validation will be A]
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

6.5.1 Validation-Test Criteria

To achieve software validation a series of tests is carried out which demonstrates conformity with
user requirements.
A test 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 All of the respective behavioral characteristics are achieved.
o

o There is consideration of all performance requirements.

o Documentation is accurate.

Scanned by CamScanner
 rnginoonng (MU - Som n
23f Of ap)
ItT Usability as well ( l H
Testing and Maintonan - Cf
' ° compatibility, error rocov ”’f! n l i n l rf
So*.
covery, ,

- ........... v M M a Cn
................. ...... .....
There is acceptance O f U *’-th<
fun
specification or *° etion Or
iOS
tth
har ’ ,bb
• »»cteriMiA •
l n
° ’s not cov ” n r " it conforms to
1 ° n 'l a liqt
project. difficult 1 fo
iat control the fl O w cnn-r,set the devj n
* ? efkienc y • ’ created.
” “cvjation, fJT
C11Cnt {c
UBtome r ) U
uration Review set a method f 01
con fiS

!red
as a vital clem
b al Validation
l associated Process. The main aim of
ents of
d. the software r.
of independent
LOWn
rrors have been as audit.
flpha and Beta Testing
)bject-orien ted
---- ---------------------------
jpg- (Ref, sec. 6.5.3)
(10 Marks))
vhich is user- pha testing

ie to find out bugs before deploying the software

ation will be

Alpha testing is a type of acceptance testing.

yarding the
This testing is called as an alpha testing since it is performed when development phase of
software application is near to Beta Testing.
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.
Alpha testing is typically performed by in-house software engineers or QA staff.
oity with
. It is the final testing stage before the software is released into the real world.
Alpha testing is performed in two phases :
t team members. They perform debugging of
(i) m first phase software is tested by developmen
software to catch bugs quickly.
quality analyst team for additional testing in
„„ ph—'-"
actual user’s environment setup.

- Better insight about the

- Freeupteamforotherproj -

Scanned by CamScanner
 1
Software To -.ting and Maintop-
LjJ Software Engineering (MU - Sam. 6 • Comp)

- Reduce delivery time to market.

Early feedback helps to improve software quality. pl
(2) Beta testing
r
perf°

well as intended users will test the software to determine wnewicr rmwaiymg t] >eir
needs and expectations.
- Beta testing allows users to test software before it i s released to public.

- Beta testing minimizes the product failure risks and delivers qualitative product thr
customer validation. It gives direct feedback from the user. fad
- 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
Inc
Validation testing and Pre-Release testing.
Beta testing gives assurance that we deliver quality software to our customers by testing th&
product under various situations in real world environment that can't be created in a lab setting

Beta Testing permits tester to test the software application in post-launch infrastructure.
Beta testing improves the quality of software product by using feedback of customer.

lues.
Beta testing helps to increases customer satisfaction.

Types of beta testing

There are various types of Beta testing :

L iS Provided to t
m "* eted of end
aspects. This data is useful for the improvement —
Product.
and
-reiated

2
‘ u nT r 648 I eStble
’ thiS
° f test
”S' P roduct » released publicly in real world

tzxtr - “ - - »

Scanned by CamScanner
2. Engineering (Mu
-So.
•fop)
be A|ph

£nanc , ’‘Ung

'•li
parameter
Alph,
formed by ■ ipha "’"n K

Who is
as are < On,
are is satisfying u 1Q . eerie;! Uy’ > by T '
t>
'on. en,
Ploy«. 8t,n
of □ rn «i8don«
ting environment Alpha not e‘mni
i
End
U
yeesofor.
6 done
e product through “' onmaat' «
lab
tested Beta
kiting js .
a i enyir
onm ent d
° ne real
not
tested "T °' WorW

Testing PU1 Pliability

6
Pha
8,n
sting, Customer lCluded testing typejAlph, ia ' d Uri „t ET T;C "’
testing g L .
includ es Wte
bla
— ck box testin, Beta To « ---------
by testing the jYme required Alpha testing m . Testing * “ C' UdeS Black

3.lab setting.
P rm because LXTJ “> *
WGGkS
WeU °f is
squired to
«• black J Perf0na
the beta testing.
testin is
Performed. * S
mes
ire. Important issues
cted in Beta testing will be
Alpha testing. corrected in future versions of the
software product.
Focus Alpha testing focuses
on giving Beta testing also focus on quality of the
as raoce about quality of thZ produdTbut
■ - v it collects feedback from
software product before going to end
users about software product and
Beta testing.
gives assurance that the software
fociated product is ready for use in real world
environment.

world Syllabus Topic : System Testing

users,

U System Testing
>mal -» (MU - M a y 17)

May 17. 10 Marks

0. 6.6.1 Write short note on System Testing. (Ret, sec. 6.6)
for f o n Hre and completely integrated software product.
System Testing is tes go w h 0S e work is to test the complete computer based

id
System Testing is sequence of vario
system.

Scanned by CamScanner
 Software Engineering (MU - Som, 6 » Comp) 6-22 Software Testing and Maintenance

~ System testing is end-to-end testing, i.o. wo tc

| Log in modulo Enquiry modulo ► Admission modulo Log out modulo

oystem testing contains both functional (chock whether requirements oi user are luinucd or not)
as well as Non-Functional testing (check whether expectations of user are fulfilled or not).
There are Two basic categories of Software Testing such as

Software testing
methods

1. Black Box Testing

2. White Box Testing

Fig. <5.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
eep owledge 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

► 1 . Usability Testing

2. Load Testing
U
......- .......... . ...M.,
3. Regression Testing

4. Recovery Testing

5. Migration Testing '

6. Functional Testing f

7. Hartfware/Software Testinn b

Fig. 6.6.2 : Types of System Testing

Usability Testing

Scanned by CamScanner
 gngin ee r|n g(MU . S Om .G.

It is non-functionnl U»8 ti n R i
Thifl testing basically concei.,
Jt i 8 verified that after fr w bou " ®asi
ttn,nin
jeon used in user interf ac _ ., R K. m<l
X hot roKf
Con
picture. rusinR.
e. RW* foIf If '’* S ’ T8t •* Tn «tnf< Wy .
n
*• n*. not CT1
now
. n n B UilBCT
This testing is sugg C B t c d t Export T
. _,=■> interf.m P rfonn - «■» initial <!„■
a,,,;;""™
8
"'n eban w te ; !■>'"» of SDLC n r ind v„,„
Load Testing
1*
, Load testing is a type of P C rform a n „
life load conditions. sting which bj

time. P' Shaves when multiple users access it at same

This testing normally used to find out :

-me maximum number of users who can access the software at same

2. Specifies whether currently available infrastructure i.e. software and hardware is adequate
to execute the application.

3.
4. Scalability (action taken to increase capacity of system such as increase storage etc.) to
permit to more number of users to access our application.

It is non-functional type testing.

Load testing is normally used when we test ClienVServer based applications and Web based
applications .

3. Regression Testing
usal
of * - - ," ,o''. o ' o . o 0 -00 s

- made a,
been m „a.
coae i-u » - - '
functionality. d test cases to .give assurance a
o pxecuto alTvauj

LXnXX

working of existing

4.
Recovery Testing
done
Recovery Testing *
disaster such as J

Scanned by CamScanner
 4

f Soft/varo Testing and Maintop

50

T Software Enplnooring (MU ~ Som. 0 • Comp)

J identify the point where the behavio/JT'

- tn recovery tiling. system portorm rv..v-------u. opora tions up to the point J *
system was correct nnd then from that point nga n pc herj
system get crashed.
6. Migration Testing

- Migration testing is performed to give assurance that the software can bo moved freni *
system infrastructures to current system
- In Migration testing, wo

6. Functional Testing

- Functional testing is a type of software testing which checks that every function present ip the
software application works as per requirements of user.
— This testing includes black box testing and it does not focus on the source code of the soft
$ application.
- Every functionality of the system is verified by tester using appropriate test data and actUa]
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 and

software used in our system.
- IBM called the Hardware/Software Testing as "HW/SW Testing".

Syllabus Topic : Software Testing Fundamentals

search errors d a good test is the test which has a Ugh I

’“
a customized software or a product with keeping
testability” in mind.
- Simultaneously it is don
exhibit a
characteristics which leadZ a"™ “ «f

-
swiy howeasii, [a coaputerprograJn] “Software testability is

. z zxx„„. .
- Operability : “The
e
while designing and implementing a s te ® Clently U can
be tested.” If quality is focused
C mpara Ve sma
execution of tests, allowing smooth testin * ° U number of bugs will block the

Scanned by CamScanner
 . Engineering (Mu . Som r _
(jbservability • “What
havior ' distinct outputs. '• Wl.o l
he
Point °f Wro n K output i, . iraply lnpu„
dGnti w —r ‘9
automatically. Source cod . fied. n hich nr !
CSnbe
* n< „
8 Qcct>88 -n f(r
Controllability . •Tho ibl G ‘on „ n(1
Portiii n g of rou
int*
,nf
‘m * a*l Rh„ *»*tutinn.
•
the efTn
d &om
»)<io r ' lo the
80
control software and ha execu fa 8 * d ° De U auteTO
*
’tern. posstblo to specify (.«,„„ *»« and v„ ri ’ M r "° '<u»bin. lio „' <*lnput. , M

ly au es str
Decomposability . -3 > tomate aightly by th e *’ possible to

enti
' Md perform “ *’
«U.e
*" modules wWch cm " The «n m „ c
s Simplicity : “The less there isL ‘"'‘‘ ntl/ S°' lW " e b itopleLntod
°ftw are th
expected from the program fe g „ » -ore quidu, w
tUr
structural simplicity (e.g., archil" ° K t « the mim ' W ie
functional simplicity i.
■ ac tuaj odul
Simplicity (e.g„ a coding standard " “ “W to1™ ““““’ *" “ cet uiremenW;
8 adoptedf
. Stability : “The f ewer ‘ »reaseotm8 pec ti
software are less then itt a «» rupXm •
asy
t° control them and h. testing.
f SOfUare IfisModifications to the
fast from failures
. Understandability : “The more information ° '
the
Nation regarding 3? ’ smarter we will test.” If there is
and internal, external, dependencies
’ shared, test will be Lrte
Characteristics of a Good Test

[O6 J -----Write Characteristics of a Good Test, (Ref, sec. 6,7.1) (s Mark5) '
There are some characteristics of a good test as follows : — — -
- There is high probability of finding out errors in a good test. To achieve this goal, there is need for
the tester to understand the software thoroughly and try to develop a view regarding how the
software might fail.

- Preferably, the classes regarding failure are searched. For example, one class of possible failure in
a GUI is the failure to identify proper mouse position.

- A series of tests possibly developed to exercise the mouse in an effort to exhibit an error in mouse
position recognition.

- A good test is not redundant. There is limitation in testing time as well as resources.
Irmina a test which has same intention as another test.
- There is no meaning m performing
, . m nst be different.
- The purposes of differen s * tegts which have sa me aim, time as well as

- 4 good test Should be ‘best of J p entation of just a subset of these tests.

resource limitations may Mtigae . having highest possibility of uncovering a whole class

should prefer the testna

- In such situation, one sho
of errors.
i

Scanned by CamScanner
 ]£/_ Software Engineering (MU ■ Som, 6 ■ Comp) G-26 Software Testing and

~ A good test should be neither too simple nor too complex. Even if sometimes tester can combin
series of tests into one test case, lie should remember that the possible side effects relatod
this approach may mask errors.
Usually it is better to execute each test separately.

Syllabus Topic : Whlto-Box Testing

££ White-Box Testing

6 8
- • -------- Wrif8 note
°n White Box Testing. (Ref, sec. 6.8)
WTiite Box Testing is testing process in which we verify internal coding and infrastruc*
of
software product under the test.
White box testing is based on analysing the internal implementation of system under te t Tk
pr ramming knowledge or detailed functional knowledge of system is major pre-requisite

box testing mainly concentrates on the testing flow of inputs and outputs th™,. u
are, strengthening security and improving design and usability of software product §
x testing is also called as Clear Box testing, Open Box testing Structural
tes
Transparent Box testing, Code-Based testin. anH .

used to fadicate test g f Mde f

“ ° ° we can see what is

white term todicate the capability to see

XXXX
It uses following methods :

° Statement coverage i.e. testing programming statements using minimum number of

tests.
Branch
° coverage : This is to ensi
once. »ns in system are tested at least
Path covera
° 8e : It includes ensur
least once. in system is tested at
Other than above there are
Condition Coverage, Path “
Every technique has its own advent™. J ...

Step 1 : Understand the source code

In this step, testers understand the source code of the softw

e
“ software product.

Scanned by CamScanner
 ■■ En&Mwtoy (MU. ®2fn. n
box J
,fnganrt
— en
’ ter can

n ,«lic,ou, code in the „„„ "

, ■nw sccond step involves " ” “"' w

’'tagU ’nd *’" M
•» •«.
under U.o test rorch >n Whiu '

Wi
' “ — te
fw
------- - Tins “ethod requires pro „,™ ° d ' ” f "’ ft ”"w~l„t
l/htstr
ncture of W,it 01 Sdn 8
' t J ? * »ay be r - bave . . "’ U P ° r in th,
ier test evel
- Thu s 1 «P« S be Mu . B ' 8bo
' lt
-requisite * **nite |Box
for Testing ' are V'»<iuet und ' °V«« have high W

following are the advantai

■hrough the ‘8eS boxtesting;
paths of

testing, - White Box Testing c a n b e ea

*" ughtestin,.
. , . , , PPhedat.
As tester has knowledge n f • .
no
input helps is testing. need to wait for GUI.
sconies
ster to find out which type of
. Whiteboxtestingpe

into it s - Automation of White box tests can. “through finding hidden b,

. White box testing is strict because

ovei
We can start white box testing y state.
»er of module of software is created.

sast Following are the disadvantages of white box testing :

- White Box Testing is complex and expensive process.
at
to perform
exhaustive testing.
e
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.

If white box testing performed by developers who develop code present in software then there is
less possibility to find out development related errors.
, . m.- h Mr testing we need expert persons who have deep knowledge of

Scanned by CamScanner
 Software Testinggd Mai
- Som. 6 • Comp) 6-28

Basis Path Testing

1
7)
IQ. 6.9.1 Explain diffomnl techniques In white box testing. (Hof. see. 6.9) Dec. 15.
— *9.2 Explain Basis Path of Testing, (Rot, sec. 6.9)

Basis path testing is considered as a white-box testing technique.

It was proposed by Tom McCabe. Those tests guarantee to execute every statement in a.
program at least once during testing. Basic set is the set of all the execution paths of a proc du
6
-9.1 Flow Graph Notation

Before basic path procedure is discussed, it is important to know the simple notation us d f
representation of control flow. ***
This notation is known as flow graph. Flow graph depicts control flow and uses the fnl! -
constructs. lowing
- These individual constructs are
a
procedure. Particular

Sequence

Until

While

Case

F
ig. 6.9.1

Scanned by CamScanner
 Er>9,neer,n
' (Mi j . Sorn. R .
f Basic Term.n 01 o 9yossoc(ai .2.-2Q

' ■ --Phnod. ’ Ph .22%:

_ Edge : Edge is U]o «.lo nw)c

control. An edge must tw<) «•* nM, tl) „

Ot
procedural statements. « "oda W„„ n

K,Un,n 1 re
“'>ow sraph . * nt 8nv ,
tf.3 Cyclomatic Comp| exlty bonded by
B 8
and nodeg.

— £! cycio ma fc7 7~~~'— 7—— ____

n
contains control statements " °° °W fr
°“ start to t ,

eK 1
the control statement. ’ ™«on paths depeaLT" ' T“ “
aependmg upon decision taken on
So Cyclomatic complexity
provides a upper bound for number of tests th t «
S mU8 Pr<>dUCed f
path, a test should be conducted to see if > • ‘ °r each
“ an

not. ie
end point of the procedure or

- P foraflowgraphiscomputedinoneofthree.ays:

nUm erS re ons

1. ° °f he flow graph correspond to the Cyclomatic complexity.

2. Cyclomatic complexity, V(G), for a flow graph G is defined as

V(G) = E-N +2

where E is the number of flow graph edges and

N is the number of flow graph nodes.

3. Cyclomatic complexity, V(G), for a graph flow G is also defined as

V(G) = P+1

Where P is the number of predicate nodes contained in the flow graph G.

Example : Consider the following flow graph.

Scanned by CamScanner
 Software Engineering (MU - Sem. 6 - Comp) Software Testing and Maintop
6-30

3
2 5
! 5 6

i 8 10.

I
I: 12.

13.

Fig. 6.9.2
Region, R = 6
Number of Nodes = 13
Number of edges = 17
Number of Predicate Nodes = 5

Cyclomatic Complexity, V( (J)

V(C) = R = 6;
Or

V(C) = Predicate Nodes + 1

= 5 +1 = 6
Or

V(C) = E-N + 2

= 17 - 1 3 + 2 = 6
6.9.4 Deriving Test Cases

’ “r s - - - - -
low
2. Even without a flow grach Vent l

d
— * -e Md z * c0Unting the number of conditionai

Scanned by CamScanner
 „ engineering (MU ■ Sem. e ■ o

3 -Prepare test cases that will ~ --------------------

nt
gi °nancn
llts ha
Graph Matrices - "" Each teat case i,

Gra ph matrix is a two di mensionol

flnd columns. each equal that hcl ps - n ln
a e a ln 6 the basic net. It has rows
j- flow granh
, Entry corresponding to each node-nodo pair rcpr " '
nU n C 1k ! i n
" Each edge is represented by some letter
Vlter t J .
to distintniiah u° r ' ' 1™ graph.
rphen each edge is provided w ui, . other edgeg .
connection. 'ere is no connection and 1 if there is

Seating a connection.

Each row with two entries represents a predicate node.

. Then for each row sum of the entries is obtained and 1 is subtracted from it.

Now the value so obtained for each row is added and 1 is again added to get the cyclomatic
complexify*

Once the internal wording oi me dmerent procedures is tested, tnen tne testing ior '
functionality of program structure is tested. For this black box testing techniques are used.

Syllabus Topic : Control Structure Testing

Bm Control Structure Testing

(10 Marks)

The basis• path

path testing technique which structure
we have testing.
seen in previous

Now we are going to see some other ™na

6.10.1Condition Testing a test-case desig

■obably preceded
J - c— — * National e ressi n
° ’ W

J existing in a P bl,

- *with
- * ; £one
£ * NUiv
J

Scanned by CamScanner
 Software Testing and intn n g n c Q
Sofhvarq Engineering (MU • Scm, 6 - Comp) 6-32

~ A relational expression takes the form

I - l < n‘lntii»n;il-ttj>rrnl<ir> 1.2

where E l and E2 nre arithmetic expressions whereas the <relational-operator> m any one of

In a compound condition elements present are; two or more simple conditions, Boolean operator
and parentheses.
It is considered that Boolean operators which are probably permitted in a compound condition
contains OR ( | ), AND (&), and NOT (-»).
- A condition which does not contain relational expressions is considered as a Boolean expression
If a condition is wrong, then minimum single component of the condition is wrong. Hence, type3 o f
errors in a condition contain Boolean operator errors (incorrect/missing/extra Boolean operate
Boolean variable errors, Boolean parenthesis errors, relational operator errors, and arithmeti
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.

The data flow testing technique opts for test paths of a program based on the placements of
definitions and uses of variables in the respective program.

... -k. h a* . gloW vrtiblii ““

- For a statement with S as its statement number,
o I ....... , . Mni ,_ Jx) M(S) (x j

x
’ “ ■*■"■“ s - >• « — ■■
any other

USE(S the
at statement S’. deft

,h h Du h
““ ■ “ i» — — -
■ XT— .

P and the else part.

Scanned by CamScanner
 Engineering (MU - Sem n .
Cornp)
such cose, the else br n n ( -h 6-33
93ndM ainten
testis «>«
nw
. pTes.mg ‘' —«.u,
1 an
y one Of
con8iderod as the f uni,
X- ° " ti "" mnxir
num Of t .
°Perator s>
aro
op testing is considered testa, they Qr 6 hOt en . * TiU ' rn " in
O8 a wRu u 8llfnr
ld
oonditio validity of loop constructs -box testing . nniqu to
’ ®nt '"Wtano
° .
For loops it is possible to define four d i r " ® ths
aression. nod unstructured
unstniHi, M j i_ unieront cla8SG8, ■
loops, and loops.
e
» types of lmPb 10
° P8 ’ tenated loops, nested
Perators;,
'fthnietic

ation to

Nested loops
its of
Simple loops

Concatenated
loops
?r is
will

Unstructured loops

Fig. 6.10.1 : Classes of Loops

Simple loops : The following given series of tests can be carried out on simple loops, where n is
3
the maximum number of permissible passes through the loop.

1. Skip the loop entirely.

2. Only one pass through the loop.

3. Two passes through the loop.

4. ' m passes through the loop where m < n.

>ted loops, there

N. d loop. : T •»- - » •. —
engineer)
I, ««« » U» " rf B.W «

This would loads » ‘ , a , ,„l«

" p

BcgiO s w® th-

Scanned by CamScanner
 Software Testing and Mainteri -
Software Enqineerinq (MU - Scm. 6 - Comp) 6-34

iowest
2. Carry out easy loop

range or excluded values.

■ 3. Work outwent while executing tests for the next loop, but holding oil other outer l00ps „
minimum values whereas other nested loops to typical
4. Continue the process unless all loops have been tested.
- Concatenated loops : It is possible to test concatenated loops with the help of the opproach
defined for simple loops, if nil of tho loops ore not interdependent.
- However, if there is concatenation of two loops and tho loop counter for first loop i s used as th ,
starting value for second loop, then tho loops ore not independent.
- When there is dependency of loops on each other, then the approach which has been applied 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.

Syllabus Topic : Black Box Testing

6.11 Black Box Testing

(MU - D e c . 16)
Q. 6.11.1 Explain Black Box testing. (Ref, sec. 6.11)
Dec. 16. 5 Marks
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.
It is also known as behavioural testing or specification based testing.
In Black Box Testing we concentrate on inputs provided to software product and output from the

Black „ . pp|M a . tvd

5
X”.; ■ “” ‘•■hni '“ “■ T
-“ <bva>..,.*.1.,,.. c..

Input
Output
Executable
program

Fig. 6.11.1 : Black box testing

Scanned by CamScanner
 ip q (MU- Seal. 6 -Comp) fi . 35

010 St
° PS h
‘tf0 USC<
‘ ‘° PWr
° r,n b,Mk
h'stlng I

the i'eq u ' remcnt9 nn<

’ s P c c *r>cnt ions, of tho system arc analyzed.

ter soleCt VfJid ‘ C S t dftto dnt

“ P0BlUV0 | C 1 MCnrtrln
'' 10
"W-'ic'dion under
, ui 0 to processes that data and give output a s expected.
i is
K
tester selects invalid test data for negative test scenario to verify whether application under
S
' ° s B hie to processes that data and give output ns expected.
te st>

arc run.
goft'v£ire

t . g detected if actual result is not same as expected result.

P6 ducted defect is reported to developer.

S- can then fix that defect and then application is retested by tester.
ne veloPe r
9- . test cases following methods are used in Black Box Testing •
develop S
for
d»ry ValueAlialysis(BVA) of testing boundaries of the input
the name indicates boundary value analysis is a proc
As
values-
. jjjost commonly used technique in BBT.
,, just above minimum, normal value.
' bas ic idea is to select input values at their; mmimu
' value and just below maximum value.

P
•*•*“ - ““X
_ Equivalence class partitmmng
- — -- “
classes. ids red undancy of input values.

81
. BVA and equivalence partitioning
d all the factors that
©Cause ■ effect graphing hip between oul

. This technique graphically. exp

affect the output of system- effect election of test cases such

. This technique tests 0 y effe cts.

that they logically

Scanned by CamScanner
 LJ Software Engineering (MU - Som. 6 - Comp) 6-36 SqftwaroTosting and Malntenar

(iv) Error - Guessing

Error guessing is n technique which makes use of tester*s experience and skill for testing Bimj]a{ .
applications to find out defects which may not bo determined by formal techniques.
It is usually done after formal testing techniques aro applied.
It list outs all possible defects in system and then design tests which will attempt to produce thn
The success of error guessing technique is mainly depends on knowledge and skills of tester.

6.11.1 Types of Black Box Testing

I- Functional testing

Functional testing is a type of software testing which checks that every function present in
software application works as per requirements of user or not.
Functional testing includes black box testing and it does not focus on the source coda
software application. “e
All functionalities of the system are verif
compare actual result with expected result. and
If there is difference between actual result and expected result then bug is detected.
Functional testing is done using Requirement Specification Document.

Non-functional testing

Regression testing

This testing is performed to eiv

added 0Ur Boftware
any interruption in working of existogX tionXZ “ not make

6.11.2

(i) is efficient for large systems.

® I. „ talonal

“ ,D — “
(tv) Tester and developer work independently.

Scanned by CamScanner
 w
~- ft rr
’ Jpisfldvantagcs of Black Dox Testlnn
ra Testing and Mainfnem,
(i) it is difficult to find out all poartbi. input* for

(iD Test method cannot be used far complex mde.

skill for testing Firm J ,r
liques.

mpt to produce them.

Jails of tester.

(MU - Mr/ 1 $, Ur/ 1V,

Cc<npare i.. lw „ wfcgaM b kbox , Mtnq , H<( >n<|
ris.SMam>
parameter
tion present in our White box testing
leVelS
i< able It is mainly applicable at lower
levels of testing :
jource code of the levels of testing i.e. unit and
Acceptance and system testing. integration testing.

Me test data and Requirement specification is the

tS for testing
IP** basis for Black Box Testing. Box Testing.

?d. performed by It is carried out by software testers. | It is carried out by software

developers.

It aims at what functionality is It aims at how system is performing

-'Aim
system performing. its functionality.
lity. Programming knowledge and Programming knowledge and
P quirenients
performance, implementation knowledge is not
necessary to carry outBBT. necessary to carry out V«~BT.

It is less expensive than WBT.

Cost
In white box testing, we test the
ie because of In black box testing, we do not test
Focus on
software pijroduct and flow of control.
functionality of software product
ice that old White box testing
Facility provided facility of verifying communication
among different modules present tn
s not make verifying communication among
different modules present in software product.
software product.

(MU -Way VO
6.12 Software Maintenance

Q. 6.12.1 Writeshortnote

Scanned by CamScanner
 Software Engineering (MU • Sem, 6 • Comp) 6-30
6-38 Software Tasting and Maintonancn

- Maintenance is required to give assurance that the software has ability to satisfy the changing
requirements of user.

such as waterfall, spiral or iterative model etc.

Duo to corrective and non corrective software actions, wo need to make changes in Softwn r(
products.
Following are the needs of maintenance :
To correct the defects found in software product.
2. To improve the design of software.
3. To improve performance of software product.
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 most important part of the financial

resources is spending on
maintenance in a software life cycle.

- - - <— - .. .
ma
" “ agement re orts
P ~

— — — —
impact on
can

‘ heir re
’ atiOnShip t0
maintenance costs includes

> hardware and software.

ludes policies, competition, process, product, and personnel.

□ Requirment

□ Designing

□ implementation

□ Testing

0 Maintaince

ice

Scanned by CamScanner
 Engineering (MU - Sem.
1 L
•« ' - mp)
Th* cost required for Eoftw . ----- 2-L
Maintenar
' the software devo lopment nnne„ --. Tostlnr.
le ere are number of f a c t o r s > w h . ch ’ **
chan S i ns
8OS pha
razors which incpcaBo "'™” «« "r m „ inl(!noncn ' «e8 included
model o,n
/ The standard age of software a
ap t«nanc<,
- Plication • QS8Ula
Soft
gacy software which work o * ed Oa UD
Ware
' pro ve itseff better than new lyc „nn J n ° W Irino. wit „ *° *° W
»•■«.
■ ..... .....
a re costly.
jdost engineers who perfi
to find out problems. Lce ar
e now inn,tp
'- ri «>c«l 0 „<l u a
. nal and error meUKK1

ndOCU ente aU
;“ “ dC -«->-Probte, !rn
in future.
rease Mair,.
maintenance Vost
>ftware.
Programming Language.

- External environment dependencies.

ylabUST
— ° P l C : T v P Jg- ofSoftw
are Maintenance

fj3j[ypes of Software Maintenance

(MU -May 16, Dec. 16)

Ip. 6.13.1 What are the different types of maintenance? (Ref, sec. 6.13) ~
May 16, Dec. 16, 5 Marks

Types of maintenance

1 . Corrective Maintenance |

2. Adaptive Maintenance •

3. Perfective Maintenance -■
....... ■...■...1 ■.........■■ ,.A. ......l.J.J.n I

4. Preventive Maintenance

Fig. 6.13.1 : Types of maintenance

1. Corrective Maintenance
- This type of maintenance contains changes and updation performed for fcdng of defects found in
software preduct that are detected by end user or tester.

Scanned by CamScanner
 corrKt nB ,h0 dcfc in MtkW!,re
! . ? °7
:e8 a:

10 ox
_ XXVXZXl ',m,ne 11,0 originnl
’ pe “”’ *< 8tate that what

omerseneyco Xe ZL UhZ" 1 0 " 1’ relea

« »n>a l I
I'rentypoccentpart of ell the maintenance activities are performed to do corrective
Adaptive Maintenance iance.
This category of maintenance contains making changes in <mfK,

Pr
prod ° dUCt date
' Ada
Ptive maintenance is used to lak mahltain

-
ZTZT ""■*“ w“ 461 06 meanS appIyin
'■«™«-
application which does J.” S changes to component of the software
7 Chang
software application. * some other component of

according to modifications in the

“ “• m u, Mu , n „, wM h

are factors which affect the

significant effect on
To implement this modified .

member countries to make changes

■ — - «... fciw _
p
• changes and updat<;s ’ -ftware useful
« fyandperfonnaoceof -ew user re meuts, _ *

d
Ce« T

Scanned by CamScanner
 Ting (MU • Som. 6 - Comp) 6-41

maintenance includes performing enhancements in functionalities of application

in addition to cnhance tho

P erfonnance software application.
mins enhancement in both functionality and in efficiency of tho source coda and modifying
11
functionalities of tho softwnro application according to changing noeda of urwrn.

rfectiv® maintenance contributes 50% of Intel maintenance which in the Inryrit of nil the
Maintenance activities.

n tive Maintenance
t?c*eV®
4-

plication.
objective is to solvo the problems which are not major at this point but may cause serious
sinfiltUre
' i -
preventive maintenance includes applying changes to avoid the occurrence of errors.

preventive maintenance also includes doing actions to avoid the occurrence of errors.

It tends to decrease the complexity of software application by improving understandability of

rQgrain and growing maintainability of software application.

It includes documentation updating, code optimization, and code restructuring.

Documentation updating includes making changes in the documents which are affected by the
changes related to the present state of the system.
Code optimization includes changing the programs to quickly execute the program or to use

Code restructuring includes changing the structure of program for decreasing the complexity of
source code and making it understandable.
Preventive maintenance is performed only for maintenance organization and no outside requests
are accepted for this category of maintenance.
Preventive maintenance contributes 5% of all the maintenance activities.

Types of Software Maintenance

Perfective Preventive Corrective

r 20% Adaptive
C 50%
25%

Fig. 6.13 J

Scanned by CamScanner
 0-42 Software Tostim

og

Explain sin;

M cnance Jog is n document that records who did what, when, and why.

,y
7„TZk
’ "7 r"' f 7 tro
k performed on "';
,c,hootinB
the system
r c,,rrinii
and
r b
'’ may °shed ° — ’ p***™,
. a , lhey 7
y may hcd h ht
■"'actions tetween aeeming|y onreIii(ed symplonM " « ™ hard-t p*
Maintenance of j-our valued assets is an essential chore to oerform nt i
wouM happen if you own a precious metal ornament " *nlCTVa1 ’-
ill certainly
maintain them on a timely basis. Same is th< you need to
t if they are
To keep an organized mi
ou
r
ou own. can put your

10/23/2016
/Maintenance P ofvafidation
t0
• formed tfy: IValidation performed by. iotenance
... Planned on (datej:

B
“ « ’«“* - P.H.* 7 ‘h ' m
-™- <=» of your

Scanned by CamScanner
 Engineering (MU - Sern Q

in
provide services on contr. «'« « ntr .Soft*,;
!(ntenango With
Generally, maintenance ]OK8 r ,. r the Cflm

sor viee» that it will retain ite P«>venUv ,

i6 j equipment mai„ tenance , og
Design your program " win „ i(|
k
2. Moke the resources read, fo r main ’"*"”"'” ‘“ « :
they
s 3. Outline the cost of mnintononc(j
Pot
Smooth flow of operations with no bug8

iat 5.
ly Emergencies are possible with a maintained <,nv,r
ral pre-designed on-line template «nn>ent.’
io websites offer different categories 6 f r ek
for the Tw ’’h’ ° hing your m ■
9
documents this log in a user-friendly wav J prograT'
---------- --------------------- ™y. Just download the templed
plate
' abus To
Pi Softwa r , and maintain everything
mg
4 Software Re-engineering

(10 Marks) |
mality so that it

- Software Re-Engineering is process of re-structuring nr ™

r .• ... x T-r . . structuring or re-wntmg components of old software
application without modifying its functionality.

It is 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 in 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
was developed, UNIX was re-engineered in C, as writing source code in assembly language and
understanding it become difficult.

Sometimes developers observe that some components of software product require more
maintenance than other components and such components are requiring re-engineering.

Re-engineered
Re-engineering implementation
Reverse software
I Exiting
Engineering planning
software

Scanned by CamScanner
 Software Enqinoprinr- (Mu . _ *
6 - Comp) Software? Testing and

’ccduro includes following steps :

components of so ft wan? we wnnt to re-engineer. Is it complete software
are
-> °r
2. Do Ron
3- Perform
'n -orientej
1711
Restructuring of data if needed.
Use Forward o •
engineering idea to generate re-engineered software.
e important terms used in Software re-engineering.

It is
S ficatiOn by
This T “ ni,I in
K and understanding the existing
e deVe Pment mOde1
phase to -quue mentg “ g X“ '° ’

Exiting r
Reverse Program
software . Engineering Specification

Restructuring of source code

procedure of performing the re-structuring and reconstruction

■_ - ~~ •* - -

e pIatform
structuring. can be decreased with the help of re-
Forward Engineering

hand which“f product from the requirements in

' f‘ZZ"“ - » *. «...

Forward engmeering is similar as software enrin
■t .s always performed after reverse engineering M • Pr0CedUre havin
S ence that

Program
Specifications
from Reverse Forward
Engineering Engineering
software

Fig. 6.143

Scanned by CamScanner
 rnqinesring ( MU ~ S e r n - 6 • Comp) G-45

nCntreUSa
X°
f component is an clement of so
software s y stam *
"’“""’'"'“■A In th.
It may 1x5 a sma11 modul
° or
sub-systcin.

Inearing

< Pearse Engineering

(MU

fl.
Q. May 1 6 . 1 0 Mark"

This procedure can be reverse software development life cycle model, i.e. go from maintenance
phase to requirement gathering phase.
Reverse engineering is the procedure that recognizes an object, a device, or technical properties of
system through analysis of architecture of system, functions and operations.
Consider an existing system has design about which we dp not know anything. System designers
perform reverse engineering by analyzing the source code and attempt to get the design.

With the help of design, designer attempt to make conclusion about' specifications of software
product.
Reverse engineering is a process of analyzing an object to observe how software works in order to
dupl
ing is invented in older industries and now
computer hardware anu ovinv—'- e j nroeram which is in the

- Softwareof the
format reverse
sequence of Os and. . XedZthe’sZrcecode.
the source code of a program since the

_ Software reverse engineering is performedIto « * performance rfa

source code need to study how the pro am P * dete ct unsecure
program, to repair a bug i.e. correct an error
is.
contents from program like virui
Program
Reverse
Exiting
software
Fig .6.15.1:Reverse E ng ineering
Chapter Ends—

□□□

Scanned by CamScanner