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 Waterfall model works in
evolutionary method. sequential method.
In spiral model errors or risks In waterfall model errors or risks
are identified and rectified are identified and rectified after
earlier. the completion of stages.
Spiral model is adopted by Waterfall model is adopted by
developers. customers.
Spiral model is used for large Waterfall model is applicable for
project. small project.
Spiral model requirements and In waterfall model requirements
early stage planning is necessary and early stage planning is
if required. necessary.
Flexibility to change in spiral Flexibility to change in waterfall
model is not Difficult. model is Difficult.
While cost of spiral model is Waterfall model is comparatively
very expensive. inexpensive.
There is low amount risk in There is high amount risk in
spiral model. 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 XP
In Scrum framework, team work In Extreme Programming (XP),
in iterations teamwork for 1-2 weeks only.
called Sprint which are 1-2
month long.
Scrum model do not allow Extreme Programming allow
changes in their timeline or their changes in their set timelines.
guidelines.
Scrum emphasizes self- Extreme Programming
organization. emphasizes strong engineering
practices
In Scrum framework, team In Extreme Programming, team
determines the sequence in have to follow a strict priority
which the product will be order or pre-determined priority
developed. order.
Scrum framework is not fully Extreme Programming (XP) can
described. If you want to adopt it be directly applied to a team.
then you need to fill the Extreme Programming is also
framework with your own known for its Ready-to-apply
framework’s method like XP, features.
DSDM or Kanban.

C. Scrum and XP

D. Scrum and Kanban

 Scrum Kanban
Timeboxed iterations prescribed Timeboxed iterations optional.
Can have separate cadences for
planning, release, and process
improvement. Can be event
driven instead of timeboxed
Team commits to a specific Commitment is optional
amount of work for this iteration
Uses velocity as default metric Uses lead time as default metric
for planning and process for planning and process
improvement improvement
Cross-functional teams Cross-functional teams optional.
prescribed Specialist teams allowed
Items must be broken down so No particular item size is
they can be completed within 1 prescribed
sprint
A sprint backlog is owned by A Kanban board may be shared
one specific team by multiple teams or individuals.
Cannot add items to ongoing Can add new items whenever
iteration capacity is available.

E. Scrum and Lean Development

Scrum Lean development

Agile is an umbrella team for Lean is an umbrella term for any
 several software development approach based on both lean
methodologies including scrum manufacturing and Toyota
and XP production system
Agile is all about individuals and Lean is all about eliminating
iterations waste
It is collective collaborations It emphasizes on maximizing
between teams and end users customer value and increasing
efficiency
It values iterative delivery by It defers commitment and values
welcoming changing processes over customer
requirements requirements
It believes in end results through It follows a systematic plan to
responses and feedback development by avoiding
unnecessary meeting and
documentation.
The lesser the team, the faster It sees the team as a whole
the delivery.
It foresees future by responding It responds in a disciplined
to changes rather than following manner to changing
plan. 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: