Q.1 In a market, software products for similar purposes differ a lot in their costs.

What
can be the reason behind it?
Ans: This may be due to many factors like warranty terms, platform, maintainability,
customizability, supporting add-ons and compatibility with different environments.
Q.2 The softwares are related with many myths . On the contrary , there are facts which
are either not known to us or we are ignorant on that part. Listed below are a certain
myths. Contradict them with their facts.
i) Myth: Software is easy to change.
Fact: Ease of modification in S/W depends on the maintainability of its design.Not all software is
easy to change. Furthermore , any change in a part will affect other components of the software
and will forward in different parts of the software , which will require intense tracing and
altering. Hence , s/w alteration is a complex and costly task.
ii) Testing software or proving s/w correct can remove all possible errors in application.
Fact: Testing can report presence of errors but can never guarantee their absence. Also testing for
all inputs is impractical and confined to constraints of time and resources.

Q.3 Giving reasons for your answer based on the type of system being developed, suggest the
most appropriate generic software process model that might be used as a basis for managing the
development of the following systems:
a)

A system to control anti-lock braking in a car

b)

A virtual reality system to support software maintenance

c)

A university accounting system that replaces an existing system

d) An interactive travel planning system that helps users plan journey with the
lowest environment impact
Answer: a) Anti-lock braking system This is a safety-critical system so requires a lot of upfront analysis before implementation. It certainly needs a plan-driven approach to development
with the requirements carefully analyzed. A waterfall model is therefore the most appropriate
approach to use, perhaps with formal transformations between the different development stages.

b) Virtual reality system This is a system where the requirements will change and
there will be an extensive user interface components. Incremental development with,

perhaps, some UI prototyping is the most appropriate model. An agile process may be
used.

c) University accounting system This is a system whose requirements are fairly wellknown and which will be used in an environment in conjunction with lots of other
systems such as a research grant management system. Therefore, a reuse-based approach
is likely to be appropriate for this.

d) Interactive travel planning system System with a complex user interface but which
must be stable and reliable. An incremental development approach is the most
appropriate as the system requirements will change as real user experience with the
system is gained.

Q.5 If you were in charge of a large team implementing such a system , how would you ensure
that the product was both reliable and finished on time? Suggest a process model to accomplish
this task.
Ans: Spiral model is most suitable as
a) the size of project is large ,
b) reliable enough for which we will risk analysis everytime,
c) for time factor, deadline is to be followed.

Q.6 When emergency changes have to be made to the systems, the system software may have to
be modified before changes to the requirements have been approved. Suggest a model of a
process for making these modifications which ensure that the requirements document and the
system implementation do not become inconsistent. Also, justify your suggestion.
Ans: Incremental model is most suitable as modifications in older version are possible and
easily manageable.

Q.7 Based on the various Life cycle Models studied , mention the most appropriate life cycle
models you would prefer in accordance with the stated descriptions along with the justification
for your preference.

Sr. No.

Description

Most appropriate

Justification for your

1.

2.

3.

life cycle model

Requirements are Waterfall / RAD
easily
understandable
and defined
Development
Prototype / Spiral
team has less
experience on
similar projects
There is
Prototype / RAD
involvement of
users in all
phases.

preference of Models
These teo models are
applicable only when all
the requirements are
understood and defined.
These models emphasize
on seeking clarified
requirements from the
client.
In these models active
user involvement proves
helpful in consolidating
and completing user
requirements.
These models involve
development from
scratch.

4.

Development
team has less
experience on
tools to be used.

Waterfall / Spiral

5.

Requirements
change quite
often.

Prototype / Spiral Both models helps

seeking feedback from
the client based on
prototype executions.
Hence, changes to
requirements are
manageable.

Q.8 Give the criteria for selection of models on the basis of:
a) Requirements of the project
Requirements
of the Project
Requirements are
defined early in
SDLC
Requirements are
easily defined
and
understandable
Requirements are
changed
frequently
User
involvement

b) User

Waterfall

Prototype

Spiral

RAD

Yes

No

No

Yes

Yes

No

No

Yes

No

Yes

Yes

No

Waterfall

Prototype

Spiral

RAD

Requires limited
user involvement
User
participation in
every phase

Yes

No

Yes

No

No

Yes

No

Yes

Q.9 Write a set of non-functional requirements for the ticket-issuing system, setting out its
expected reliability and response time.
Answer:

Possible non-functional requirements for the ticket issuing system include:

a) Between 0600 and 2300 in any one day, the total system down time should not
exceed 5 minutes.

b) Between 0600 and 2300 in any one day, the recovery time after a system failure
should not exceed 2 minutes.

c) Between 2300 and 0600 in any one day, the total system down time should not
exceed 20 minutes.

All these are availability requirements note that these vary according to the time of day.
Failures when most people are traveling are less acceptable than failures when there are
few customers.

d) After the customer presses a button on the machine, the display should be updated within
0.5 seconds.
e) The ticket issuing time after credit card validation has been received should not exceed 10
seconds.
f)
When validating credit cards, the display should provide a status message for customers
indicating that activity is taking place. This tells the customer that the potentially time consuming
activity of validation is still in progress and that the system has not simply failed.
g)

The maximum acceptable failure rate for ticket issue requests is 1: 10000.