Subject: Software Engineering / Code IT3003 /Branch: CS & IT /Semester: 5th /Sept 2015

Mid-Term Examination September, 2015

School of Computer Engineering, KIIT University
Time: 2 Hours

Full Marks: 25
Answer 5 ( Five ) questions including Q.1 which is compulsory

1.

(a)

Why is Software Engineering referred to as a layered technology ?

1 x5

Tools
Methods
Processes

Ans

Quality Focus

(b)
Ans
(c)
Ans
(d)
Ans

Quality focus: bedrock that supports software engineering

Processes: Provides the glue that holds the layers together; provides a
framework for effective development; forms the basis for management;

Methods: Provide the technical "how to" for building software

Tools: Provide automated or semi-automated support for the process and

methods
Explain what is meant by fan-in and fan-out in architectural design.
Fan-in: of a module is the number of modules that directly invoke it.
Fan-out: of a module is the number of modules that are directly invoked by it.
What do you understand by traceability in the context of software
requirements specification?
Traceability is the ability to tell which design component relates to which
requirement, which test case corresponds to which requirement. Traceability of
requirements helps in studying the impact of changes in design and coding.
Differentiate between heuristic, empirical and analytical estimation
techniques.
Heuristic techniques: an educated guess based on past experience.
Empirical techniques : assume that the characteristics to be estimated can be
expressed in terms of some mathematical expression based on analysis of
historical data.
Analytical techniques: derive the required results starting from certain simple

Subject: Software Engineering / Code IT3003 /Branch: CS & IT /Semester: 5th /Sept 2015

(e)

assumptions.
Differentiate between functional format and project format for software
development organization
functional format : Engineers are organized into functional groups, e.g.
specification, design, coding, testing, maintenance, etc.
Engineers from functional groups get assigned to different projects

Ans
project format Engineers get assigned to a project for the entire duration of the
project. Same set of engineers carry out all the phases

Subject: Software Engineering / Code IT3003 /Branch: CS & IT /Semester: 5th /Sept 2015

Describe the Prototyping model of software development.

Under what circumstances is it beneficial to construct a prototype?
How does the Prototyping model differ from the RAD model ?
Prototyping Model: Before starting actual development, a working prototype of the system is
first built. A prototype is a toy implementation of a system with limited functionalities , low
reliability and inefficient performance
Start with approximate requirements.
Carry out a quick design.
Prototype model is built using several short-cuts: e.g.,A function may use a table look-up
rather than performing the actual computations.
The developed prototype is submitted to the customer for his evaluation:
Based on the user feedback, requirements are refined.
This cycle continues until the user approves the prototype.
The actual system is developed using the classical waterfall approach.
Design and code for the prototype is usually thrown away:
However, the experience gathered from developing the prototype helps a great
deal while developing the actual product.

Customersatisfied

Circumstances where Prototyping is suggested; When requirements are not well known or are
likely to undergo changes
Difference from the RAD model
RAD faster than prototyping
Quality and reliability less than prototyping
In prototyping, a throwaway approach is followed to obtain requirements only
The RAD prototype develops into final product

Subject: Software Engineering / Code IT3003 /Branch: CS & IT /Semester: 5th /Sept 2015

2
Suggest a suitable life cycle model for a Software Project where several kinds of risks
are there. Explain all the phases of the proposed model with schematic diagram.
Spiral model is suggested for a Software Project where several kinds of risks are there
Each loop of the spiral represents a phase of the software process: The innermost loop might
be concerned with system feasibility, the next loop with system requirements definition, the
next one with system design, and so on.
There are no fixed phases in this model, the phases shown in the figure are just examples
The team must decide: how to structure the project into phases.
Start work using some generic model: add extra phases for specific projects or when
problems are identified during a project.
Each loop in the spiral is split into four sectors (quadrants)

CustomerEvaluationofPrototype

Objective Setting (1st Quadrant)

Identify objectives of the phase,
Examine the risks associated with these objectives.
Find alternate solutions possible.
Risk Assessment and Reduction (2nd Quadrant)
For each identified project risk, a detailed analysis is carried out.
Steps are taken to reduce the risk.
For example, if there is a risk that the requirements are inappropriate:
a prototype system may be developed
Development and Validation (3rd quadrant): develop and validate the next level of the product.
Review and Planning (4th quadrant): review the results achieved so far with the customer and plan
the next iteration around the spiral.
With each iteration around the spiral , progressively more complete version of the software gets built.
Spiral Model Subsumes all other models:
a single loop spiral represents waterfall model.
uses an evolutionary approach -- iterations through the spiral are evolutionary levels.
enables understanding and reacting to risks during each iteration along the spiral.
uses: prototyping as a risk reduction mechanism

Subject: Software Engineering / Code IT3003 /Branch: CS & IT /Semester: 5th /Sept 2015

Subject: Software Engineering / Code IT3003 /Branch: CS & IT /Semester: 5th /Sept 2015

How is the SRS document used by different types of users?

Discuss the desirable characteristics of SRS documents.
Use of SRS document by different types of users
Users, Customers : To ensure that the requirements as described will meet the customer needs.
SRS document also serves as the basis of the Contract document.
Developers: Design and development is based on SRS document as input.
Test Engineers: To validate if the requirements have been successfully implemented.
Writers of Users manual: SRS document serves as a guide to the functionalities which must be
addressed in the users manual.
Project Managers: for estimating the cost of the project.
Maintenance Engineers : for understanding the functionalities of the system.
Desirable characteristics of SRS documents
It is desirable that a SRS document should have the following characteristics.
Concise. The SRS document should be concise and at the same time unambiguous, consistent,
and complete. It should not be verbose .
Structured. It should be well-structured. A well-structured document is easy to understand and
modify.
Black-box view. It should only specify what the system should do and refrain from stating how
to do these. This means that the SRS document should specify the external behavior of the
system and not discuss the implementation issues.
Traceable: Traceability is the ability to tell which design component relates to which
requirement, which test case corresponds to which requirement. Traceability of requirements
helps in studying the impact of changes in design and coding.
Response to undesired events. It should characterize acceptable responses to undesired events.
These are called system response to exceptional conditions.
Verifiable. All requirements of the system as documented in the SRS document should be
verifiable. This means that it should be possible to determine whether or not requirements have
been met in an implementation.

Subject: Software Engineering / Code IT3003 /Branch: CS & IT /Semester: 5th /Sept 2015

When the size of a software product increases, explain why the estimated effort

increases drastically whereas the development time increases moderately. Substantiate

by considering two organic projects having 10,000 and 15,000 LOC.
[ Values of parameters: Effort ( 2.4, 1.05); Time ( 2.5, 0.38) ]
Using formulas for the Basic COCOMO, we get
E1=2.4(10)1.05 =2.4x11.22 = 26.92 PM
T1= 2.5(E1)0.38= 2.5(26.92)0.38 = 2.5x3.49= 8.73 Months
E2=2.4(15)1.05 = 2.4x17.17= 41.21PM
T2=2.5(E2)0.38=2.5(41.21)0.38 = 2.5x4.10=10.27 Months
% increase in effort= [(E2-E1)/E1]x100=53%
% increase in time= [(T2-T1)/T1]x100= 17.64%
% increase in size= [(15-10)/10]x100= 50%
Thus, for a 50% increment in size, the above formulas predict a 53% rise in effort but only 18% rise
in development time.
This can be explained by the fact that, with increase in size, some tasks can be carried out in parallel;
thereby resulting in a sub-linear increment in time

Subject: Software Engineering / Code IT3003 /Branch: CS & IT /Semester: 5th /Sept 2015

A restaurant owner wants to computerize order processing, billing and

accounting activities. He also expects the computer to generate statistical
report about sales .
The computer should maintain the prices of all the items and also support
changing the prices by the manager. Whenever any food items are sold, the
sales clerk would enter the item code and the quantity sold. The computer
should generate bills.
When ingredients are issued for preparation of food items, the data is to be
entered into computer.
Purchase orders are generated on a daily basis, whenever the stock of any
ingredient falls below a threshold value.
The computer should calculate the threshold value of each item based on the
average consumption of this ingredient for the past three days and assuming
that a minimum of two days stock must be maintained for all ingredients.
Whenever the ordered ingredients arrive, the invoice data regarding the
quantity and the price is entered. The computer should print cheques against
the invoice.
Monthly sales receipt and expenses data should be generated whenever
requested by the manager .
Represent the system by drawing a DFD upto level 1.

Subject: Software Engineering / Code IT3003 /Branch: CS & IT /Semester: 5th /Sept 2015

CONTEXT DIAGRAM

Purchase
Manag
er

Expense
reports

Sales
reports

Chequ
Bill

RAS

Order details

Invoice
Query / Change Menu
Price

Clerk
received
Issue
Ingredien

Please see attachment for Level I DFD

Subject: Software Engineering / Code IT3003 /Branch: CS & IT /Semester: 5th /Sept 2015

Identify the functional requirements for the above problem.

R1:Create / Add to Inventory
Input: Invoice from Vendor
Output: Update Inventory file
R2: Generate Bill
Input: Item code, Quantity of order
Output: Bill, Update Sales file
R3: Delete from Inventory
Input: Item code, Quantity of order
Output: Bill, Update Sales file
R4: Generate Purchase Order
Input: Consumption data for past 3 days
Output: Purchase Order
Process: Check threshold level
R5: Print Cheques
Input: Invoice from Vendor
Output: Cheque
R6: Generate Reports
Input: Query by Manager
Output: Sales Report/ Expense Report
R7: Change Menu Price
Input: Changed Price (Manager)
Output: Update Menu Price

Subject: Software Engineering / Code IT3003 /Branch: CS & IT /Semester: 5th /Sept 2015

Draw the Activity Network and Gantt Chart for the activities tabulated
below
Activity
A
B
C
D
E
F
G
H

Predecessor
B
A, C
A, C
D
E
F, G

Duration (days)
10
5
3
4
5
6
5
5

Identify the critical path , project completion time and slack times.
Ansns
ES=14
LF=14

4
ES=10
LF=10

ES=0
LF=0

10
B 5

3
2
ES=5
LF=7

ES=20
LF=20

5
E

5
5
ES=15
LF=15

5
H

ES=25
LF=25

Subject: Software Engineering / Code IT3003 /Branch: CS & IT /Semester: 5th /Sept 2015

Critical path-1
ADFH
Critical Path-2
AEGH
Project Duration = 25 days

BC Slack time 2 days

GANTT CHART
A
B
C
D
Activit
y

E
F
G
H
Days

Subject: Software Engineering / Code IT3003 /Branch: CS & IT /Semester: 5th /Sept 2015

6(a)
Ans

Write short notes on any two

Function Point metric
FP metric is a metric to characterize the size of a software project. Unlike LOC, it can
be used to estimate software size directly from problem specification. Size estimation
is needed for effort and time estimation of a project.
Underlying idea: Size of a software product is directly dependent on the number of
different functions or features it supports.
Computation: FP is computed using the following steps.
1. Compute the Unadjusted Function Point (UFP).
The UFP can be simply computed as:
UFP = (Number of inputs)*4 + (Number of outputs)*5 + (Number of
inquiries)*4 + (Number of files)*10 + (Number of interfaces)*10
Note that the above expression does not consider the differing complexities of
entities within each class, e.g. different complexities of the different input
parameters. Here each input is simply considered as 4 function points. Thus the
weights like 4, 5, etc. can be viewed as average weights. To refine the result, it
is recommended to grade each parameter (like each input, each output, etc.) into
one of 3 classes: simple, average and complex. Separate weights are used for
each class. For example, for inputs, (a) weight 3 is used as a multiplier for the
number of simple inputs; (b) weight 6 is used as a multiplier for the number of
complex inputs; and (c) weight 4 is used as multiplier for the number of other
inputs.
2. Compute Technical Complexity Factor (TCF)
A set of 14 parameters (like high transaction rates, response time requirements,
etc.) are identified that can influence the development effort. Each factor is
assigned a value from 0 (no influence) to 6 (strong influence). The resulting
numbers are summed up to produce the degree of influence (DI). Now, TCF is
computed as TCF = 0.65 + 0.01*DI.
Finally FP is computed as
FP = UFP * TCP
FP does not take into account algorithmic complexity of the functions. Feature point
metric addresses it by incorporating algorithmic complexity as an extra parameter.

2.5x2

Subject: Software Engineering / Code IT3003 /Branch: CS & IT /Semester: 5th /Sept 2015

6(b) Risk Management

Risk is an unanticipated unfavourable event or circumstance that can occur while a
project is underway. Risk is problem that might occur in future. Risk management aims
at reducing the impact of all kinds of risks that might affect a project. It has 3
component activities:
1. Risk identification: A list of risks is maintained. Risks are grouped into project
risks (e.g., risk occurring if incurred cost is more than estimated cost), technical
risks (e.g., for a mobile communications company, a technical risk is a risk
occurring if the handoff between satellites in case of mobile communication is
too difficult to implement) or business risk (e.g., for a mobile phone
manufacturing company, the risk occurring if the phone is too heavy to carry).
A company can maintain a company disaster list which stores the hazards faced
by the company earlier.
2. Risk assessment: The risks are ranked in terms of the damage they might cause,
i.e., the risks are prioritized and the most damaging risks are first handled. The
Ans
priority is defined as ((probability of the risk to occur) * (severity of the
damage that the risk if true can cause))
3. Risk containment: Efforts are made to avoid the potential ill-effects associated
with the risk. There are 3 ways to do it: (1) Avoid the risk: Remove/defer
development of risky features, (2) Transfer the risk: Use 3rd party solution, (3)
Reduce the risk: Plan contingency measures (e.g. recruit new engineers if some
engineer is leaving, build prototype for complex projects, etc.)
To choose between different strategies of handling a risk, evaluate the risk
leverage of the different risks
Risk exposure before reductionRisk exposure after reduction
Risk Leverage ( RL )=
Cost of reduction
Clearly, if (RL < 1), it is not a beneficial step.
Note that risk handling still requires a lot of ingenuity on the part of the project
manager.

Subject: Software Engineering / Code IT3003 /Branch: CS & IT /Semester: 5th /Sept 2015

6(c)

Ans

Software Configuration Management

Configuration identification : deciding which objects (configuration items ) are to be kept
track of. The deliverables of a SW product consist of a number of objects, e.g. source code,
design document, SRS document, test document, users manual, etc.
These objects are modified by many software engineers throughout development cycle.
The configuration of the software is the state of these objects at any point of time.
Software Configuration Management ( SCM) deals with effectively tracking and controlling
the configuration of a software during its life cycle.
To control access to these objects with a view to avoiding the following problems
Inconsistency: When several members work on an object, they must work on a single
copy of the object, otherwise inconsistency may arise.
Concurrent access: Two engineers may simultaneously carry out changes to portions of
the same module, and while saving overwrite each other.
Unstable development environment: If one is trying to integrate module A, with
modules B and C, he cannot proceed if developer of module C keeps changing C.
System accounting and status information.
Keeping track of who made a particular change and when .
When an effective SCM is in place, the manager freezes the objects to form a base line.
A baseline is the status of all the objects under configuration control. When any of the objects
under configuration control is changed , a new baseline is formed.
Configuration control :ensuring that changes to a system happen without ambiguity
Controlled objects: are under Configuration Control (CC)
One must follow formal procedures to change them.
CC : process of managing changes to controlled objects.
CC allows authorized changes to the controlled objects and prevents unauthorized
changes .

The engineer needing to change a module , obtains a private copy of the module through a
reserve operation, carries out all changes on this private copy and restores the changed module
to the baseline with the permission of the change control board(CCB).

Subject: Software Engineering / Code IT3003 /Branch: CS & IT /Semester: 5th /Sept 2015

6(d) Cohesion and Coupling

Ans Cohesion is a measure of: functional strength of a module. A cohesive module
performs a single task or function.
Classification of Cohesiveness

communicational

[ Brief description of each type]

Coupling between two modules is a measure of the degree of the interdependence or
interaction between the two modules.
Classification of Coupling

Subject: Software Engineering / Code IT3003 /Branch: CS & IT /Semester: 5th /Sept 2015

[ Brief description of each type]