Vivekanand Education Society’s Institute of Technology, Chembur, Mumbai,

Department Of Computer Engineering,

Year:2019-20 Even Sem)
Test No.- 1

Class : D12 Division: A/B/C

Semester:VI Subject: Software Engineering
Date:20 /2/2020 Time: 1 hr

Course
CO1 CO2 CO3 CO4 CO5 CO6
Outcome

% 25% 45% 30%

Q.1) (Attempt any five of the following)

Explain the process of CMM.

CMM was developed by the Software Engineering Institute (SEI) at Carnegie Mellon University
in 1987. It is not a software process model. It is a framework which is used to analyse the
approach and techniques followed by any organization to develop a software product.

The 5 levels of CMM are as follows:

Level-1: Initial –

No KPA’s defined. Processes followed are adhoc and immature and are not well defined.
Unstable environment for software development. No basis for predicting product quality, time
for completion, etc.
a)
Level-2: Repeatable –

Focuses on establishing basic project management policies. Experience with earlier projects is
used for managing new similar natured projects.

Level-3: Defined –

At this level, documentation of the standard guidelines and procedures takes place. It is a well
defined integrated set of project specific software engineering and management processes.

Level-4: Managed –

At this stage, quantitative quality goals are set for the organization for software products as well
 as software processes. The measurements made help the organization to predict the product and
process quality within some limits defined quantitatively.

Level-5: Optimizing –

This is the highest level of process maturity in CMM and focuses on continuous process
improvement in the organization using quantitative feedback. Use of new tools, techniques and
evaluation of software processes is done to prevent recurrence of known defects.

Draw the Use case diagram for ATM Application System.

b)

Illustrate requirement elicitation and elaboration in requirement engineering?

c) Requirement Elicitation Process

Requirement elicitation process can be depicted using the folloiwng diagram:
 ● Requirements gathering - The developers discuss with the client and end users and
know their expectations from the software.
● Organizing Requirements - The developers prioritize and arrange the requirements
in order of importance, urgency and convenience.
● Negotiation & discussion - If requirements are ambiguous or there are some conflicts
in requirements of various stakeholders, if they are, it is then negotiated and
discussed with stakeholders. Requirements may then be prioritized and reasonably
compromised.
The requirements come from various stakeholders. To remove the ambiguity and
conflicts, they are discussed for clarity and correctness. Unrealistic requirements are
compromised reasonably.
● Documentation - All formal & informal, functional and non-functional requirements
are documented and made available for next phase processing.

Requirement Elicitation Techniques

Requirements Elicitation is the process to find out the requirements for an intended
software system by communicating with client, end users, system users and others
who have a stake in the software system development.

There are various ways to discover requirements

Interviews
Interviews are strong medium to collect requirements. Organization may conduct
several types of interviews such as:
● Structured (closed) interviews, where every single information to gather is decided in
advance, they follow pattern and matter of discussion firmly.
● Non-structured (open) interviews, where information to gather is not decided in
advance, more flexible and less biased.
● Oral interviews
● Written interviews
● One-to-one interviews which are held between two persons across the table.
● Group interviews which are held between groups of participants. They help to
uncover any missing requirement as numerous people are involved.

Surveys
Organization may conduct surveys among various stakeholders by querying about their
expectation and requirements from the upcoming system.
Questionnaires
A document with pre-defined set of objective questions and respective options is
handed over to all stakeholders to answer, which are collected and compiled.

A shortcoming of this technique is, if an option for some issue is not mentioned in the
questionnaire, the issue might be left unattended.

Task analysis
Team of engineers and developers may analyze the operation for which the new
system is required. If the client already has some software to perform certain operation,
it is studied and requirements of proposed system are collected.

Domain Analysis
Every software falls into some domain category. The expert people in the domain can
be a great help to analyze general and specific requirements.

Brainstorming
An informal debate is held among various stakeholders and all their inputs are
recorded for further requirements analysis.

Prototyping
Prototyping is building user interface without adding detail functionality for user to
interpret the features of intended software product. It helps giving better idea of
requirements. If there is no software installed at client’s end for developer’s reference
and the client is not aware of its own requirements, the developer creates a prototype
based on initially mentioned requirements. The prototype is shown to the client and the
feedback is noted. The client feedback serves as an input for requirement gathering.

Observation
Team of experts visit the client’s organization or workplace. They observe the actual
working of the existing installed systems. They observe the workflow at client’s end and
how execution problems are dealt. The team itself draws some conclusions which aid
to form requirements expected from the software.

To discover this information, requirements engineering contains a number of

overlapping steps:

1. Inception​, in which the nature and scope of the system is defined.

2. Elicitation​, in which the requirements for the software are initially gathered.
 3. Elaboration​, in which the gathered requirements are refined.
4. Negotiation​, in which the priorities of each requirement is determined, the
essential requirements are noted, and, importantly, conflicts between the
requirements are resolved.
5. Specification​, in which the requirements are gathered into a single product,
being the result of the requirements engineering.
6. Validation​, in which the quality of the requirements (i.e., are they unambiguous,
consistent, complete, etc.), and the developer's interpretation of them, are
assessed.
7. Management​, in which the changes that the requirements must undergo during
the project's lifetime are managed.

Requirements engineering will usually result in one or more work products being
produced. These products, taken together, represent the software's specification (see
the specification step previously mentioned, and detailed below). These work products,
however, do not have to be formal, written documents — indeed, the work products can
be a set of models, a formal mathematical specification, a collection of use cases or
user stories, or even a software prototype.

d) Draw activity diagram for railway reservation system.

 Explain 4 desirable characteristics of good SRS Document.
e)
Following are the characteristics of a good SRS document:
 1. Correctness: User review is used to ensure the correctness of requirements stated in the
SRS. SRS is said to be correct if it covers all the requirements that are actually expected from the
system.

2. Completeness: Completeness of SRS indicates every sense of completion including the

numbering of all the pages, resolving the to be determined parts to as much extent as possible as
well as covering all the functional and non-functional requirements properly.

3. Consistency: ​Requirements in SRS are said to be consistent if there are no conflicts

between any set of requirements. Examples of conflict include differences in terminologies used
at separate places, logical conflicts like time period of report generation, etc.

4. Unambiguousness: ​An SRS is said to be unambiguous if all the requirements stated

have only 1 interpretation. Some of the ways to prevent unambiguousness include the use of
modelling techniques like ER diagrams, proper reviews and buddy checks, etc.

5. Modifiability: SRS should be made as modifiable as possible and should be capable of

easily accepting changes to the system to some extent. Modifications should be properly indexed
and cross-referenced.

6. Verifiability​: An SRS is verifiable if there exists a specific technique to quantifiably

measure the extent to which every requirement is met by the system. For example, a requirement
stating that the system must be user-friendly is not verifiable and listing such requirements
should be avoided.

7. Traceability: One should be able to trace a requirement to a design component and then
to a code segment in the program. Similarly, one should be able to trace a requirement to the
corresponding test cases.

8. Design Independence: There should be an option to choose from multiple design

alternatives for the final system. More specifically, the SRS should not include any
implementation details.

9. Testability: An SRS should be written in such a way that it is easy to generate test cases
and test plans from the document.

10. ​Right level of abstraction: If the SRS is written for the requirements phase, the details
should be explained explicitly. Whereas, for a feasibility study, fewer details can be used. Hence,
the level of abstraction varies according to the purpose of the SRS.

f) Explain Scrum Cycle.

We first need to determine a Product Backlog (a list of product requirements in order of priority),
which is the responsibility of the Product Owner

The Scrum Team makes estimates and arrangements for the workload based on the Product
Backlog list in Product Backlog Refinement Meeting

With the Product Backlog list, we need to hold a Sprint Planning Meeting for defining the sprint
goal of this iteration (the time period of a Sprint is typically 1 to 4 weeks), then selected a list of
user stories to form the Sprint Backlog for the coming sprint which could fulfill the sprint goal.

Sprint Backlog is completed by the Scrum Team, each member is refined into smaller tasks
according to the Sprint Backlog (the workload of each task can be completed within a few days)

Within the Sprint, a Daily Scrum Meeting is required and each of the meetings is time-boxed in
about 15 minutes. Everyone must speak and face-to-face to interact with all members for
reporting what you did yesterday, and commit what you want to accomplish today, and you can
ask questions related to impediment or problems that you can’t solve. Then, update your Sprint
burn down Chart.

To achieve daily integration, that is, every day must have a version that can be successfully
compiled and can be demonstrated; many people may not have used automated daily integration.
 If it passes, the unit test code is executed immediately. If all of them are passed, the version is
released.

When all the user stories are completed, that is, the Sprint Backlog is completed, it means that a
Sprint is completed. At this time, we need to conduct a Sprint Review Meeting (also known as a
review meeting). The product owner and the customer must participate. Every member of the
Scrum Team will demonstrate to them the working software they have completed and this
meeting is very important and must not be cancelled.

Finally, The Sprint Retrospective is held after the sprint review at the end of each sprint. During
the retrospective, the team self-identifies elements of the process that did or did not work during
the sprint, along with potential solutions. Retrospectives typically last 90 minutes and are there to
help us incorporate continuous improvement into our team culture and into our Sprint cadence.

Explain Prototyping Model with its advantages and disadvantages.

The basic idea in Prototype model is that instead of freezing the requirements before a design or
coding can proceed, a throwaway prototype is built to understand the requirements. This
prototype is developed based on the currently known requirements. Prototype model is a
software development model. By using this prototype, the client can get an “actual feel” of the
system, since the interactions with prototype can enable the client to better understand the
requirements of the desired system. Prototyping is an attractive idea for complicated and large
systems for which there is no manual process or existing system to help determining the
requirements.
The prototype are usually not complete systems and many of the details are not built in the
prototype. The goal is to provide a system with overall functionality.
Diagram for Prototype Modeling:

Q.2) a)

Advantages of Prototype model:

● Users are actively involved in the development

● Since in this methodology a working model of the system is provided, the users
get a better understanding of the system being developed.
 ● Errors can be detected much earlier.
● Quicker user feedback is available leading to better solutions.
● Missing functionality can be identified easily
● Confusing or difficult functions can be identified
Requirements validation, Quick implementation of, incomplete, but
functional, application.

Disadvantages of Prototype model:

● Leads to implementing and then repairing way of building systems.

● Practically, this methodology may increase the complexity of the system as scope
of the system may expand beyond original plans.
● Incomplete application may cause application not to be used as the
full system was designed
Incomplete or inadequate problem analysis.

OR
Explain Extreme programming technique in Agile methodology
b)
Extreme programming (XP) is one of the most important software development framework of

Agile models. It is used to improve software quality and responsive to customer requirements.

The extreme programming model recommends taking the best practices that have worked well in

the past in program development projects to extreme levels.

Good practices needs to practiced extreme programming: Some of the good practices that have

been recognized in the extreme programming model and suggested to maximize their use are

given below:

● Code Review: Code review detects and corrects errors efficiently. It suggests pair
programming as coding and reviewing of written code carried out by a pair of
programmers who switch their works between them every hour.
 ● Testing: Testing code helps to remove errors and improves its reliability. XP
suggests test-driven development (TDD) to continually write and execute test
cases. In the TDD approach test cases are written even before any code is written.
● Incremental development: Incremental development is very good because
customer feedback is gained and based on this development team come up with
new increments every few days after each iteration.
● Simplicity: Simplicity makes it easier to develop good quality code as well as to
test and debug it.
● Design: Good quality design is important to develop a good quality software. So,
everybody should design daily.
● Integration testing: It helps to identify bugs at the interfaces of different
functionalities. Extreme programming suggests that the developers should achieve
continuous integration by building and performing integration testing several times
a day.

Basic principles of Extreme programming: XP is based on the frequent iteration through which

the developers implement User Stories. User stories are simple and informal statements of the

customer about the functionalities needed. A User story is a conventional description by the user

about a feature of the required system. It does not mention finer details such as the different

scenarios that can occur. On the basis of User stories, the project team proposes Metaphors.

Metaphors are a common vision of how the system would work. The development team may

decide to build a Spike for some feature. A Spike is a very simple program that is constructed to

explore the suitability of a solution being proposed. It can be considered similar to a prototype.

Some of the basic activities that are followed during software development by using XP model

are given below:

● Coding: The concept of coding which is used in XP model is slightly different

from traditional coding. Here, coding activity includes drawing diagrams
 (modeling) that will be transformed into code, scripting a web-based system and
choosing among several alternative solutions.
● Testing: XP model gives high importance on testing and considers it be the
primary factor to develop a fault-free software.
● Listening: The developers needs to carefully listen to the customers if they have to
develop a good quality software. Sometimes programmers may not have the depth
knowledge of the system to be developed. So, it is desirable for the programmers
to understand properly the functionality of the system and they have to listen to the
customers.
● Designing: Without a proper design, a system implementation becomes too
complex and very difficult to understand the solution, thus it makes maintenance
expensive. A good design results elimination of complex dependencies within a
system. So, effective use of suitable design is emphasized.
● Feedback: One of the most important aspects of the XP model is to gain feedback
to understand the exact customer needs. Frequent contact with the customer makes
the development effective.
● Simplicity: The main principle of the XP model is to develop a simple system that
will work efficiently in present time, rather than trying to build something that
would take time and it may never be used. It focuses on some specific features that
are immediately needed, rather than engaging time and effort on speculations of
future requirements.

Applications of Extreme Programming (XP): Some of the projects that are suitable to develop

using XP model are given below:

● Small projects: XP model is very useful in small projects consisting of small teams
as face to face meeting is easier to achieve.
● Projects involving new technology or Research projects: This type of projects face
changing of requirements rapidly and technical problems. So XP model is used to
complete this type of projects.
 Compute the function point value for a project with the following information domain
characteristics:
(1) No. of user inputs = 30
(2) No. of user outputs = 20
(3) No. of user inquiries = 08
(4) No. of files = 7
(5) No. of external interfaces = 6
Assume all complexity adjustment values are moderate ,14 algorithms have been counted and
consider Weighting Factor as average.

a)
Q.3)

OR

b) An application has the following:

10 low external inputs, 12 high external outputs, 20 low
 internal logical files, 15 high external interface files, 12
average external inquiries, and a value of complexity
adjustment factor of 1.10.
Compute the function point value for the Application

~ All the best!!! ~