W,t~

POPULAR PUBLICATIONS SOTTW ARE ENGINEERING

10. a) What do you understand b th ' or low-level modules, procedures or functions are integrated and then
kinda of system feating that are J.ua~,;•~::t•dm te~ting'? What are the diff All the bottO~ . t gration testing of lower level integrated modules, the next level of
e on arge software PrOducts;rer,t tested. Afl~rl tb: ;~~ed and can be used for integration testing. This approach is helpf~I
Answer: [MODEL QUEST
111 odules wil t of the modules of the same development level are ready. This
System testing of sofh\.are or hard . . . ION] hen all or mos d k . . t
t \\are 1s testmg conducted only w h s to determine the levels of software developed an ma es 1t easter o
sys _em to evaluate the system's compliance with i . on a co~plete, integrate thod also e Ip
rne . rogress in the form of a percentage.
testing falls within the scope of black b . . ts specified requirements. Sys1 d repart te 5Unf ~ting is an approach to integrated testing where the top integrated modules
knowledge of the inne: design of the code o;:~~:.tmg, and as such, should require:: Top Dowdn : the branch of the module is tested step by step until the end of the related
As a rule, system testing takes, as its input, all of the "i " are teste an
~at have s~ccessfuJly passed integration testing and ~lt:f:~:d s;oflware components ' rnodul~-h Testing is an approach to combine top down testing with bottom up testing.
mtegrated with any applicable hardware system(s). The purp f ~are ~ystem itself sandwi~ dvantage of the Bottom-Up approach is that bugs are more easily found. With
to detect any inconsistencies between the software units t~s~ o 1~tegrat1on testing is The main a . . . . .
Top-Down, it is easter to find a missing branch lmk.
~called asseT?b(ages) or between_any of the assemblages and th: h:;:w:r:g~ated toget~er
is a more l!m1ted type. ot: testing; it seeks to detect defects both wi~hi ystem '.~sting ) What la unit testing & what errors are found during unit testing?
assemblag~ and also within the system as a whole. n the inter- ~1·;•scribe McCall's Quality Assurance Factors.
The follo~ng examples are different types of testing that should be consid d d .
System testmg: ere urmg
c: What I• symbolic execution? Consider the following function:
function product (x, y, z: integer) : Integer;
- GUI software testing var t1 , t 2 : Integer;
Usability testing var prod : integer;
- Performance testing begin
- Compatibility testing t1: • X • y;
tz: • y • x;
Error handling testing prod : • t 1 • tz/y;
Load testing end;
Volume testing Give the symbolic execution of the above function. [MODEL QUESTION]
Stress testing Answer:
Security testing a) Unit Testing:
Scalability testing In computer programming, a unit test is a procedure used to validate that a particular
Sanity testing module of source code is working properly. The procedure is to write test cases for all
Smoke testing :iinct!ons and methods so that whenever a change causes a regression, it can be quickly
identified and fixed . Ideally, each test case is separate from the others; constructs such as
Exploratory testing
mock objects can assist in separating unit tests. This type of testing is mostly done by the
Ad hoc testing developers and not by end-users.
Regression testing
Reliability testing Advan~age of unit testing:
Installation testing • Unit tests can provide quick feedback to the developer.
Maintenance testing • Un!t tests can simplify the structure of the system . .
Recovery testing and failover testing. Un~t tests can mitigate concerns about the effects of refactoring.
• Un~t tests can be used to validate code integration.
b) What is the difference between the top-down and the bottom-up integration Unit tests may result in more testable code.
testing approaches? [MODEL QUESTION] • Un!t tests can document the code they test.
Answer: . . west level • Un~t tests are typically inexpensive to run and maintain.
Bottom Up Testing is an approach to integrated testing where th e 1O ts. Unit tests report serious problems early.
·
components are tested first, then used to facilitate t h e testing o fh'igher level componen
The process is repeated until the component at the top of the hierarchy is teS ted.

SWE-102 SWE-103
POPULAR PUBLICATIONS SOITW ARE ENGINEER ING

b) Softwart Quality Factors/Goals:

Utillly/Corr«tn~s: extent to which program satisfies specifications (presence
of
SOFTWARE PROJECT MANACEMENT
function)
JMlabllty: precision with which program perfonns as expected (absence of
ModlJiabilily: effort required to modify
failure) -- [ Multiple Choice Type Questio ns !
Maintainability: effort required to locate and fix errors [WBUT 2017]
e maintenance includes .
1. SoftWar _ eventing maintenan ce policy for servers
Stturlty: extent to which access is controlled a) setting pr ·t
tallation of sottware at s1 e
EjJiciency: amount of computing resources required b) Ins . ing of sottware for maintenan ce purposes
c) oes1gn
Usllbllty: effort required to learn, operate, and interpret behavior d) sug fixing
Ttslllbllty: effort required to test
Answer: (d)
lnltroptrability: effort required to couple to another system
Portability: effort required to transfer to different environment
Rtusability: extent to which program can be used in other application
s
2
· :r
E anded form of the term HIPO is
Hierarchical Input Process Output
c) Huge Input Process Output
[WBUT 2019]
b) High-leve l Input Process Output
d) none of these
c) In computer science, symbolic execution (also symbolic evaluation Answer: (a)
) refers to the
analysis of programs by tracking symbolic rather than actual values, a case
of abstract
interpretation. The field of symbolic simulation applies the same concept 3. Software consists of . [WBUT 2019]
to hardware. a) Set of instructio ns + operating procedure s
Symbolic computation applies the concept to the analysis of mathematical expression
s. b) Programs + document ation + operating procedure s
Symbolic execution is used to reason about all the inputs that take the same
path through c) Programs+ hardware manuals
a program. d) Set of programs
Answer: (a)

4. SRO stands for

[WBUT 2019]
a) Software Requirem ents Definition
b) Structured Requirem ents Definition
c) Software Requirem ents Diagram
d) Structured Requirem ents Diagram
Answer: (b)

S. Which of the following primary objectives have to

be achieved for the
requirement model?
[WBUT 2019]
a) To describe what the customer requires
b) To establish a basis for the creation of a software design
cd))To define a set of requireme nts that can be validated once
All of these the software
Answer: (d)

6· From the
following
software product? which quality deals with maintainin g the quality of the
a) Quality assurance [WBUT 2019]
c) Quality efficiency b) Quality control
Answer: (b) d) None of these

SWE-104 SWE-105
WWW

POPULAR PUBUCATIO~ SOFTWARE ENGINEERING

7 _Which quality deal• with the maintaining the quality of the •oftwa t by unauthorized persons
a) Quality a..urance b) Quality control re Product? t to which access to software or d a a
_ ,,,egrity: The exten d
c) Quality efficiency d) None of these tweur 2019 4 1
can be controlled. . d I arning operating, preparing input for, an
Answer: (b) I 5. Usability: The effort require e '

Short Answer Type Questions J interpre~ing ?~t~u~t a t~~:;~ired lo locate and fix an error in a program. This
6_ Mai11ta111ab1/tty. e ~.
. very limited definition. .
1. a) Define software quality. ; ; ibility: The effort required to modify an operational program._ fi rms its
b) Briefly explain McCall's quality factors. [W~u~013, 2015] 7. Te::Obility: The effort required to test a program to ensure that it per o
Answer: 8.
. . BUT 2013] intended function. fi h dware and/or
•) Software quahty 1s the degree of conformance to explicit or implicit re . Portability: The effort required to transfer the program rom one ar
expectations. .· qu,rements and 9
· soft ware system environment to another. .
Reusability: The extent to which a program [parts of a program] can _be reused tn
b) The factors that affect software quality can be categorized in two b d 10
· other applications - related to the packaging and scope of the funct10ns that the
Factors that can be directly measured (e.g., defects uncovered during ;:at_ gr)oups: program performs. .
. d" s mg
Factors th at can be measure d on Iyin 1rectly (e.g., usability or maintainabilit ·) 1J. l1tteroperability: The effort required to couple one system to another.
ln each case measurement should ?ccur. W~ ~ust _compare the software (pr~~
documents~ to some datum and arnve at an 1nd1cat1on of quality. ams, data, 2. Why Project Planning is needed? Draw the diagram for precedence ordering
McCall, Rich_ards, and Walters prop~se a useful categorization of factors that afti among planning activities. (WBUT 2017]
software quality. These software quality factors, focus on three important as ect Answer:
software product: pects of a Project planning is part of project management, which relates to the use of schedules
1. Operational characteristics, such as Gantt charts to plan and subsequently report progress within the project
2. Ability to undergo change, environment.
3. Adaptability to new environments. Project planning is often used to organize different areas of a project, including project
Ma1ntatnab1hty
plans, workloads and the management of teams and individuals. Project planning is
Portability
Flcx1b1hty Rcusab1hty inherently uncertain as it must be done before the project is actually started. Therefore the
Tcstab1l11y ln1eroperab1l1ty duration _of_th~ tasks is often estimated through a weighted average of optimistic, normal,
and pess1m1st1c cases. Float or slack time in the schedule can be calculated using project
PRODUCT REVISION ma~~gement software. Then the necessary resources can be estimated and costs for each
PRODUCT TRANSITION acu_vity can be allocated to e_ac~ resource, _giving the total project cost. At this stage, the
project sched~le may ~e opt1m1zed to achieve the appropriate balance between resource
usage and project duration to comply with the project objectives.
Correcmess Usability Efficiency Precedence Diagramming Method (PDM)
Rehab1hty Integrity

Referring to the factors noted in Figure above McCall and his colleagues provide the
following descriptions:
1. Correctness: The extent to which a program satisfies its specification and fulfills
the customer's mission objecJives.
2. Reliability: The extent to which a program can be expected to perfonn its
.
~-
intended function with required precision. (It should be noted that other, more
complete definitions ofreliability have been proposed.
0--+~'
8 Acttv111cs with 13 dependencies
J. Efficiency: The amount of computing resources and code required by a prograll1
to perform its function .

SWE-106 SWE-107
POPULAR PUBLICATIONS SOFTWARE ENGINEERING

The PDM diagram in the figure above shows eight planning_ a~~ivities, labe_led
A-1-l. The
arrows show how some activities are dependent on othe_r act1v1t1es. E.g. activity
B cannot
start until activities A and C are complete. To show this dual dependency,
an arrow can
be drawn from A to B and another arrow from C to B.
d by someone deliberately trying to cause a fat·1 ur e in the system. Some of
also b~ c;:~es of failure may be described as foll~~s: ·gn and manufactu
ring errors or
the rnaJO ware failure: Hardware fails because o . est
I life

There are four types of dependencies with a PDM diagram:

• ~:C~~se components have reacht~l th~ end t~f~~~;a~ ~raits s~ecification, design
Software failure: Software at s ue or
• Finish-to-start (the most common dependency typ_e):-The successor • implementation.
activity's
start depends on the completions of the successor act1v'.t~. erational failure: Human oper~tors ma_ke mis . takes Now perhaps the largest
.
• Finish-to-finish-The completion of the successor activity depends • Op f t m failures in soc10-techmcal systems. .
completion of the predecessor activity.
on the single cause o sys e I "bug" is a mistake that may cause a failure. It .ts
A sof~~re fault, :e:~~: c~;r:;r~ to fail t~ perfonn its required
• Start-to-s tart-The start of the successor activity depends on the
start of the function. Failures are
predecessor activity. a cond:tn th:~~t of system errors that are derived from faults in the system._
. . Howe~er~
• Start-to-finish-The completion of the successor act1v1ty depends a usua y a r\ecessarily result in system errors if the erroneous system
on the start of state ts transten
the predecessor activity. faults do :~correcte d' before an error arises. Errors do not necessarily
lead to ~ystem
an_d can 'f the error is corrected by built-in error detection and recovery
failures 1 . mechanism. In
3. What do you mean by an object lifeline and focus of control ·fi d
order to achieve the reliability the faults can be classt te as 10r ll •
and which diagram ows. . . . .
is It ,-qulr9d and why? • Fault avoidance: Development technique are used that. either.
[WBUT 2018] mtn•mt~e the
Answer: possibility of mistakes or trap mistakes before they result tn the introducti
In UML diagram, such as sequence diagram requires the object lifeline on of
and focus of system faults .
control. .
Fault detection and removal: Verification and validation techmques
In UML diagrams, such as sequence or communication diagrams, object t~at incre~se
lifelines the probability of detecting and correcting errors before the system goes
represent the objects that participate in an interaction . For example, in a ban_ki into service
ng sce~ario, are used.
lifelines can represent objects such as a bank system or customer. Each • Fault tolerance: Run-time techniques are used to ensure that system
mstance tn an faults do not
interaction is represented by a lifeline. result in system errors and/or that system errors do not lead to system failures.
focus of control (FOC) is used in sequence diagrams to show the period
of time during
which an object pcrfonns an action. FOC is rendered as a thin, rectangular b) Explain the Boehm software quality model with the help
object that sits of a block diagram.
on top of object lifelines. The top of the FOC rectangle coincides with the
receipt of a [WBUT 2016]
message. Answer:
Boehm model was introduced in the year of 1978. The model 1s used
4. Explaln about software quality assurance. to represent a
[WBUT 2019] hierarchical model that structures around hi gh level characteristics intermedia
Answer: te level
characteristics, and primitive characteristics. All of these together
Rt/tr to Question No. 6(a) of Long Answer Type Questions. establishment of a high quality software model. results in to
The model defines the quality of software on the basis of a set of
credentials and
Long Answer Type Question s measurements. lt _is _als? elucid~tes a model of soflware quality characteri
stics. The high
level of cha~acte~1~t1cs 1s made in such a way that answers following questions:
1. a) What la software failure? How is it related with fault?
[WBUT 2016]
• As-1s_ uttltty: It defines the way a utility signifies the as-is utility.
Answer:
It creates a
que~t10~ of_how easily, reliably and efficiently an as can be utilized.
A software failure is a deviation between the specified and the actual behavior. • Mamta1nab1lity: This aspect decides how convenient it is to understand
l_n _other or re-evaluate a process. change
words, the software does not do what the requirements describe. More precisely '
it is t~e
inability of a system or component to perform required function according • Po~ability: This aspect helps in deciding an effective way to
specification. to its environment. change an
Failures may also arise because of human error in interacting with the software, Ta~~~~tet:~diate level o~ c~aracteristics represented by the model displays
perhaps a seven quality
wrong input value is being entered or an output being misinterpreted. Finally follows: altogether s1gn1fy expected quality from a software system. These are
failures may as

SWE-108
SWE-109
 POPULAR PUBLICATIONS
50FfWA RE ENGrNEERlNG
• Flexibility: It is very easy to amend the software
as per the re .
~aran:iete rs of the software should be so flexible that they can react
s1tuattons. onquirement Device efficiency
numeroUs ~- Accessibility_
• Reliability: Software performance should be reliable
should be accurate. with zero defe · communicat!veness
cts. Result 9JO.
• Portability: Software can run on different compute Self-d~~cript1veness
windO\~S. r' program
example Dos, ! I . 1.,egib1ltty . .
• Efficiency: Practical & efficient use of resources or 12. Augrn~ :i:t~~ created after doing improvements
utilization ofresources should be made. data coll d . in McCall software quality
ecte · Opttmun, The Boehm tered few errors in it. This new model of
Boehm was found to b~ more
• Testability: Software should be tested easily and model ~ncoun. . laced in hierarchical order. The order
as a result users can . begins with addr~ssmg the
check that the r~~ul~ are correct so that the( can rely on int:resung as it ?rte end-users. On the contrary, the bottom
res 411 blindly. easily of the hierarchy displays the
• Understand~bility. Software should be simple rnaJor concerns o
they can use It properly and efficiently. to understa nd for user • ally inclined personnel.
techntC d focuses on . . .
measuring properties and charactenst1cs
s so that m such a way that create
• Usability: Users can apply it easily and comforta
bly. The ~o eI d non-technical stakeholders that are involved
in the lifecycle of sofu.vare. As
comp exdanto McCall model this model is used in a widespr
compare ead manner because of its
bottom 10 top approach of software' .
quality. . .
Even though this software quality model overcomes the
shortcommgs of vanous olden
software quality models and as it provides a basic amount
of support by following a top
down approach to quality of software, this model is
also short-lived as far as a solid
software quality testing is expected to be.

2. Suppose you are the Project Manager of

a Software Project that consist s of
following Activities in the table and you have
to draw the activity networ k and find
the critical tasks of the project.
D'!w the Gantt chart of the Project. (Consider
Resources allocati on will start from
Gcncnl Lolrty 12 March, 2010.
[WBUT 20 17]
Activity Activity Name Duratio n Immedi ate
No.
(weeks) Predec essor
1. Obtain Require ments 4
2. Analyze Operati ons 4
3. Define Subsys tems
2 1
4. Develop Database
5. 4 1
Make Decisio n Analysi s
6. 3 2
Identify Constra ints
7. 2 5
Build Module 1
8. 8 3,4,6
Build Module 2
9. 12 3, 4, 6
Build Module 3
10. 18 3,4,6
Write Reoort
11. 10 6
The factors can result into creation of other measurable Integrat ion and Testina
properties. These are as follows: 12. lmolem entation 8 7,8,9
I. Device Independence Aosw er: 2 10, 11
2. Accuracy
3. Completeness
4. Robustness
5. Consistency
6. Accountability

SWE-110 •
SWE-111
 POPULAR PUBLICATIONS
SOFTWARE ENGINEERING

Task Name
•/:r~t• S~rt
Fin ish
Pr~de:cC!.Ss0r4
MS project the cnuca .
. . I path may be derived asper the d',agram below:
;' - - - - . ~
obtain
requirement
4 wks Fri ll-03-10 Thu 08--04-10 A5per : ~ ~
Analyze 4wks Fri 12-03-10 Thu 08-04-10
-operations
Define
Subsystems
Develop
2wks Fri 09-04-10 Thu 22-04-10 1
~1i
4wks Fri 09-04-10 Thu 06-05-10 1
Database
Make decision 3wks Fri 09-04-10 Thu 29-04-10 2
Analysis
Identify 2wks Fri 30-04-10 Thu 13-05-10 5
Constraints
Build Module 1 8wks Fri 14-05-10 Thu 08-07-10 3,4,6
Build Module 2 llwks Fri 14-05-10 Thu 05-08-10 3,4,6
Build Module 3 18 wks Fri 14-05-10 Thu 16-09-10 3,4,6
write Report lOwks Fri 14-05-10 Thu 22-07-10 6
Integration and Swks Fril7-~10 ·Thu 11-11-10 7,8,9
Testing
Implementation 2 wks Fri 12-11-10 Thu 25-11-10 10,11

; .,,
--------------------------- ------------- ----·············--- --------------- ---- ---------- --- -- ----- -------------- --- ----- -------
The Gantt chart of the Project is

List of paths:
l. ,S-1-3-7-11-I2 =4+2+8+8+2=24 Wks
2. S-1-3-9-ll-12 =4+2+12+8+2=28 Wks
3. S-1-3-8-11-12 =4+2+f8+8+2=34 Wks
4. S-1-4-7-11-12 =4+4+8+8+2=26 Wks
5. S-1-4-9-11-12 = 4+4+18+8+2=36 Wks
6. S-1-4-8-11-12 =4+4+12+8+2=30 Wks
7. _S-2-5-6-7-11-12 =4+3+2+8+8+2=27 Wks
8. S-2-5-6-9-11-12.=4+3+2+18+8+2=37 Wks
9. S-2-5-6-8-11.-12 =4+3+2+12+8+2=3 l Wks , . . T tal
The path '8' is the longest path of the project i.e. the critical path of the p~oJe~t. . : at
duration alongJ he critical path is 37 weeks. It starts at 12/03/10 and will ,nis
25/11110.

S.WE-112 SWE-113
 POPULAR PUBLICATION S ~
is to
3. Consider the following c program· . com uted statistically from the code_. The goal
Int Compute_gc d (x, y) · CWeur 201~ ce code, These metnc~ a:~ so~are and the relations between them.
lntx, y: ,
( sour. easurable properties d N 1+NZ
identilY m th (N)· The length of your program, compute .
while (xi= y)
If (x > y) then X = X - y; b) Halstead Len~e-abov~ Halstead Length is 39
else y = y-y; AS per 0 ur examP
return x;
} .
tJalstead Vofurne
a) Find out the estimated length p - N is program!bengt~ operators NI + total number of operands NZ
Time. Comment on the techniqu~ t~:ram vocabulary, Program vol
b) Compare Ha/stead's length and volf;u use to solve t~e problem~me, Effort, N "" total num er o . . d n2
·
Answer: e measures of size with th eLoc . rogram
n is P · vocabulary
fd. (net operators nl + number of distinct operan s
. N""numbero is I
erands are: measure.
a) List of operators and O
ccurrences L;,t•'J"1;:.,~~~~moog oil metrics ,v,;J,ble to e,Hmoto project ,;ze. This metric ;s
2 LO is u~ar because it is the simplest to use. Using this metric, the proJect size ,s
I X ;:l%:t~~ by counting the number of source instructi~ns _in_ the developed progr~-
y Ob · usly while counting the number -of source instructions, Imes used for commenting
the ~1ide ~d the header lines should be ignored. Dete~nin? the LOC count at the end of
a project is a very simple job. However, accurate estuna~ion of the LOC count at the
beginning of a project is very difficult. In order_ t? estimate the ~OC count at the
beginning of a project, project managers usually d1v1de the problem mto 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.
Lines-of-code (LOC) metrics offer a gross measure of code, but do not measure content
well. However, LOC in combination with Halstead measures may help relate program
Else size to functionality
Return is a
4. ~) What do you mean by forking and joining in Activity Diagram? What

ri2=2 sw1mlane?
f'll=15 Nl=24 b) What are extend and include in use case diagram?
c) W~at ~re dependency, aggregation and composition in use case diagram?
Explain with example. [WBUT 2018]
Program length: N=Nl+N2=3 9
Answer:
Program vocabulary: TJ = TJ I + T]2 = 17 a) I" Part:
Estimated length: =15 logi 15+ 2 log2 2=62 usednode
isFork .
to s islita icontrol. no det h~t has on~ mcommg . and multiple outgoing edges and
. e~ge
Pr~g. Volume V=N*log2 T]=39x log2 (17) = 39x4.087=159.411 bits to support pa l~?m1~g flo~.1~to multiple concurrent flows. Fork nodes are introduced
Estimated program leve1=(2/T] I )x(T]2/N2)=(2/15)x(2/l 5)=0. J333
model unreft~:te~ ';:.:~e~f:::t1e s. As compared to UML 1.5, UML 2.0 activity forks
Effort:=V/ Estimated program level= 159.41 1/0.1333= 1195.88
notation . a single
for a fork .n0 d_e .is a rme segment with .. edge entering it and
. activity
Time= E/6=(1195.88/18) [*B=I 8 give best result in Halastead 's experiments] The or
two more edge
'
1977 s 1eavmg 1t.
=66.44 Seconds ·
HalS tead complexity measures are software metrics introduced by Halstead in as
part of his discourse on establishing an empirical science of software development. r~e
HalS!ead measures are based on four scalar numbers derived directly from a programs SWE-115

SWE-114
 POPULAR PUBLICATIONS ~
~

E ~• ~ e "Perfonn medical te~ts"

Join node is a cont~ol ~ode t~at has multiple incomin~ edges and o·ne outgoing ed . I of an extend relationship between tthe "Perform Pathological
is used to synchronize mcommg concurrent flows. Jom nodes are introduced ge and figure shows..3n ;;:~=thological Tests" (chi ld) us~ casf~s~ medical tests" use case.
parallelism in activities. to suppon (parent) and Per hances the functionality of the Pe~ specialized version of the
The notation for a join_ node is a line segment with several activity edges enterin . Tests". use ~fee "~rforrn Pathological Tests" use case is a
g 11, and

3~
only one edge leavmg 1t. . Essen_tt~!IY;rforrn medical tests" use case.
generic p asses where one class depends on
. endeocy is defined as a· relation between tweon~lon th~ first class. So any change in

one of the classes may ect t e

~;~e
;~~~~r class but anotheaffirclass {;afu~~t7~~::;t~~ other class that depends on the first
.
2• d Part: A swi'.111ane (o_r ~win:ilane _diagr~) is used in process flow diagrams one. . as association but with an additional point that th~re is an
'flowcharts, that visually ?1stmgu1shes Job shanng ~nd resp~nsibil ities for sub-proce;s or Aggreg~tion is th~ same unlike association where there was no ownership of the
ofa business process. Sw1mlanes may be arranged either horizontally or vertically. es ownershtp of the i~st3:1cels, eferred to as a Weak Association and is represented by the
instances. Aggregation IS a so r . . t t
b) Includes . following symbol in UML representation: let's add another class named Departmen °
In on: forr:1 of interaction, a given u~e cas~ may include an~ther. "Include is a Directed our example explained above. · h
Relationship between tw? use cas:s, 1m~lymg that the behavior of the included use case The relation between Teacher and Department then conceptually, a Department can ave
is inserted into the behavior of the mcludmg use case multiple T~achers associated with it but each Teacher can belong to only one Department
An include relationship is depicted with a directed arrow having a dotted line. The lip of ata time.
the arrowhead points to the parent use case and the child use case is connected at the base Composition is a special case of aggregation . [n more specific manner, a restricted
of the arrow. The stereotype "<<include>>" identifi es the relationship as an include aggregation is called Composition. When an object contains the other object, if the
relationship. contained object cannot exist without the existence of container object, then if is called
Composition.
Make
Example: A class contains students. A student cannot exist without a class. There exists
Appointment composition between class and students.
<<fnclude>> 5. 1:he following table indicates the various tasks involved in completing a software
.. proJect, the corresponding activities and the estimated effort for each task in
person-months·

~
[WBUT 2 0191
Notation Activity Effort in person-
months
Fig: An example of an include relationship T1 Reauirements Specification 1
T2 Desian
Extends . th This T3 ' 2
In another form of interaction a given use case (the extension) may extend ano er: th Code actuator interface module 2
T. Code sensor interface module
relationship indicates that the' behavior of the extension use case may be inserted '" e 5
Ts Code user interface part
extended use case under some conditions. d I' 51
•milar to T& 3
Code control processina cart
An extend relationship is depicted with a directed arrow having a dotte me, and the _T1 1
Integrate and test
the include relationship. The tip of the' arrowhead points to the parent us~:~:tend>>" _Te 6
Write user manual
child use case is connected at the base of the arrow. The stereotype 3
identifies the relationship as an extend relationship, as shown in the figure.
SWE-117
SWE-116
►
SQFffi'ARE ENGINEERING
POPULAR PUBUCATIONS

The precedence relation r, ? {7j , TJlmpliH that the tasks T, must complete rt ~otes on the following : [WBUT 2018]
either taaka 7j or Tk can start. The following precedence relation Is known t befor1
among different taaka T1 ? Tz ? 0
hold !i Write sho
Quallty Assurance
[WBUT 2019]
[WBUT 2019]
{Tj, r., T5 , T.}? Tr b) UML diagrams d I of software development
a) Draw the Activity Network and the Gnatt chart representations for the project c) Incremental mo e
Answer: ·
The following precedence relation is known to hold among different tasks: ~o~::~ity Assurance Factors: h' h program satisfies specifications (presence of
a Tty/Correctness: extent to w ,c
T 1 <= T2 <= {TJ, T., T5, T6} <= T,<= TB 1
' {}' This notation of task indicates parallel activity UU • d( b ce of failure)
funcuon) . . with which program perfonns as expecte a sen
Reliability: prec1s10n . 'fy
ifiability: effort required to modi
Activity Network Mod . bTty· effort required to locate and fix errors
Maiot_a,~a ~~nt ·to which access is controlled
Secu~i:~ : amount of computing resources required .
~:~•i~ity\ffort requir~d to learn, operate, and interpret behavior
Testabili ty: effort required to test
7 IJ
IJ 16
Interoperability: effort required to couple_ to another ~ystem
Portabili ty: effort required to transfer to different ~nv1ronment. .
8 Reusability: extent to which program can be used m other applications.

b) UML Diagrams: Refer To Question No.3 of Short Answer Type Questions.

2 J

c) Incremental model of software development: . . . .

Incremental Model is a process of software development where requirements d1 v1ded into
Critical Path is: TI-T2-T4-T7-T8=16 months mul tiple standalone modules of the software development cycle. In this model, each
[As the question does not demand activity wise slack time, the backward is not drawn] module goes through the requirements, design, implementation and testing phases. Every
Gantt chart (Unit in Month) subsequent release of the module adds function to the previous release. The process
fr,7r=- I
r
1
11 continues until the complete system achieved.
T2 ..... Design&

-- development Testing lmplementauon

TJ 1-

r.
T5
Budd 2
T, ,_ Requirements 1-..~---o.J Design&
development Tesung lmplementat1on
T,
T,
le R I T I C A L p A T H
-
.
Design &
1 2 3 4 5 6 7 8 9 JO 11 12 13 u 15 16 development Testing lmplementat1on
-
Fig: Incremental model

SWE-119
SWE-118

ti,_
- - - - - - - - - - ---.--.......~
POPULAR PUBLICATIONS
SOFTWARE ENGINEERING
Phases of incremental model are as follows:
. . In today 's information
1. Requirement analysis: In the first phase of the incremental model th
analysis expertise identifies the requirements. And the syste~ ~ pr~duci
. s:;~;i:;e
d to construct software intensiv~ development in short
tJML is primarily us~he need for efficiency ~d r~p;, ge Building complex softwa:e
requirements are understood by the requirement ·analysis team. To dev ntt 1ona1 technology _indu~~;become a programmer'.s ma1~ ~ti~iz~~g
eriods of t11:1e ifficult process and learn mg an .
UML assists the developer m
software under the incremental model, this phase perfonns a crucial role. e op the
2. Design & Development: In this phase of the Incremental model of SDLc p lications is ad hr u h . re represented exactly
design of the system functionality and the development method are finished' t_he a~:ing these processe~ tm~d; u·p of objects and messages. ObJ ects ~es with the underlined
success. When software develops new practicality, the incremental model W1th s e diagram is I UML di agrams-as rectang b I w
A sequenc been represented in al diagram is shown in fi gure e o .
style and development phase. Uses hoW they hav~ . the rectangle. A skeleton sequence . .
class name_w1thm h of these elements in the next s~ect1on.
3. Testing: In the incremental model, the testing phase.checks the performan
each existing function as well as additional functionality. In the testing phas ce
various methods are used to test the behavior of each task.
t
e, t e
We shall discuss eac ~----i

I
Object

4. Implementation: Implementation phase enables the coding phase of th ~ :XYZ

.
:LM:N

r \
development system. It involves the final ~odin? th~t design in the designing an~
development phase and tests the functionality m the testing phase. After
i
i
completion of this phase, the number of the product working is enhanced and
upgraded up to the final system product Syncht~nous call

W----t t - - - -.,...
When we use the Incremental Model?
When the requirements are superior.
A project has a lengthy development schedul e.
When.Software team are not very well skilled or trained.
\ Asynchronous coll
When the customer demands a quick release of the product.
You can develop prioritized requirements first. 8. a) What are the different elements of o b.Jeet mod eI? Describe each of them

Advantage of Incremental Model briefly.

b) What is UML? [MODEL QUESTION]
Errors are easy to be recognized.
Easier to test and debug Answer: · h h k' d f
a) There are five main kinds of programming styles, listed here wit t e m s o
More flexible. abstractions they employ:
Simple to manage risk because it handled durins its iteration. · 1. Procedure-oriented Algorithms
The Client gets important functionality early. 2. Object-oriented Classes and objects
3. Logic-oriented Goals, often expressed in a predicate calculus
Disadvantage of Incremental Model 4. Rule-oriented If-if1en rules
Need for good planning 5. Constraint-oriented Invariant relationship
Total Cost is-high. There is no single programming style that is best for all kinds of appl ications. For
Well defined module interfaces are needed. example, rule-oriented programming would be best suited for the design of a know ledge
base, and procedure-oriented programming would be best fo r the design of computation-
7. What'·s UML? What is the purpose of UML? Briefly explain the 'Seque;~~ intense operations. From our experience the object-oriented style is best su ited to the
Diagram'. [MODEL QUESTI
broadest set of applications; indeed, this programming paradi gm often serves as the
architectural framework in which we employ other paradigms.
Answer: . . • nd des ign language Each of these styles of programming is based on its own conceptual framework. Each
UML (Unified Modeling Language) is an obJect-onented ana 1~sis a d . the software requires a different mindset, a different way of thinking about the problem. -for all th ings
defined by the Object Management Group (OMG). UML is use h':al designation object-oriented, the conceptual framework is the object model. There are fo ur major
.
engmeenng. field and describes
• a program~mg · language used model)
as a grap 1 · elements of this model:
to create an abstract model that can be used m a system (UML ·
SWE-120 SWE-121
 POPULAR PUBLICATIONS soFIWARE ENGINEERING

I. Abstraction
2. Encapsulation
.
Represents an e
J
xternal person or entity that interacts
User
Actor
3. Modularity
4. Hierarchy
By major, we mea~ that a model with?ut any one of these elements is not object-or·
There are three maJor elements ofObJect Model: _ 1entect.
Objecl
with the system

Represents an ob;,ct
components
, ;n the system o, on, of ;1, ~St"'."' l
I. Typing
2. Concurrency
3. Persistence
By minor, we mean that each of these elements is a useful, but not essential Part f
object model. . ' 0 the
Unit

Separator
Re resents a subsystem, component, unit, or oth;;
loJcal entity in the system (may or may not
implemented by objects)
Represents an interface or boun?ary betwee_n
El
Separator

Without this conceptual framework, one may be programming in a language h subsystems, components For units (e.g., alf I
Smalltalk, Object Pascal, C-H-, Eiffel, or Ada, but your design is going to smel~u \ as interface, Internet, network)
FORTRAN, ~ascal, ofC application. 11 ea Groups related header elements into subsystems ~r
Group
components
b) !he Unified Model in~ Langu~ge ~ ) is_ a sta~dard language used for modeling the
various components, their behavior, their relat1onsh1p and _the way they interact within the
so~are system or any other non- software systems. These components are used fo
visualizing, analyzing and documenting the artifacts of the software system. The UM~ Sequence Diagram Body Elements
represents a -collection of best engineering practices that have proven successful in the Action ·I
Represents an action taken by an actor, Act)on I·
modeling of large and complex systems. That UML plays a significant role in software object or unit ·
development process, because it uses graphical notations to express the modeling of
software projects.
Asynchronous
Message
An asynchronous message between . -I Asynch Message
header elements ~I-
·(i ~~~~~c~y:1_~~~~~ .
\j ..............I. .
Block A block representing . a loop or ..
9. Define the following terms: '[MODEL QUESTION]
i) Sequence diagram
ii) Links :~,~~~~n.al foe a partocula, headec .
iii) State chart diagram
iv) Collaboration diagram Call Message A call (procedure) message between . ·I Call Message
Answer: header elements
(i) Sequence Diagram: CreateMessage A "create" message that creates a header I
Create Message ;

*.
UML sequence diagrams are used to represent or model the flow of messages, events and element (represented by lifeline going · ·f - - - - - - - - ~ ~ .. ·
actions between the objects or components of a system. Time is represented in the from dashed to solid pattern)
vertical direction showing the sequence of interactions of the header elements, which are Destroy Element Represents the destruction of a header ..
displayed horizontally at the t9p of the diagram. . element i
Sequence Diagrams are used primarily to design, document and validate the architecture,
interfaces and logic of the system by describing the sequence of actions that need to_ be
Destroy Message
Represents the destruction of a header I
Destroy Message
element as a result of a call from another· · ·f----------,K ·
, I,
performed to complete a task or scenario. UML sequence diagrams are useful _desi~ element !
tools because they provide a dynami_c view of the system behavior which can be difficu t Diagram Link
to extract from static diagrams or specifications. ft e Represents a portion of a diagram being 1' :
treated as a functional block. Similar to a · ·c.,- -__L_in_k_ _ _ _l ..
Although UML sequence diagrams are typically used to describe object-orient~d so war
systems, they are also extremely useful as system engineering tools to design syst
· b usmess
arc h.1tectures, in · · ·
process engineering as process fl ow d'agrams
1 , as messagck
e: procedure or function call that abstracts
functionality or details not shown at this
1

sequence charts and call flows for telecom/wireless system design, and for protoco 1sea level. Can optionally be linked to
design and analysis. · · another diagram for elaboration.

SWE-122 SWE-123
 POPULA R PUBLICA TIONS
soFTWA RE ENGINEERTNG

Else Block Represen ts an "else" block portion of a

diagram block ··r l else t Diagram·
(iii) State C~ ~~e diagram itself clari fies the ~urpose d' am and other details. lt

Flow Note
-tJ . .
Documen tation note that is auto~ati~alt y Flow ~ote providing
The name o_
ribes diffe rent s
tates of a compone nt m a system.
desc ent/objec t of.a system. .
of theT ~:~tates are specifi c to a

clarify it state machi ne can be

.

fonnatted to flo w after previous

diagram c/eta//s compon hart diagram describes a state machme. Now
· A State c tfo biect and these states are
1 h' hich defi nes different states o an o ,
elements d fi ed as a mac me w
Free Note Documen tation note that is free- flo wing ~ c~~~olled by exte~al or int~~a~-~vden;}· a State chart d
iagram. As State chart d iagram
and can. be placed anywhere in the Activi ty diagra1:1 is a specta 1· ·me ofan ob·ect.
diagram (can also be anchored relati ve to defines states it is used to mofdehl11fifet1 UML d'1agr~ams used
d' is one o t e 1ve to model dynamic nature of a
a flow element) State chart iagrr diffe rent states of an object d uring its li fetime. A nd th~se states
system. They de me S State chart diagrams are useful are
Message A simpl e message between header to model reactive systems.
. rl_ _ _ M_es_s_ag_e__.:,J~ . chang_ed by event\ b~ defined as a system that responds
elements to external or internal events.
Reacuve syst:m~a : describes the flow of control from
Page Break A page break in the di agram one state to another state. Stat~s
-+·--·-...Page Break ...._. _,,·+-· Stat~ c:artd d~ ~ condition in which an object exists and
it changes when so~e e~ent isf
Return Message A return
elements
message between
header . . r return l·.
a~e eOmde So the most important purpose of State chart
tngge re . . .
an object from creation to termination.
State chart diagrams are also used for forward and reverse
diagram is to model life t ime o
. · .
engmeen ng of a sy?tem. ut
B
Scenario Start Start of a scenario (set of alternati ves)
I ~art I the main purpose is to model reactive system.
Scenario Case Start of an a lternative or case in a ~ Following are the main purposes of using State chart diagrams
scenario :
• To model dynamic aspect of a system.
Scenario End End'of a scenari o . • To model life time ofa reactive system.
End • To describe different states of an object during its life
, State time.
A state change for a header element • Define a state machine to model states of an object.

Steady State (iv) Collabor ation Diagram :

A steady state in the sys tem . . ·t/?I\S!e.adx.?1fd.e_ }{}jJ ··· A Collaboration diagram is very similar to a Sequenc e
d iagram in the purpose it achieves ;
in other words, it shows the dynamic interactio n
Timer Start Start of a timer fo r a particula r header .. Timer( 0s) of the objects in a system. A
1 "S7 1... distinguishing feature of a Collabor ation diagram is that
element it shows the· obj ects and their
E"l association with other objects in the system apart from
how they interact with each other.
Timer Stop Stop of a tim er fo r a particul ar header .. Timer The association between objects is not represent ed in a
Sequenc e d iagram .
element A Collaboration diagram is easily represent ed by modeling
obj ects in a system and
Timer Expiration Expiratio n of a timer for a particul representing the associations between the objects as
ar . . Timer links. The interacti on between the
header element objects is denoted by arrows . To identify the sequence
of invocatio n of these objects, a
number is placed next to each of these arrows.
(ii) Links:
A UML link is run-time relations hip between instances . ·..
of cl assifiers. A typical uru
direction al link requires the one instance to know about, 0th
and· thus depend, upon the e~
but this is not required. Likewise, a bi-directional link
requires that both' instances ma
traverse to each other, but this also does not require depende
ncy.

SWE-124 SWE-125