Student Id: Student Name:

Academic year: 2019-20

Sem-In Examinations-I,
B. Tech. (CSE), 2018 Batch
II/IV, 1st Semester
18CS2103R/A: Software Engineering
Time: 2 hours Max. Marks: 50
(Assume any missing data suitably and design adequate hypothesis, if required)
Part-A (4X 3M=12M)
Answer ALL Questions (BTL-1)
1. What is legacy software.
2. How TSP is used to build a ―self directed‖ project team that organizes itself to
produce high-quality software.
3. Define Requirements Engineering, List out the tasks of Requirements
Engineering.
4. Illustrate the Agile manifesto.
Part-B (4 X 5M=20M)
Answer ALL Questions (BTL-1,2)
5. Outline Software Application Domains.
6. Relate Product to Process.
7. Outline Eliciting Requirements.
8. How User requirements are expressed in Extreme Programming.
Part-C (2 X 9M=18M)
Answer ALL Questions (BTL-2,3)
9. (a) Summarize Software Myths. (4M)
(b) Explain the importance of specialized process models. (5M)
(Or)
10. (a) Summarize Prescriptive Process Models. (4M)
(b) Illustrate how incremental model is employed in spiral model. (5M)
11. (a) Outline the types of Requirements. (3M)
(b) Plan Establishing the Ground Work in Requirement Engineering. (6M)
(Or)
12. Identify Specific Agile Methods.
 Academic year: 2019-20
Sem-In Examinations-I,
B. Tech. (CSE), 2018 Batch
II/IV, 1st Semester
Software Engineering: Key
Max. Marks: 50
Part-A (4X 3M=12M)
Answer ALL Questions (BTL-1)
1. What is legacy software.
A. Legacy software systems . . . were developed decades ago and have been
continually modified to meet changes in business requirements and
computing platforms. (2M)
These older programs—often referred to as legacy software—have been
the focus of continuous attention and concern. (1M)

2. How TSP is used to build a ―self directed‖ project team that organizes itself to
produce high-quality software.

A. The goal of TSP is to build a ―selfdirected‖ project team that organizes

itself to produce high-quality software. The main objective for TSP is to
Build self-directed teams that plan and track their work, establish
goals, and own their processes and plans. These can be pure software
teams or integrated product teams (IPTs) of 3 to about 20 engineers.
(2M)
Because many industry-grade software projects are addressed by a
team of practitioners, from the introduction of PSP and proposed a
Team Software Process (TSP). (1M)
3. Define Requirements Engineering, List out the tasks of Requirements
Engineering.
A. The broad spectrum of tasks and techniques that lead to an
understanding of requirements is called requirements engineering. (1M)
It encompasses seven distinct tasks: inception, elicitation, elaboration,
negotiation, specification, validation, and management. (2M)
4. Illustrate the Agile manifesto.
A. Any three Listed Below (2M). If all are mentioned (3M)
Uncovering better ways of developing software by doing it and helping
others do it.Through this work we have come to value:
 Individuals and interactions over processes and tools
 Working software over comprehensive documentation
 Customer collaboration over contract negotiation
 Responding to change over following a plan
 That is, while there is value in the items on the right, we value
the items on the left more.‖
Part-B (4 X 5M=20M)
Answer ALL Questions (BTL-1,2)
5. Outline Software Application Domains.
 A. Seven broad categories Listed (2M) of computer software present
continuing challenges for software engineers:
 System software
 Application software
 Engineering/scientific software
 Embedded software
 Product-line software
 WebApps (Web applications)
 AI software
Explanation about each carries (2M to 3M)
6. Relate Product to Process.
A. If the process is weak, the end product will undoubtedly suffer. But an
obsessive overreliance on process is also dangerous. (2M)
In a brief essay written many years ago, About every ten years give or
take five, the software community redefines ―the problem‖ by shifting its
focus from product issues to process issues. Thus, we have embraced
structured programming languages (product) followed by structured
analysis methods (process) followed by data encapsulation (product)
followed by the current emphasis on the Software Engineering
Institute’s Software Development Capability Maturity Model (process)
(2M)
The swings also do not solve ―the problem‖ for they are doomed to fail
as long as product and process are treated as forming a dichotomy
instead of a duality. (1M)
7. Outline Eliciting Requirements.
A. Requirements elicitation (also called requirements gathering) combines
elements of problem solving, elaboration, negotiation, and specification.
(2M)
In order to encourage a collaborative, team-oriented approach to
requirements gathering, stakeholders work together to identify the
problem, propose elements of the solution, negotiate different
approaches and specify a preliminary set of solution requirements. (1M)
Listed all (2M)
 Collaborative Requirements Gathering
 Quality Function Deployment: Normal requirements, Expected
requirements and Exciting requirements.
 Usage Scenarios
 Elicitation Work Products
8. How User requirements are expressed in Extreme Programming.
List of mentioned as Story Cards, Task List and Visible Graphs - (2M)
Explanation for Each – 1M, (1x3= 3M)
A. 1. Story Cards— A handwritten note on a paper index card. During the
Planning Game, many of these are written. This spartan example was
chosen to emphasize the minimalist approach to recorded requirements
that XP encourages.The story cards record user stories: features, fixes,
or nonfunctional requirements that the user wants. There can even be a
story card to create documentation. Stories are usually in the one-day
to three-week range of estimated duration.

2. Task List— During an Iteration Planning Game, the team convenes

around a whiteboard, and generates a list of tasks for all the stories
chosen for the iteration. Another popular alternative is to generate
individual task cards. Once a task is chosen by a volunteer, they enter
 an effort estimate (in ideal engineering hours)—tasks should be in the
1–2 day range.
3. Visible Graphs— The idea is to easily communicate—to the team—
something they find useful to measure. Measure at least one thing. XP
doesn't mandate what that should be, though known examples include
acceptance tests defined and passing, story progress, and task
progress.
Part-C (2 X 9M=18M)
Answer ALL Questions (BTL-2,3)
9. (a) Summarize Software Myths. (4M)

Types of Myths - (1M)

A. Software myths—erroneous beliefs about software and the process that is
used to build it—can be traced to the earliest days of computing. Myths have a
number of attributes that make them insidious. For instance, they appear to
be reasonable statements of fact (sometimes containing elements of truth),
they have an intuitive feel, and they are often promulgated by experienced
practitioners who ―know the score.‖ Today, most knowledgeable software
engineering professionals recognize myths for what they are—misleading
attitudes that have caused serious problems for managers and practitioners
alike. However, old attitudes and habits are difficult to modify, and remnants
of software myths remain. (1M)
Management myths - Managers with software responsibility, like managers in
most disciplines, are often under pressure to maintain budgets, keep
schedules from slipping, and improve quality. Like a drowning person who
grasps at a straw, a software manager often grasps at belief in a software
myth, if that belief will lessen the pressure (even temporarily). (1M)
Customer myths - A customer who requests computer software may be a
person at the next desk, a technical group down the hall, the marketing/sales
department, or an outside company that has requested software under
contract. In many cases, the customer believes myths about software because
software managers and practitioners do little to correct misinformation. Myths
lead to false expectations (by the customer) and, ultimately, dissatisfaction
with the developer. (1M)
Practitioner’s myths - Myths that are still believed by software practitioners
have been fostered by over 50 years of programming culture. During the early
days, programming was viewed as an art form. Old ways and attitudes die
hard. (1M)

(b) Explain the importance of specialized process models. (5M)

A. List of Specialized Process Models (2M)
Specialized process models take on many of the characteristics of one or
more of the traditional models presented in the preceding sections.
However, these models tend to be applied when a specialized or
narrowly defined software engineering approach is chosen.

Component-Based Development: (1M)

component-based development model incorporates many of the
characteristics of the spiral model. It is evolutionary in nature [Nie92],
demanding an iterative approach to the creation of software. However,
the component-based development model constructs applications from
prepackaged software components.

The Formal Methods Model: (1M)

It encompasses a set of activities that leads to formal mathematical
specification of computer software. Formal methods enable you to
specify, develop, and verify a computer-based system by applying a
rigorous, mathematical notation. A variation on this approach, called
 cleanroom software engineering is currently applied by some software
development organizations.

Aspect-Oriented Software Development(1M)

Aspect-oriented software development (AOSD), often referred to as
aspect-oriented programming (AOP), is a relatively new software
engineering paradigm that provides a process and methodological
approach for defining, specifying, designing, and constructing aspects—
―mechanisms beyond subroutines and inheritance for localizing the
expression of a crosscutting concern‖.
(Or)
10. (a) Summarize Prescriptive Process Models. (4M)
A. List of Prescriptive Process Models (1M)
Explanation of Models ( 0.5x 6 = 3M)
Prescriptive process models were originally proposed to bring order to
the chaos of software development. ―prescriptive‖ because they
prescribe a set of process elements—framework activities,
software engineering actions, tasks, work products, quality assurance,
and change control mechanisms for each project. Each process model
also prescribes a process flow (also called a work flow)—that is, the
manner in which the process elements are interrelated to one another.
The Waterfall Model:
The waterfall model, sometimes called the classic life cycle, suggests a
systematic, sequential approach6 to software development that begins
with customer specification of requirements and progresses through
planning, modeling, construction, and deployment, culminating in
ongoing support of the completed software.
Incremental Process Models:
The incremental model combines elements of linear and parallel process
flows. The incremental model applies linear sequences in a staggered
fashion as calendar time progresses. Each linear sequence
produces deliverable ―increments‖ of the software in a manner that is
similar to the increments produced by an evolutionary process flow.
Evolutionary Process Models:
Evolutionary models are iterative. They are characterized in a manner
that enables you to develop increasingly more complete versions of the
software. In the paragraphs that follow, I present two common
evolutionary process models.
Prototyping: Often, a customer defines a set of general objectives for
software, but does not identify detailed requirements for functions and
features. In other cases, the developer may be unsure of the efficiency
of an algorithm, the adaptability of an operating system, or the form
that human-machine interaction should take. In these, and many other
situations, a prototyping paradigm may offer the best approach.
The spiral development model: is a risk-driven process model
generator that is used to guide multi-stakeholder concurrent
engineering of software intensive systems. It has two main
distinguishing features. One is a cyclic approach for incrementally
growing a system’s degree of definition and implementation while
decreasing its degree of risk. The other is a set of anchor point
milestones for ensuring stakeholder commitment to feasible and
mutually satisfactory system solutions.
Concurrent Models:
The activity—modeling—may be in any one of the states12 noted at any
given time. Similarly, other activities, actions, or tasks (e.g.,
communication or construction) can be represented in an analogous
manner. All software engineering activities exist concurrently but reside
in different states.
(b) Illustrate how incremental model is employed in spiral model.
(5M)
A. Defining Spiral Model (2M)
Diagram (1M)
Explanation (2M)
The Spiral Model is an evolutionary software process model that couples
the iterative nature of prototyping with the controlled and systematic
aspects of the waterfall model. It provides the potential for rapid
development of increasingly more complete versions of the software.
Boehm [Boe01a] describes the model in the following manner:
The spiral development model is a risk-driven process model generator
that is used to guide multi-stakeholder concurrent engineering of
software intensive systems. It has two main distinguishing features.
One is a cyclic approach for incrementally growing a system’s degree of
definition and implementation while decreasing its degree of risk. The
other is a set of anchor point milestones for ensuring stakeholder
commitment to feasible and mutually satisfactory system solutions.

Using the spiral model, software is developed in a series of evolutionary

releases. During early iterations, the release might be a model or
prototype. During later iterations, increasingly more complete versions
of the engineered system are produced.
A spiral model is divided into a set of framework activities defined by
the software engineering team. For illustrative purposes, I use the
generic framework activities discussed earlier. Each of the framework
activities represent one segment of the spiral path. As this evolutionary
process begins, the software team performs activities that are implied
by a circuit around the spiral in a clockwise direction, beginning at the
center. Risk is considered as each revolution is made. Anchor point
milestones—a combination of work products and conditions that are
attained along the path of the spiral—are noted for each evolutionary
 pass. Unlike other process models that end when software is delivered,
the spiral model can be adapted to apply throughout the life of the
computer software.
11. (a) Outline the types of Requirements. (3M)
Each Requirement (1M)
A. Normal requirements: The objectives and goals that are stated for a
product or system during meetings with the customer. If these requirements
are present, the customer is satisfied. Examples of normal requirements might
be requested types of graphical displays, specific system functions, and
defined levels of performance.
Expected requirements: These requirements are implicit to the product or
system and may be so fundamental that the customer does not explicitly state
them. Their absence will be a cause for significant dissatisfaction. Examples of
expected requirements are: ease of human/machine interaction,
overall operational correctness and reliability, and ease of software
installation.
Exciting requirements: These features go beyond the customer’s
expectations and prove to be very satisfying when present. For example,
software for a new mobile phone comes with standard features, but is coupled
with a set of unexpected capabilities (e.g., multitouch screen, visual voice
mail) that delight every user of the product.

(b) Plan Establishing the Ground Work in Requirement Engineering.

(6M)
List of Plan (2M)
Explanation of Each (1x4 = 4M)
A. In an ideal setting, stakeholders and software engineers work together on
the same team. In such cases, requirements engineering is simply a matter of
conducting meaningful conversations with colleagues who are well-known
members of the team. But reality is often quite different.

Identifying Stakeholders:
Sommerville and Sawyer define a stakeholder as ―anyone who benefits in a
direct or indirect way from the system which is being developed.‖ I have
already identified the usual suspects: business operations managers, product
managers, marketing people, internal and external customers, end users,
consultants, product engineers, software engineers, support and maintenance
engineers, and others. Each stakeholder has a different view of the system,
achieves different benefits when the system is successfully developed, and is
open to different risks if the development effort should fail.

Recognizing Multiple Viewpoints:

Because many different stakeholders exist, the requirements of the system will
be explored from many different points of view. For example, the marketing
group is interested in functions and features that will excite the potential
market, making the new system easy to sell. Business managers are
interested in a feature set that can be built within budget and that will be
ready to meet defined market windows. End users may want features that are
familiar to them and that are easy to learn and use.

Working toward Collaboration:

If five stakeholders are involved in a software project, you may have five (or
more) different opinions about the proper set of requirements. I have noted
 that customers (and other stakeholders) must collaborate among themselves
(avoiding petty turf battles) and with software engineering practitioners if a
successful system is to result. But how is this collaboration accomplished?
The job of a requirements engineer is to identify areas of commonality (i.e.,
requirements on which all stakeholders agree) and areas of conflict or
inconsistency (i.e., requirements that are desired by one stakeholder but
conflict with the needs of another stakeholder). It is, of course, the latter
category that presents a challenge.

Asking the First Questions:

 Who is behind the request for this work?
 Who will use the solution?
 What will be the economic benefit of a successful solution?
 Is there another source for the solution that you need?
(Or)
12. Identify Specific Agile Methods.
List of Specific Agile Method (2M)
A. Scrum and XP are widely applied agile methods—the two most common,
according to at least one survey [Shine03]. However, there is anecdotal
evidence indicating some "XP" adoption is misunderstood as simply "not
the waterfall" and the teams are merely practicing iterative and
evolutionary development or "programming without documentation" and
calling this XP.
Scrum (2M)
Scrum's distinctive emphasis among the methods is its strong promotion of
self-organizing teams, daily team measurement, and avoidance of following
predefined steps. Some key practices include a daily stand-up meeting (the
Scrum meeting) with special questions, 30-calendar-day iterations, and a
demo to external stakeholders at the end of each iteration.
XP (2M)
XP is probably the most well known agile method; it emphasizes
collaboration, quick and early software creation, and skillful development
practices. It is founded on four values: communication, simplicity,
feedback, and courage. It includes 12 core practices, including the whole
team working together in a common room, pair programming, constant
refactoring, and test-driven development.
Crystal Methods (2M)
The Crystal family of agile methods were developed by Alistair Cockburn
[Cockburn02]. While acknowledging the necessity of an iterative lifecycle,
in this group of methods Cockburn stresses the primacy of "peopleware"
issues over process: communication, education, and so on. His definition
of software development shows this emphasis: "…a cooperative game of
invention and communication." Different versions of Crystal (Clear, Yellow,
…) contain increasing method weight (or process ceremony in terms of
defined and ordered steps, documents, reviews, etc.) as a function of staff
size, criticality, and project priority. You choose size and criticality, and
this maps to a particular version of Crystal with a recommended method
weight. Cockburn has created a scale to illustrate matching method
configurations to these factors. For example, E6 means a project of 1–6
people, where the worst that can happen from a system failure is loss of
essential money. refer to this classification model, to classify Scrum, XP,
UP, and Evo.
Any other specified above (1M)