1. What do you mean by software crisis? Explain with examples.

How can
software crisis can be minimized?

Software Crisis is a term used in computer science for the difficulty of

writing useful and efficient computer programs in the required time.
software crisis was due to using same workforce, same methods, same tools
even though rapidly increasing in software demand, complexity of software
and software challenges. With increase in the complexity of software, many
software problems arise because existing methods were insufficient.

Causes of Software Crisis:

 The cost of owning and maintaining software was as expensive as

developing the software
 At that time Projects was running over-time
 At that time Software was very inefficient
 The quality of software was low quality
 Software often did not meet requirements
 The average software project overshoots its schedule by half
 At that time Software was never delivered

Minimization of software crisis:

There is no single solution to the crisis. One possible solution of software

crisis is Software Engineering because software engineering is a systematic,
disciplined and quantifiable approach. For preventing software crisis, there
are some guidelines:
 Reduction of software over-budget
 The quality of software must be high
 Less time needed for software project
 Experienced working team member on software project
 Software must be delivered
2. Communication plays a vital role in the field of software engineering.
Explain.

Communication skills represent nothing but the exchange of ideas, views,

and information with others. It is a valuable and beneficial element
obligatory in every profession. Great communication is the most important
characteristic for success as a software engineer. A big part of the day-to-day
job of software engineering is not spent knee-deep in code but rather
working with a variety of folks across the company. It turns out software
engineers, like other knowledge-workers, spend a ton of time collaborating
across IM, email, reading designs, reviewing code and going to meetings.
The role of software engineering involves working across many parts of the
company communicating with product management, account management,
support, operations, sales, customers and of course with our peers and
managers. As their career develops, software engineers end up spending
most of their time communicating rather than actually coding.
Communication skills form a backbone in the field of software engineering.
Being a software engineer, one should practice developing their
communication every-day. This will help in dealing with the clients and
personas working with. If both the communication skills, verbal as well as
non-verbal are tremendous one can execute their plans with effortlessly.
People believe that the world of software engineering can be run on the basis
of technical knowledge, but they are mistaken. In this field, communication
skills are as important as technical skills are to work in the software
engineering field.

3. Your company is offered a project of building an online shopping app

and you have the right to choose the process model to be followed.
Which software process model will you follow? Justify your answer.

I would choose Agile model because Agile model is simpler and easier to
follow in a software project. Agile process model brings good culture in the
team and positive mindset to team members. In ‘Agile Model’ after every
sprint there is a demo-able feature to the customer. Hence customer can see
the features whether they are satisfying their need or not.
4. What is traceability in software engineering? Explain requirement
traceability.

Traceability in software engineering describes the extent to which

documentation or code can be traced back to its point of origin. The goal of
traceability is to provide better quality and consistency of product
development. It brings the ability to verify the history, location, and
application of an item by means of documented identification.

Requirements traceability is the ability to trace a requirement forwards and

backwards in the development lifecycle. Requirements are traced forward
through other development artifacts, including test cases, test runs, and
issues. Requirements are traced backward to the source of the requirement,
such as a stakeholder or a regulatory compliance mandate. The purpose of
requirements traceability is to verify that requirements are met. It also
accelerates development. That’s because it’s easier to get visibility over your
requirements. Traceability is also important for analysis. If a requirement
changes, then you can use traceability to determine the impact of change.
You’ll see what the requirement is connected to. And you’ll be able to see
how changing that requirement will impact related issues or tests.

5. Why do we need requirements engineering in software engineering?

Explain.

Requirements engineering refers to the process of defining, documenting,

and maintaining requirements in the engineering design process.
Requirement engineering provides the appropriate mechanism to understand
what the customer desires, analyzing the need, and assessing feasibility,
negotiating a reasonable solution, specifying the solution clearly, validating
the specifications and managing the requirements as they are transformed
into a working system. Thus, requirement engineering is the disciplined
application of proven principles, methods, tools, and notation to describe a
proposed system's intended behavior and its associated constraints. When
developing a software, one of the most important aspects for success of any
software project is to get the requirements right. The success of any software
project depends on the quality of the requirements. As the projects change
 over the time, we try to study the requirement process in different type of
projects focusing on classical, web-based and open source projects. The
requirements dictate all other software engineering processes which in turn
influence the Productivity, Quality and Risk. The requirements engineering
steers the whole process of the software development to develop the right
software. Requirements engineering not only helps the various software
process teams but also helps the management to meet the constraints of cost,
time and resources. Also, requirements can help us to trace the quality of the
software product.

6. Differentiate between:
A. Spiral and Waterfall Model

Spiral Model Waterfall Model

Spiral model works in
evolutionary method.
In spiral model errors or risks
are identified and rectified
earlier.
Spiral model is adopted by
developers.
Spiral model is used for large
project.
Spiral model requirements and
early stage planning is necessary
if required.
Flexibility to change in spiral
model is not Difficult.
While cost of spiral model is
very expensive.
There is low amount risk in
spiral model.
Waterfall model works in
sequential method.
In waterfall model errors or risks
are identified and rectified after
the completion of stages.
Waterfall model is adopted by
customers.
Waterfall model is applicable for
small project.
In waterfall model requirements
and early stage planning is
necessary.
Flexibility to change in waterfall
model is Difficult.
Waterfall model is comparatively
inexpensive.
There is high amount risk in
waterfall model.
B. Agile and RUP Model

RUP Agile
Formal cycle is defined across Each iteration is a complete
four phases, but some workflows cycle.
can be concurrent.
Formal project plan, associated No end-to-end plan. Each next
with multiple iterations, is used. iteration plan is determined at
The plan is end-date driven and the end of the current iteration.
also has intermediate milestones. Product Owner determines when
the project is done.
Scope is predefined ahead of the Instead of scope, Agile uses a
project start and document in the project Backlog, which is re-
scope document. Scope can be valued at the end of each
revised during the project, as iteration.
requirements are being clarified,
bur these revisions are subject to
a strictly controlled procedure.
Vision/scope Document, Formal The only formal artifact is the
functional requirements package, operations software.
system architecture document,
development plan, test plan, test
scripts etc.
Recommended for large, long- Recommended for quick
term, enterprise-level projects enhancements and organizations
with medium-to-high that are not dependent on a
complexity. deadline.
 Scrum
In Scrum framework, team work
in iterations
called Sprint which are 1-2
month long.
Scrum model do not allow
changes in their timeline or their
guidelines.
Scrum emphasizes self-
organization.
In Scrum framework, team
determines the sequence in
which the product will be
developed.
Scrum framework is not fully
described. If you want to adopt it be directly applied to a team.
then you need to fill the
framework with your own
framework’s method like XP,
DSDM or Kanban.
C. Scrum and XP
D. Scrum and Kanban
XP
In Extreme Programming (XP),
teamwork for 1-2 weeks only.
Extreme Programming allow
changes in their set timelines.
Extreme Programming
emphasizes strong engineering
practices
In Extreme Programming, team
have to follow a strict priority
order or pre-determined priority
order.
Extreme Programming (XP) can
Extreme Programming is also
known for its Ready-to-apply
features.
 Scrum
Timeboxed iterations prescribed
Team commits to a specific
amount of work for this iteration
Uses velocity as default metric
for planning and process
improvement
Cross-functional teams
prescribed
Items must be broken down so
they can be completed within 1
sprint
A sprint backlog is owned by
one specific team
Cannot add items to ongoing
iteration
E. Scrum and Lean Development
Scrum
Agile is an umbrella team for
Kanban
Timeboxed iterations optional.
Can have separate cadences for
planning, release, and process
improvement. Can be event
driven instead of timeboxed
Commitment is optional
Uses lead time as default metric
for planning and process
improvement
Cross-functional teams optional.
Specialist teams allowed
No particular item size is
prescribed
A Kanban board may be shared
by multiple teams or individuals.
Can add new items whenever
capacity is available.
Lean development
Lean is an umbrella term for any
 several software development
methodologies including scrum
and XP
Agile is all about individuals and
iterations
It is collective collaborations
between teams and end users
It values iterative delivery by
welcoming changing
requirements
It believes in end results through
responses and feedback
The lesser the team, the faster
the delivery.
It foresees future by responding
to changes rather than following
plan.
approach based on both lean
manufacturing and Toyota
production system
Lean is all about eliminating
waste
It emphasizes on maximizing
customer value and increasing
efficiency
It defers commitment and values
processes over customer
requirements
It follows a systematic plan to
development by avoiding
unnecessary meeting and
documentation.
It sees the team as a whole
It responds in a disciplined
manner to changing
requirements rather than
predicting the future.

7. Write short notes on:

A. Risk Driven Development

Risk-Driven Development is about identifying those high-risk

specifications that need to meet by the project and working on those
items early to assure that they can be accomplished by the project.
Often these risks are associated with the architecture core and drive
the selection of key technologies and solutions. The desire is to flush
these issues out early before you spend a considerable amount of time
 going down a path to realize the architecture won’t meet your high-
risk needs and a complete rewrite is necessary.

B. Client Driven Development

Client-Driven Development is about identifying those features most

important to the customer and business and completing those items
early so the client sees progress and can provide feedback on those
features early and on-going. Unless a customer sees progress and feels
empowered during the development process, one may not have a
project. The desire is to keep the customer happy and engaged in the
project by delivering those features that are important to the client and
their business

C. Product backlog

Product Backlog is an ordered list of everything that is known to be

needed in the product. It is the single source of requirements for any
changes to be made to the product. The Product Owner is responsible
for the Product Backlog, including its content, availability, and
ordering. A Product Backlog is never complete. The earliest
development of it lays out the initially known and best-understood
requirements. The Product Backlog evolves as the product and the
environment in which it will be used evolves. The Product Backlog is
dynamic; it constantly changes to identify what the product needs to be
appropriate, competitive, and useful. If a product exists, its Product
Backlog also exists.

D. User story

User stories are part of an agile approach that helps shift the focus
from writing about requirements to talking about them. All agile user
stories include a written sentence or two and, more importantly, a
series of conversations about the desired functionality. A user story is
an informal, natural language description of one or more features of a
 software system. A user story is a tool used in Agile software
development to capture a description of a software feature from an
end-user perspective. A user story describes the type of user, what they
want and why. A user story helps to create a simplified description of a
requirement. User stories are often recorded on index cards, on Post-it
notes, or in project management software. Depending on the project,
user stories may be written by various stakeholders such as clients,
users, managers or development team members.

E. Adaptive Software Development

Adaptive Software Development is a move towards adaptive practices,

leaving the deterministic practices in the context of complex systems
and complex environments. Adaptive Software Development focuses
on collaboration and learning as a technique to build complex systems.
It is evolved from the best practices of Rapid Application Development
(RAD) and Evolutionary Life Cycles. Adaptive Software Development
was then extended to include adaptive approaches for the management,
with speculation replacing Planning. It incorporates three phases
namely:

i. Speculation

During this phase project is initiated and planning is conducted.

The project plan uses project initiation information like project
requirements, user needs, customer mission statement etc., to
define set of release cycles that the project wants.

ii. Collaboration

It is the difficult part of ASD as it needs the workers to be

motivated. It collaborates communication and teamwork but
emphasizes individualism as individual creativity plays a major
role in creative thinking.

iii. Learning
 The workers may have an overestimate of their own understanding of
the technology which may not lead to the desired result. Learning helps
the workers to increase their level of understanding over the project.

F. Socio-Technical Systems

Socio-technical system is basically a study of how any technology is

used and produced. This help us to identify the ethical errors in
technical and social aspects of the systems. Socio-technical system is a
mixture of people and technology. It consists of many items. These
items are difficult to distinguish from each other because they all have
close inter-relationships. Some of the items are shown in figure: