1. Differentiate Waterfall model and Spiral model.

S.
No. Waterfall Model Spiral Model
The Waterfall model is simple The spiral model is a lot more
1. and easy. complex.
The waterfall model works in a While the spiral model works
2. sequential method. in the evolutionary method.
In the waterfall model errors or In the spiral model errors or
risks are identified and rectified risks are identified and
3. after the completion of stages. rectified earlier.
The waterfall model is adopted While the spiral model is
4. by customers. adopted by developers.
The waterfall model is While the Spiral model is
5. applicable for small projects. used for large projects.
2. Define Project Planning.

Project planning is a discipline addressing how to complete a project in a certain timeframe, usually
with defined stages and designated resources. One view of project planning divides the activity into
these steps:
 setting measurable objectives
 identifying deliverables
 scheduling
 planning tasks

3. What is the need for Requirement Analysis?

Requirements analysis is critical to the success or failure of a systems or software project. The
requirements should be documented, actionable, measurable, testable, traceable, related to
identified business needs or opportunities, and defined to a level of detail sufficient for system design.

4. Define Use Case model.

A Use Case Model describes the proposed functionality of a new system. A Use Case represents a
discrete unit of interaction between a user (human or machine) and the system. This interaction is a
single unit of meaningful work, such as Create Account or View Account Details.
Each Use Case describes the functionality to be built in the proposed system, which can include
another Use Case's functionality or extend another Use Case with its own behavior.

5. Differentiate Cohesion and Coupling.

S.No Cohesion: Coupling:

1 Cohesion is the indication of Coupling is also the indication
the relationship within the of the relationships between
module. modules.
2 It is the concept of intra It is the concept of the Inter
module. module.
3 Cohesion has many types but The coupling has also many
usually, high cohesion is good types but usually, the low
for software. coupling is good
6. Define Refactoring.

Refactoring consists of improving the internal structure of an existing program's source code, while
preserving its external behaviour

7. Differentiate Black box testing and White box Testing.

S.No Black Box Testing White Box Testing

It is a way of testing the
software in which the tester
It is a way of software testing in has knowledge about the
which the internal structure or the internal structure or the code
program or the code is hidden and or the program of the
1. nothing is known about it. software.
Code implementation is
Implementation of code is not necessary for white box
2. needed for black box testing. testing.
It is mostly done by software It is mostly done by software
3. testers. developers.
No knowledge of implementation Knowledge of
4. is needed. implementation is required.
8. State Smoke testing.

Smoke testing checks the core functionality of a program, to ensure that the program is ready for
further testing.

9. Name the areas DevOps adaptation is preferred.

DevOps automation processes into four areas

Build,
Deployment,
Test, and
Infrastructure

10. Define continuous integration.

Continuous integration is a DevOps software development practice where developers regularly merge
their code changes into a central repository, after which automated builds and tests are run.

Note to question paper setter

 Questions should be of(both subdivisions) understanding(K2) type questions OR higher Knowledge level
questions.
 Maximum of 2 subdivisions per question can be given.
 Subdivisions can be given in maximum 2 questions out of 5 questions.
11. a) Describe in detail about how a software project should be planned and scheduled.

Brief about the following

1. The product
2. The people
3. The software team
 4. Agile team
5. Coordination and communication issues

b) Describe in detail about Classical and Iterative Waterfall Model with diagrams.

Classical waterfall model divides the life cycle into a set of phases. This model considers
that one phase can be started after completion of the previous phase. That is the output of
one phase will be the input to the next phase. Thus the development process can be
considered as a sequential flow in the waterfall. Here the phases do not overlap with each
other. The different sequential phases of the classical waterfall model are shown in the
below figure:

Let us now learn about each of these phases in brief details:

1. Feasibility Study:
2. Requirements analysis and specification:
o
3. Design: The aim of the design phase is to transform the requirements specified in
the SRS document into a structure that is suitable for implementation in some
programming language.
4. Coding and Unit testing
5. Integration and System testing
6. Maintanance

The iterative waterfall model

provides feedback paths from every phase to its preceding phases, which is the main
difference from the classical waterfall model.

Feedback paths introduced by the iterative waterfall model are shown in the figure
below.
 When errors are detected at some later phase, these feedback paths allow correcting
errors committed by programmers during some phase. The feedback paths allow the
phase to be reworked in which errors are committed and these changes are reflected in
the later phases. But, there is no feedback path to the stage – feasibility study, because
once a project has been taken, does not give up the project easily.
It is good to detect errors in the same phase in which they are committed. It reduces the
effort and time required to correct the errors.

Phase Containment of Errors: The principle of detecting errors as close to their points
of commitment as possible is known as Phase containment of errors.
12. a) Explain in detail about requirement gathering and analysis. Specify the functional and non
functional requirements.

Requirement gathering and analysis:

1. Requirement Elicitation and Analysis

 Requirements discovery
 Interviewing
 Scenarios
  Use cases
 Ethonography
 Requirement classification and organization
 Requirements prioritization and negotiation
 Requirements specification

Functional Requirements: These are the requirements that the end user specifically
demands as basic facilities that the system should offer. All these functionalities need to
be necessarily incorporated into the system as a part of the contract. These are
represented or stated in the form of input to be given to the system, the operation
performed and the output expected. They are basically the requirements stated by the
user which one can see directly in the final product, unlike the non-functional
requirements.

Non-functional requirements: These are basically the quality constraints that the system must
satisfy according to the project contract. The priority or extent to which these factors are
implemented varies from one project to other. They are also called non-behavioral requirements.

b) Explain in detail about the following diagrams with example.

i) Use case Model (8)
ii) Class Diagram. (8)

USE CASE MODEL:

The Use-case model is defined as a model which is used to show how users interact with the
system in order to solve a problem. As such, the use case model defines the user's objective, the
interactions between the system and the user, and the system's behavior required to meet these
objectives.
Various model elements are contained in use-case model, such as actors, use cases, and the
association between them.
Components of Basic Model
There are various components of the basic model:
1. Actor
2. Use Case
3. Associations
Actor
Usually, actors are people involved with the system defined on the basis of their roles. An actor
can be anything such as human or another external system.
Use Case
The use case defines how actors use a system to accomplish a specific objective. The use cases
are generally introduced by the user to meet the objectives of the activities and variants involved
in the achievement of the goal.
Associations
Associations are another component of the basic model. It is used to define the associations
among actors and use cases they contribute in. This association is called communicates-
association.

Relationships
With the simple line we can represent relationships between an
actor and use cases. For relationships between use-case, we
use arrows which are labeled either "extends" or "uses". The
"extends" relationship shows the alternative options under the
specific use case. The "uses" relationship shows that single
use-case is required to accomplish a job.

Actors

o The actor's name should be meaningful and relevant to the business

If the use-case interacting with the outside organization, then we have to give the actor's
name with the function instead of the organization name, such as Airline company is
better than the PanAir).
o Place inheriting actors below the parent actor
We have to place the inheriting actors below the parent actor because it makes the actors
more readable and easily highlights the use-cases, which are exact for that actor.
o External Systems are actors
If send-email is our use-case and when the use-case interrelates with the email
management software, then in this case, the software is an actor to that specific user-case.

Use-Cases

The name of the use-case begins with a verb

The name of the use-case must be descriptive
Put the use-cases to the right of the included use-cases.
Place inheriting use-case below the parent use-case

Systems/Packages

o Give descriptive and meaningful names to these objects.

 o Use them carefully and only if needed.

Relationships

o When we are using <<extend>> arrow, points to the base use-case.

o When we are using <<include>> then arrow points to the comprised use-case.
o Actor and use-case relationship do not display arrows.
o <<extend>> may have an optional extension condition.
o <<include>> and <<extend>> both are shown as dashed arrows.

Class Diagram:

Class diagram is a static diagram. It represents the static view of an application. Class
diagram is not only used for visualizing, describing, and documenting different aspects of
a system but also for constructing executable code of the software application.
Class diagram describes the attributes and operations of a class and also the constraints
imposed on the system. The class diagrams are widely used in the modeling of
objectoriented systems because they are the only UML diagrams, which can be mapped
directly with object-oriented languages.
Class diagram shows a collection of classes, interfaces, associations, collaborations, and
constraints. It is also known as a structural diagram.

Purpose of Class Diagrams

The purpose of class diagram is to model the static view of an application. Class
diagrams are the only diagrams which can be directly mapped with object-oriented
languages and thus widely used at the time of construction.
UML diagrams like activity diagram, sequence diagram can only give the sequence flow
of the application, however class diagram is a bit different. It is the most popular UML
diagram in the coder community.
The purpose of the class diagram can be summarized as −
 Analysis and design of the static view of an application.
 Describe responsibilities of a system.
 Base for component and deployment diagrams.
 Forward and reverse engineering.

How to Draw a Class Diagram?

Class diagrams are the most popular UML diagrams used for construction of software
applications. It is very important to learn the drawing procedure of class diagram.
Class diagrams have a lot of properties to consider while drawing but here the diagram
will be considered from a top level view.
Class diagram is basically a graphical representation of the static view of the system and
represents different aspects of the application. A collection of class diagrams represent
 the whole system.
The following points should be remembered while drawing a class diagram −
 The name of the class diagram should be meaningful to describe the aspect of the
system.
 Each element and their relationships should be identified in advance.
 Responsibility (attributes and methods) of each class should be clearly identified
 For each class, minimum number of properties should be specified, as
unnecessary properties will make the diagram complicated.
 Use notes whenever required to describe some aspect of the diagram. At the end
of the drawing it should be understandable to the developer/coder.
 Finally, before making the final version, the diagram should be drawn on plain
paper and reworked as many times as possible to make it correct.
The following diagram is an example of an Order System of an application. It describes a
particular aspect of the entire application.
 First of all, Order and Customer are identified as the two elements of the system.
They have a one-to-many relationship because a customer can have multiple
orders.
 Order class is an abstract class and it has two concrete classes (inheritance
relationship) SpecialOrder and NormalOrder.
 The two inherited classes have all the properties as the Order class. In addition,
they have additional functions like dispatch () and receive ().
The following class diagram has been drawn considering all the points mentioned above.

13. a) Describe about Architectural Styles and it's types briefly.

An architectural style, sometimes called an architectural pattern, is a set of principles—a coarse

grained pattern that provides an abstract framework for a family of systems. An architectural
style improves partitioning and promotes design reuse by providing solutions to frequently
recurring problems.
Types of Architectural Styles are:-
1) Client/Server Architectural Style:-
The client/server architectural style describes distributed systems that involve a separate client
and server system, and a connecting network. The simplest form of client/server system involves
a server application that is accessed directly by multiple clients, referred to as a 2-Tier
architectural style.
Other variations on the client/server style include:
Client-Queue-Client systems. This approach allows clients to communicate with other clients
through a server-based queue. Clients can read data from and send data to a server that acts
simply as a queue to store the data.
Peer-to-Peer (P2P) applications. Developed from the Client-Queue-Client style, the P2P style
allows the client and server to swap their roles in order to distribute and synchronize files and
information across multiple clients.
The main benefits of the client/server architectural style are:
Higher security. All data is stored on the server, which generally offers a greater control of
security than client machines.
Centralized data access. Because data is stored only on the server, access and updates to the
data are far easier to administer than in other architectural styles.
2) Component-Based Architectural Style
Component-based architecture describes a software engineering approach to system design and
development. It focuses on the decomposition of the design into individual functional or logical
components that expose well-defined communication interfaces containing methods, events, and
properties.
3) Domain Driven Design (DDD) is an object-oriented approach to designing software based on
the business domain, its elements and behaviors, and the relationships between them. It aims to
enable software systems that are a realization of the underlying business domain by defining a
domain model expressed in the language of business domain experts. The domain model can be
viewed as a framework from which solutions can then be rationalized.
4) Layered Architectural Style
Layered architecture focuses on the grouping of related functionality within an application into
distinct layers that are stacked vertically on top of each other. Functionality within each layer is
related by a common role or responsibility. Communication between layers is explicit and
loosely coupled. Layering your application appropriately helps to support a strong separation of
concerns that, in turn, supports flexibility and maintainability.
5) Message Bus Architectural Style
Message bus architecture describes the principle of using a software system that can receive and
send messages using one or more communication channels, so that applications can interact
without needing to know specific details about each other. It is a style for designing applications
where interaction between applications is accomplished by passing messages (usually
asynchronously) over a common bus.
b) Explain the concepts of Design pattern and give the outline of Model-View Controller
architectural design pattern with example.

Definition
A design pattern is a general repeatable solution to a commonly occurring problem in
software design. It is a description or template for how to solve a problem that can be used in
many different situations.
2. MVC
2.1 Client server
2.2. Peer to Peer
2.3. Three tier
2.4 Four tier
2.5 Pipe and filter
Model
The Model component corresponds to all the data-related logic that the user works with. This can
represent either the data that is being transferred between the View and Controller components or
any other business logic-related data. For example, a Customer object will retrieve the customer
information from the database, manipulate it and update it data back to the database or use it to
render data.
View
The View component is used for all the UI logic of the application. For example, the Customer
view will include all the UI components such as text boxes, dropdowns, etc. that the final user
interacts with.
Controller
Controllers act as an interface between Model and View components to process all the business
logic and incoming requests, manipulate data using the Model component and interact with the
Views to render the final output. For example, the Customer controller will handle all the
interactions and inputs from the Customer View and update the database using the Customer
Model. The same controller will be used to view the Customer data.
14. a) Illustrate Integration testing and briefly explain various types of integration testing.

Integration testing is the phase in software testing in which individual software

modules are combined and tested as a group. Results of unit test can be combined and
every unit is combined other to make an integration unit. This is tested. It is said to be
integration test. This testing type hold 2 main objectives.
They are
1. To find the errors in interfaces of units
2. To assemble the individual units into working subsystems
Types of integration testing
 Bottom-Up Integration Testing
 Top-Down Integration Testing
 Mixed Integration Testing
 Big-Bang Integration Testing

b) Illustrate Regression Testing and it's process with the help of neat diagram.

The purpose of regression testing is

 To ensure the changes in work

 To ensure that the changes or additions do not break something which is already
working and should continue to work.

This type of testing is used to take fast and frequent releases and also to deliver
the stable software.

It follows the selective retesting technique. If the defect fixes are done, then there
should be a selection of test cases which have to be run inorder to check the defect fixes.
First the areas which impacted is found in an impact analysis. Based on this, some of the
 test cases are chosen. This type of testing is referred as selective retesting. Because it
concentrates on existing test cases which have been already executed.

Types: It to know about a build.

A build is an aggregation of all the defect fixes and features which are available
in the product. Normally the source code of a product is compiled first. Then defect fixes
are consolidated in the build.

Regression testing is of 2 types

They are
1. Regular regression testing
2. Final regression testing

Steps of regression testing:

 Doing a smoke or sanity test

 Understanding the criteria to choose the test cases
 Categorizing the test cases
 Method to choose the test cases
 Resetting the test cases for test execution
 Confirming the outputs of a regression cycle
15. a) Describe in detail about the Characteristics, overall architecture and building of DevOps.

Characteristics of a DevOps Organization

 Product-Based Teams Over Component Teams

 Obsession With Automation Over Preoccupation With Manual Work

 Evidence-Based Over Gutfeel
 Teamwork Over Individual Work
 Fail Fast Over Delayed Learning

b) Explain Cloud as a Platform as Software Development and Deployment. Appraise the pros and
cons of the same.

A cloud platform refers to the operating system and hardware of a server in an Internet-based
data center. It allows software and hardware products to co-exist remotely and at scale.
Enterprises rent access to compute services, such as servers, databases, storage, analytics,
networking, software, and intelligence. Therefore, the enterprises don’t have to set up and own
data centers or computing infrastructure. They simply pay for what they use.
There are several types of cloud platforms. Not a single one works for everyone. There are
several models, types, and services available to help meet the varying needs of users. They
include:
 Public Cloud: Public cloud platforms are third-party providers that deliver computing
resources over the Internet. Examples include Amazon Web Services (AWS), Google
Cloud Platform, Alibaba, Microsoft Azure, and IBM Bluemix.
 Private Cloud: A private cloud platform is exclusive to a single organization. It’s
usually in an on-site data center or hosted by a third-party service provider.
 Hybrid Cloud: This is a combination of public and private cloud platforms. Data and
applications move seamlessly between the two. This gives the organization greater
flexibility and helps optimize infrastructure, security, and compliance.
A cloud platform allows organizations to create cloud-native applications, test and build
applications, and store, back up, and recover data. It also allows organizations to analyze data.
Organizations can also stream video and audio, embed intelligence into their operations, and
deliver software on-demand on a global scale.
Pros of Cloud:
1. Lower operational costs.
2. Increased IT resources.
3. Convenient, rapid access to technology.
4. Faster connectivity.
5. Greater scale.
6. Greater expertise.
7. More reliable infrastructure.
Cons of cloud
1. A complicated shared security model.
2. Complex pricing structures.
3. Outbound data transfer costs.
4. Less flexibility than DIY environments.
5. Sketchy, inconsistent customer support.
6. Fast, redundant connectivity.
7. Cloud-specific skills.
Country- or industry-specific regulatory requirements.