For Total max Marks – 150 {120 + Int.30 (24 Mid + 6 Assign)} / 200 {160 + Int.

40 (32
Mid +8 Assign)}

GEETANJALI INSTITUTE OF TECHNICAL STUDIES, UDAIPUR

Ist MODEL PAPER 1 2021
B.Tech II Year, III Semester
Sub: Software Engineering (Code :3CS4-07)
Time: 3 Hr Max Marks: 120
Q. No. Question Marks CO
PART-A (Compulsory)
Q.1 Define software engineering? 2 CO234-07.
(a) Software engineering is an engineering branch associated with software 1
system development
(b) When you know programming, what is the need to learn 2 CO234-07.
1
software engineering concepts?
A person who knows how to build a wall may not be good at building an
entire house. Likewise, a person who can write programs may not have
knowledge of other concepts of Software Engineering. The software
engineering concepts guide programmers on how to assess requirements of
end user, design the algorithms before actual coding starts, create programs
by coding, testing the code and its documentation
(c ) How can we derive the size of software product? 2 CO234-07.
Size of software product can be calculated using either of two methods - 2
• Counting the lines of delivered code
• Counting delivered function points

(d ) What are software project estimation techniques available? 2 CO234-07.

• Decomposition technique 2
CountingLinesofCodeandFunctionPoints
• Empirical technique PutnamandCOCOMO.

(e) Definition and Importance of Data Dictionary 2 CO234-07.

Data dictionary is a file or a set of files that contains a database's metadata. 3
The data dictionary contains records about other objects in the database,
such as data ownership, data relationships to other objects, and other
data.The data dictionary is a crucial component of any relational database.
Ironically, because of its importance, it is invisible to most database users.
Typically, only database administrators interact with the data dictionary.
(f) Describe the software requirement. 2 CO234-07.
The software requirements are description of features and 3
functionalities of the target system. Requirements convey the
expectations of users from the software product. The requirements can
be obvious or hidden, known or unknown, expected or unexpected from
client’s point of view.
(g ) Define Step-wise Refinement in software design. 2 CO234-07.
4
A way of developing a computer program by first describing general
functions, then breaking each function down into details which are refined
in successive steps until the whole program is fully defined. Also called
top-down design
OR
Stepwise refinement is the idea that software is developed by moving
through the levels of abstraction, beginning at higher levels and,
incrementally refining the software through each level of abstraction,
providing more detail at each increment. At higher levels, the software is
merely its design models; at lower levels there will be some code; at the
lowest level the software has been completely developed.
At the early steps of the refinement process the software engineer does not
necessarily know how the software will perform what it needs to do. This
is determined at each successive refinement step, as the design and the
software is elaborated upon.
Refinement can be seen as the compliment of abstraction. Abstraction is
concerned with hiding lower levels of detail; it moves from lower to higher
levels. Refinement is the movement from higher levels of detail to lower
(h ) Explain Structural Partitioning in software design. 2 CO234-07.
4
The program structure should be partitioned both horizontally and
vertically.

(1) Horizontal partitioning defines separate branches of the modular

hierarchy for each major program function.

Simplest way is to partition a system into: input, data transformation

(processing), and output

Advantages of horizontal partition:

- easy to test, maintain, and extend
- fewer side effects in change propagation or error propagation

Disadvantage: more data to be passed across module interfaces

- complicate the overall control of program flow

(2) Vertical partitioning suggests the control and work should be

distributed top-down in program structure.

Advantages:
- good at dealing with changes:
- easy to maintain the changes
- reduce the change impact and and propagation
(i) What Is The Difference Between Function Oriented And Object 2 CO234-07.
Oriented Design 5
Difference Functional-oriented Approach v/s Object-oriented Design

1.FOD: The basic abstractions, which are given to the user, are real world
functions.
OOD: The basic abstractions are not the real world functions but are the
data abstraction where the real world entities are represented.

2.FOD: Functions are grouped together by which a higher level function is

Page on obtained.an eg of this technique isSA/SD.
OOD: Functions are grouped together on the basis of the data they operate
since the classes are associated with their methods.

3.FOD: In this appproach the state information is often represented in a

centralized shared memory.
OOD: In this approach the state information is not represented in a
centralized memory but is implemented or distributed among the objects of
the system.

4.FOD approach is mainly used for computation sensitive application,

OOD: whereas OOD approach is mainly used for evolving system which
mimicks a business process or business case.

5. In FOD - we decompose in function/procedure level

OOD: - we decompose in class level

6. FOD: TOp down Approach

OOD: Bottom up approach

7. FOD: It views system as Black Box that performs high level function
and later decompose it detailed function so to be maaped to modules.
OOD: Object-oriented design is the discipline of defining the objects and
their interactions to solve a problem that was identified and documented
during object-oriented analysis.

8. FOD: Begins by considering the use case diagrms and Scenarios.

(j) Define of Data object. 2 CO234-07.
A data object is a region of storage that contains a value or group of values. 5
Each value can be accessed using its identifier or a more complex
expression that refers to the object. In addition, each object has a unique
data type. The data type of an object determines the storage allocation for
that object and the interpretation of the values during subsequent access. It
is also used in any type checking operations. Both the identifier and data
type of an object are established in the object declaration.

PART-B (Attempt only 5 out of 7)

Q.2 Compare waterfall model and spiral model for software 8 CO234-07.
1
development. Which one prefer and why?
SPIRAL MODEL
WATERFALL MODEL

1] Spiral model is not suitable for small projects.

1] Waterfall model is suitable for small projects.
2] Better risk management.
2] High amount of risk and uncertainty.

3] Process is complex. 3] Easy to understand.

4] The process may go indefinitely.
4] Stages are clearly defined.
5] This model is suitable for long and ongoing projects.
5] This model is not suitable for long and ongoing projects.
6] Iterations are followed 6] Sequence is followed
7] Flexible with user requirements 7] Requirements once fixed
cannot be modified
8] Refinements are easily possible 8] Refinements are not so easy
9] Phases are repeated itself 9] Phases are processed and completed
one at a time.

Q.3 Illustrate the project planning objective? How they can be 8 CO234-07.
2
achieve?
The objective of software project planning is
to provide a framework that enables the
manager to make reasonable estimates of:
· Resources
· Cost, and
· Schedule
These estimates are made within a limited time frame at the beginning of
a software
project and should be updated regularly as the project progress.
In addition, estimates should attempt to define best case and worst-
case scenarios so
that project outcomes can be bounded.
Planning is one of the most important management activities and is
an ongoing effort
throughout the life of the project.
Software project management
begins with a set of activities that are collectively
called Project Planning
Primary Planning Steps
Once the scope of the project has been defined in the Terms of Reference, t
he project
enters the detailed planning phase. This involves the creation of a:
1.
Project Plan (outlining the activities, tasks, dependencies and timeframes)
Q4 Explain the Requirement analysis tasks 8 CO234-07.
3
The requirment analysis task is a process of discovery
refinment modeling and Specification
Q.5 Describe flowchart and box diagrams used in Procedural 8 CO234-07.
4
Programming.
Component-level design, also called procedural design, occurs after data,
architectural, and interface designs have been established

What is it? Data, architectural, and interface design must be translated into
operational software. To accomplish this, the design must be represented at a
level of abstraction that is close to code.

Component-level design establishes :-

1. The algorithmic detail required to manipulate datastructures,
2. Effect communication between software components via their
interfaces, and
3. Implement the processing algorithms allocated to eachcomponent.

Who does it? A software engineer performs component-level design.

Why is it important? You have to be able to determine whether the program
will work before you build it. The component-level design represents the
software in a way that allows you to review the details of the design for
correctness and consistency with earlier design representations (i.e., the data,
architectural, and interface designs). It provides a means for assessing whether
data structures, interfaces, and algorithms will work.

What are the steps? Design representations of data, architecture, and interfaces
form the foundation for component-level design. The processing narrative for
each component is translated into a proceduraldesign model using a set of
structured programming constructs.Graphical, tabular, or text-based notation is
used to represent the design
approach is to represent the procedural design using some intermediate
(e.g.,graphical, tabular, or text-based) representation that can be translated
easily into source code

16.1 STRUCTURED PROGRAMMING

In the late 1960s, Dijkstra and others proposed the use of a set of constrained
logical constructs from which any program could be formed
The constructs are sequence, condition, and repetition. Sequence implements
processing steps that are essential in the specification of any algorithm.
Condition provides the facility for selected processing based on some logical
occurrence, and repetition allows for looping. These three constructs are
fundamental to structuredprogramming—an important component-level design
technique.
The structured constructs were proposed to limit the procedural design of
software to a small number of predictable operations. Complexity metrics
indicate that the use of the structured constructs reduces program complexity
and thereby enhances readability, testability, and maintainability.logical chunks
that allow a reader to recognize procedural elements of a module, rather than
reading the design or code line by lineAny program, regardless of application
area or technical complexity, can be designed and implemented using only the
three structured constructs

16.1.1 Graphical Design Notation

Figure 16.1 illustrates three structured construct

Q.6 Explain Object Oriented concept with example. 8 CO234-07.
5
Object Oriented programming is a programming style which is associated with
the concepts like class, object, Inheritance, Encapsulation, Abstraction,
Polymorphism. Most popular programming languages like Java, C++, C#,
Ruby, etc. follow an object oriented programming paradigm. In this blog, I will
talk about object oriented programming concepts in Java. An object-based
application in Java is based on declaring classes, creating objects from them
and interacting between these objects. I have discussed Java Classes and
Objects which is also a part of object-oriented programming concepts, in my
previous blog. In this blog, we will understand the below core concepts of
Object oriented Programming in the following sequence:
1. Inheritance
In OOP, computer programs are designed in such a way where everything
is an object that interact with one another. Inheritance is one such concept
where the properties of one class can be inherited by the other. It helps
to reuse the code and establish a relationship between different classes.
2. Encapsulation
Encapsulation is a mechanism where you bind your data and code together
as a single unit. It also means to hide your data in order to make it safe
from any modification. What does this mean? The best way to understand
encapsulation is to look at the example of a medical capsule, where the
drug is always safe inside the capsule. Similarly, through encapsulation the
methods and variables of a class are well hidden and safe.
3. Abstraction
Abstraction refers to the quality of dealing with ideas rather than events. It
basically deals with hiding the details and showing the essential things to
the user. If you look at the image here, whenever we get a call, we get an
option to either pick it up or just reject it. But in reality, there is a lot of
code that runs in the background. So you don’t know the internal
processing of how a call is generated, that’s the beauty of abstraction.
Therefore, abstraction helps to reduce complexity. You can achieve
abstraction in two ways:
a) Abstract Class
b) Interface
4. Polymorphism
Polymorphism means taking many forms, where ‘poly’ means many and
‘morph’ means forms. It is the ability of a variable, function or object to
take on multiple forms. In other words, polymorphism allows you define
one interface or method and have multiple implementations.
Q.7 Explain the difference between Verification and Validation 8 CO234-07.
1
Verification Validation
Are we building the system right? Are we building the right system?
Verification is the process of evaluating products of a development phase
to find out whether they meet the specified requirements. Validation is
the process of evaluating software at the end of the development process to
determine whether software meets the customer expectations and
requirements.
The objective of Verification is to make sure that the product being develop
is as per the requirements and design specifications. The objective
of Validation is to make sure that the product actually meet up the user’s
requirements, and check whether the specifications were correct in the first
place.
Following activities are involved in Verification: Reviews, Meetings and
Inspections. Following activities are involved in Validation: Testing
like black box testing, white box testing, gray box testing etc.
Verification is carried out by QA team to check whether implementation
software is as per specification document or not. Validation is carried
out by testing team.
Execution of code is not comes under Verification.Execution of code is
comes under Validation.
Verification process explains whether the outputs are according to inputs
or not. Validation process describes whether the software is accepted by
the user or not.
Verification is carried out before the Validation. Validation activity is
carried out just after the Verification.
Following items are evaluated during Verification: Plans, Requirement
Specifications, Design Specifications, Code, Test Cases etc, Following item
is evaluated during Validation: Actual product or Software under test.
Cost of errors caught in Verification is less than errors found in Validation.
Cost of errors caught in Validation is more than errors found in
Verification.
It is basically manually checking the of documents and files like
Q.8 What are the relative advantages of using either the LOC and 8 CO234-07.
2
FP matrix. The major size pf s/w product.
LOC FP
Language & technology
LOC is language dependent FP is independent of language
Communication with clients Most of the clients are not familiar with
LOC Functionality (FP) is relatively easy to communicate with the
client
Tools There are many software tools for counting LOC There is not
any automated tool for FP
Usage time LOC has a good result in the design stage F P is
applicable in early stage of requirements gathering
Language & technology LOC is language dependent FP is
independent of language

PART-C (Attempt only 4 out of 5)

Q.6 Explain SRS and its components 15 CO234-07.
The output of the requirements phase of the software development 1
process is Software Requirements Specification (SRS) (also known
as requirements document). This document lays a foundation for
software engineering activities and is created when entire requirements
are elicited and analyzed. SRS is a formal document, which acts as a
representation of software that enables the users to review whether it
(SRS) is according to their requirements. In addition, it includes user
requirements for a system as well as detailed specifications of the
system requirements.
OR
IEEE defines software requirements specification as, 'a document that
clearly and precisely describes each of the essential requirements
(functions, performance, design constraints and quality attributes) of
the software and the external interfaces. Each requirement is defined in
such a way that its achievement can be objectively verified by a
prescribed method, for example, inspection, demonstration, analysis or
test.' Note that requirements specification can be in the form of a
written document, a mathematical model, a collection of graphical
models, a prototype, and so on.
Introduction to Components of the SRS

In previous section, we discussed various characteristics that will help

in completely specification the requirements. Here we describe some
of system properties that an SRS should specify. The basic issues, an
SRS must address are:
Functional requirements
Performance requirements
Design constraints
External interface requirements
Conceptually, any SRS should have these components. Now we will
discuss them one by one.
1. Functional Requirements
Functional requirements specify what output should be produced from
the given inputs. So they basically describe the connectivity between
the input and output of the system. For each functional requirement:
1. A detailed description of all the data inputs and their sources, the
units of measure, and the range of valid inputs be specified:
2. All the operations to be performed on the input data obtain the
output should be specified, and
3. Care must be taken not to specify any algorithms that are not parts
of the system but that may be needed to implement the system.
4. It must clearly state what the system should do if system behaves
abnormally when any invalid input is given or due to some error
during computation. Specifically, it should specify the behaviour of
the system for invalid inputs and invalid outputs.
2. Performance Requirements (Speed Requirements)
This part of an SRS specifies the performance constraints on the
software system. All the requirements related to the performance
characteristics of the system must be clearly specified. Performance
requirements are typically expressed as processed transaction s per
second or response time from the system for a user event or screen
refresh time or a combination of these. It is a good idea to pin down
performance requirements for the most used or critical transactions,
user events and screens.
2. Design Constraints
The client environment may restrict the designer to include some
design constraints that must be followed. The various design
Q.7 Explain Project Scheduling. 15 CO234-07.
2
Basic Principles of Project Scheduling
Software project scheduling is an activity that distributes estimated
effort across the planed project duration by allocating the effort to
specific software engineering tasks.
First, a macroscopic schedule is developed. a detailed schedule is
redefined for each entry in the macroscopic schedule.
A schedule evolves over time.
Basic principles guide software project scheduling:
- Compartmentalization
- Interdependency
- Time allocation
- Effort allocation
- Effort validation
- Defined responsibilities
- Defined outcomes
- Defined milestones
Q.8 Differentiate between DFD and CFD 15 CO234-07.
Data flow diagrams are welcomed tools used in structured analysis and 3

design methods, showing the flow of information through a system.

Each process transforms input into outputs. Begin analyzing by
diagramming an overall view of the system, typically by drawing a
context diagram. Then methodically detail each process in a
diagrammed top-down approach, starting with the level one identifying
the major system process and proceeding to level two in order to
further analyze the process. The data flow diagram results are a series
of diagrams representing the system activity in a clear and concise
manner.

Using a Data Flow Diagram

When using a data flow diagram to illustrate the processes of a system,
it is necessary to use five symbols. The external entity, an oval,
represents a source or destination of a data flow outside the area of
study. The process, a rectangular box, represents the manipulation of
data flows within the system. A line represents the data flow with
arrows showing the direction flow, typically from its source to its
destination. A data store is a storage bin for information within the
system, represented by an open-ended narrow rectangle. A resource
flow shows the flow of any physical material from its source to its
destination.

Control Flow Diagrams

A control flow diagram helps us understand the detail of a process. It
shows us where control starts and ends and where it may branch off in
another direction, given certain situations. Let's say you are working
on software to start a machine. What happens if the engine is flooded,
or a spark plug is broken? Control then changes the flow to other parts
of the software. We can represent these branches with a diagram. The
Q.7 Explain briefly Design Documentation. 15 CO234-07.
4
IEEE defines software design documentation as 'a description of
software created to facilitate analysis, planning, implementation, and
decision-making. This design description is -used as a medium for
communicating software design information and can be considered as
a blueprint or model of the system.
While developing SDD, the design should be described up to the
refinement level that is sufficient for explaining every task including
inter-task communications, data structures, and databases. No
refinement of any task should be left to be made during the coding
phase.
The information that the software design document should describe
depends on various factors including the type of software being
developed and the approach used in its development. A number of
standards have been suggested to develop a software design document.
However, the most widely used standard is by IEEE, which acts as a
general framework. This general framework can be customized and
adapted to meet the needs of a particular organization. This template
consists of several sections, which are listed below.
1. Scope: Identifies the release or version of the system being
designed. The system is divided into modules; the relationship
between them and functionalities will be defined. Every
iteration of the SDD document describes and identifies the
software modules to be added or changed in a release.
2. References: Lists references (both hardware and software
documents and manuals) used in the creation of the SDD that
may be of use to the designer, programmer, user, or
management personnel. This document is also considered
useful for the readers of the document. In this section, any
references made to the other documents including references
to related project documents, especially the SRS are also
listed. The existing software documentation (if any) is also
listed.
3. Definition: Provides a glossary of technical terms used in the
document along with their definitions.
4. Purpose: States the purpose of this document and its intended
audience. This is meant primarily for individuals who will be
implementing the system.
5. Design description information content: Consists of the
following subsections.
1. Introduction: Since SDD represents the software design that
is to be implemented, it should describe the design entities
into which the system has been partitioned along with their
significant properties and relationships.
2. Design entity: It is a software design component that is
different from other design entities in terms of structure and
function. The objective of creating design entities is to
partition the system into a set of components that can be
implemented and modified independently. Note that each
design entity is assigned with a unique name and serves a
specific purpose and function but all possess some common
characteristics.
3. Design entity attributes: They are properties of the design
entity and provide some factual information regarding the
entity. Every attribute has an attached description, which
includes references and design considerations.
Table Attributes and Description
Attributes Description
Q.8 Define different UML Diagrams with example. 15 CO234-07.
5

UML Use Case Diagram

Purpose
Use case diagram is used during the analysis phase of a
project to identify the system functionality. It describes the
interaction of people or external device with the system under
design. It doesn't show much detail, but only summarizes
some of the relationships between use cases, actors, and
systems.
Usage
Basically four elements need to be included in use case
diagram. They are actors, system, use case, and relationship.
Actors represent whoever or whatever interact with the
system. They can be humans, other computers, or other
software systems. Use cases represent the actions that are
performed by one or more actors for a particular goal. System
is whatever you are developing.

Learn More at: Use Case Diagram

How to Create a Use Case Diagram
UML Sequence Diagram

Purpose
Sequence diagrams are used in the analysis and design
phases. It's an interaction diagram that details how operations
are carried out. Sequence diagram is often used to depict the
chronologically-structured event flow through a use case. It's
good at presenting the communication relationships between
objects; and what messages trigger those communications.