Software Engineering

Section A
Answer any 10 questions

1. What is Software Engineering.

is the process of designing, developing, testing and maintaining software. It is a systematic and
disciplined approach to software development that aims to create high quality, reliable and
maintainable software.

2. Expand SDLC.
System (or) Software Development Life Cycle
SDLC is an approach for making software for the developer, user and customer. SDLC focus on the
initial phase to the end phase for making particular software. It generally deals with the analyser and
corresponding clients. The phases of SDLC are
 Project identification
 Feasibility Study
 System analysis
 System design
 System development
 System testing
 System implementation
 System Maintenance
 System documentation

3. What is the goal of the requirement analysis and specification phase.

The goal of the requirements analysis and specification phase is to clearly understand the customer
requirements and to systematically organize the requirements into a document called the Software
Requirements Specification (SRS) document.

4. Define Stack holder.

A stakeholder is an individual, group, or organization that has a vested interest or stake in the decision-
making and activities of a business, organization, or project, and can be positively or negatively
impacted by its outcomes.

5. What is SRS.
The SRS is a specification for a specific software product, program, or set of applications that
perform particular functions in a specific environment.

6. What is Cohesion.

In software engineering, cohesion refers to the degree to which elements within a module, class, or
component are related and work together to achieve a single, well-defined purpose. High cohesion
means elements are tightly focused on a specific task, while low cohesion suggests elements are
loosely related and may be doing unrelated things.
7. Define Context Diagram.

A context diagram is a high-level, visual representation that outlines the scope of a system, showing its
interactions with external entities and illustrating data flows, often used to clarify system boundaries
and requirements early in a project.

8. Explain UML.
Unified Modeling Language (UML) is a general-purpose modeling language. The main aim of UML is
to define a standard way to visualize the way a system has been designed. It is quite similar to
blueprints used in other fields of engineering. UML is not a programming language, it is rather a visual
language.
 9. What is testing.
In the context of software development, "testing" refers to the process of evaluating and verifying that a
software product or application functions as intended and meets the specified requirements.

10. Define Coding.

In the context of software testing, "coding" refers to the process of writing instructions for a computer
to perform specific tasks, typically using programming languages, which are then tested to ensure they
function as intended.

11. Explain Encapsulation.

In software engineering, encapsulation is a core principle of object-oriented programming where data

(attributes) and the methods (functions) that operate on that data are bundled together into a single unit
(a class), restricting direct access to some of the object's components, and providing a controlled
interface for interaction.

12. What is verification and validation.

Validation is the process of checking whether the specification captures the customer's requirements,
while verification is the process of checking that the software meets specifications.

Section B
Answer any 5 Questions

13. Illustrate Waterfall Model.

The Waterfall Model is a classical software development methodology. It was first introduced by
Winston W. Royce in 1970. It is a linear and sequential approach to software development that consists
of several phases. It must be completed in a specific order. This classical waterfall model is simple and
idealistic. It was once very popular. Today, it is not that popularly used. However, it is important
because most other types of software development life cycle models are a derivative of this.

The Waterfall Model has six phases which are:

1. Requirements: The first phase involves gathering requirements from stakeholders and analyzing
them to understand the scope and objectives of the project.
2. Design: Once the requirements are understood, the design phase begins. This involves creating a
detailed design document that outlines the software architecture, user interface, and system
components.
3. Development: The Development phase include implementation involves coding the software based
on the design specifications. This phase also includes unit testing to ensure that each component of
the software is working as expected.
4. Testing: In the testing phase, the software is tested as a whole to ensure that it meets the
requirements and is free from defects.
5. Deployment: Once the software has been tested and approved, it is deployed to the production
environment.
6. Maintenance: The final phase of the Waterfall Model is maintenance,which involves fixing any
issues that arise after the software has been deployed and ensuring that it continues to meet the
requirements over time.

14. Explain about the operational semantics.

Operational semantics in software engineering defines the meaning of a programming language by
describing how a program executes, essentially acting as a mathematical model of the language's
execution. It specifies how a program is interpreted as a sequence of computational steps, which then
become the meaning of the program.

Types of Operational Semantics:

Structural Operational Semantics (Small-step semantics): Describes how individual steps of a

computation take place.
Natural Semantics (Big-step semantics): Describes how the overall results of the executions are
obtained.

15. List the characteristics of a Good SRS document.

A good Software Requirements Specification (SRS) document should be clear, concise, complete,
consistent, unambiguous, verifiable, modifiable, and traceable.
Here's a more detailed breakdown of these characteristics:

Clear and Concise:

The SRS should be easy to understand, using simple language and avoiding jargon.

Complete: It should cover all aspects of the software's functionality and non-functional requirements.

Consistent: The requirements should not contradict each other, and the terminology should be used
consistently throughout the document.

Unambiguous: Each requirement should have only one possible interpretation, leaving no room for
misinterpretation.

Verifiable: Each requirement should be testable and measurable, allowing developers to determine if
the software meets the requirements.

Modifiable: The SRS should be easy to update and change as the software development process
progresses.

Traceable: Each requirement should be traceable to its source and to other related requirements,
making it easier to track changes and ensure that all requirements are met.

Feasible: The requirements should be realistic and achievable within the constraints of the project.

Prioritized: The SRS should prioritize requirements, so that the most important requirements are
addressed first.
 Structured: The SRS should be well-organized, making it easy to navigate and understand.

Black-box view: The SRS should define what the system should do, not how it should do it.

16. Explain the concept of structured analysis and structure analysis tools.

Structured analysis is a systematic, process-oriented approach in software engineering that uses

graphical tools to understand and model systems by breaking down complex problems into smaller,
manageable parts, focusing on data flow and processes. Tools like Data Flow Diagrams (DFDs) and
Entity-Relationship Diagrams (ERDs) are used to visualize and document system requirements and
designs.
Here's a more detailed explanation:
What is Structured Analysis?

Process-Oriented:

Structured analysis focuses on the processes and data flow within a system rather than the specific
implementation details.

Graphical Representation:

It uses diagrams and other graphical tools to represent the system's structure and behavior, making it
easier to understand and communicate.

Top-Down Approach:

Structured analysis typically starts with high-level overviews and then refines them into more detailed
specifications.

Systematic:

It provides a structured and organized approach to system analysis and design, ensuring a clear and
consistent methodology.

17. Explain the classification of the coupling.

Coupling refers to the degree of interdependence between software modules. High coupling means that
modules are closely connected and changes in one module may affect other modules. Low coupling
means that modules are independent, and changes in one module have little impact on other modules.
Coupling is the measure of the degree of interdependence between the modules. A good software will
have low coupling.

Following are the types of Coupling:

 Data Coupling: If the dependency between the modules is based on the fact that they communicate
by passing only data, then the modules are said to be data coupled. In data coupling, the components
are independent of each other and communicate through data. Module communications don’t
contain tramp data. Example-customer billing system.
 Stamp Coupling In stamp coupling, the complete data structure is passed from one module to
another module. Therefore, it involves tramp data. It may be necessary due to efficiency factors- this
choice was made by the insightful designer, not a lazy programmer.
 Control Coupling: If the modules communicate by passing control information, then they are said to
be control coupled. It can be bad if parameters indicate completely different behavior and good if
parameters allow factoring and reuse of functionality. Example- sort function that takes comparison
function as an argument.
 External Coupling: In external coupling, the modules depend on other modules, external to the
software being developed or to a particular type of hardware. Ex- protocol, external file, device
format, etc.
 Common Coupling: The modules have shared data such as global data structures. The changes in
global data mean tracing back to all modules which access that data to evaluate the effect of the
change. So it has got disadvantages like difficulty in reusing modules, reduced ability to control data
accesses, and reduced maintainability.
 Content Coupling: In a content coupling, one module can modify the data of another module, or
control flow is passed from one module to the other module. This is the worst form of coupling and
should be avoided.
 Temporal Coupling: Temporal coupling occurs when two modules depend on the timing or order of
events, such as one module needing to execute before another. This type of coupling can result in
design issues and difficulties in testing and maintenance.
 Sequential Coupling: Sequential coupling occurs when the output of one module is used as the input
of another module, creating a chain or sequence of dependencies. This type of coupling can be
difficult to maintain and modify.
 Communicational Coupling: Communicational coupling occurs when two or more modules share a
common communication mechanism, such as a shared message queue or database. This type of
coupling can lead to performance issues and difficulty in debugging.
 Functional Coupling: Functional coupling occurs when two modules depend on each other’s
functionality, such as one module calling a function from another module. This type of coupling can
result in tightly-coupled code that is difficult to modify and maintain.
 Data-Structured Coupling: Data-structured coupling occurs when two or more modules share a
common data structure, such as a database table or data file. This type of coupling can lead to
difficulty in maintaining the integrity of the data structure and can result in performance issues.
 Interaction Coupling: Interaction coupling occurs due to the methods of a class invoking methods of
other classes. Like with functions, the worst form of coupling here is if methods directly access
internal parts of other methods. Coupling is lowest if methods communicate directly through
parameters.
 Component Coupling: Component coupling refers to the interaction between two classes where a
class has variables of the other class. Three clear situations exist as to how this can happen. A class
C can be component coupled with another class C1, if C has an instance variable of type C1, or C
has a method whose parameter is of type C1,or if C has a method which has a local variable of type
C1. It should be clear that whenever there is component coupling, there is likely to be interaction
coupling.

18. Explain about class and object diagram.

 Class diagrams provide a high-level view of a system's structure, focusing on the relationships and
structure of classes, while object diagrams offer a more specific and concrete view by illustrating
instances and their relationships at runtime.

 Class Diagram:
 Purpose: Class diagrams are primarily used for modeling the static structure of a software system.
They depict the classes, their attributes, methods, and the relationships between classes.
 Elements: Class diagrams typically include classes, interfaces, abstract classes, associations,
generalizations (inheritance), dependencies, and multiplicities.
 Use Cases: Class diagrams are useful for designing the overall architecture of a system, defining the
classes and their relationships, and illustrating how different classes collaborate to achieve the
system’s functionality.
 Example: In a class diagram, you might represent classes like “Car,” “Engine,” and “Wheel,”
showing their attributes and methods, as well as relationships like “Car has an Engine” and “Car has
Wheels.”
 Object Diagram:
 Purpose: Object diagrams, on the other hand, focus on capturing a snapshot of the runtime instances
of classes and the relationships between them at a specific moment in time. They represent a set of
objects and their associations.
 Elements: Object diagrams include objects (instances of classes), links (associations between
objects), and multiplicity notations to indicate how many instances are involved.
 Use Cases: Object diagrams are particularly useful for testing, debugging, and documenting specific
scenarios or instances of a system. They show how objects interact at a given point in time.
 Example: In an object diagram, you might depict instances like “myCar” (an instance of the “Car”
class) with its associated instances of “Engine” and “Wheel” at a particular point in the system’s
execution.


 Class diagrams provide a high-level view of a system’s structure, focusing on the relationships and
structure of classes, while object diagrams offer a more specific and concrete view by illustrating
instances and their relationships at runtime. Both diagrams are essential for understanding and
designing software systems, each serving a distinct purpose in the UML modeling process.

19. Explain black box testing and white box testing.

 Black box testing evaluates software functionality from an end-user perspective without knowledge
of the internal code, while white box testing examines the internal structure, logic, and code to
identify defects.
 Black Box Testing:
 Focus: External behavior and functionality, focusing on inputs and outputs.
 Knowledge Required: No knowledge of the internal code or structure is needed.
 Testing Approach: Test cases are designed based on the software's requirements and specifications,
without understanding how the code processes them internally.
 Examples: Functional testing, non-functional testing, regression testing.
 Techniques: Equivalence partitioning, boundary value analysis, decision table testing, state
transition testing.
 White Box Testing:
 Focus: Internal structure, logic, and code of the software.
 Knowledge Required: In-depth knowledge of the internal code structure and how it operates.
 Testing Approach: Testers inspect the code, run it through different paths, and check if all
components (functions, methods, loops) behave correctly.
 Examples: Unit testing, integration testing.
 Techniques: Conditional testing, loop testing, control flow testing, data flow testing, branch testing.



Section C
Answer any 3 Questions

20. Explain emergence of software engineering.

Software engineering emerged in the late 1960s as a distinct discipline to address the growing
complexity and challenges of software development, spurred by the "software crisis" and the need for a
more structured and reliable approach.

Here's a more detailed explanation:

The "Software Crisis":

In the late 1960s, software projects faced increasing challenges, including delays, cost overruns, and
unreliable software. This period, known as the "software crisis," highlighted the need for a more
systematic approach to software development.

The Birth of Software Engineering:

To address these issues, the term "software engineering" and the field emerged, drawing inspiration
from traditional engineering disciplines.

Early Conferences:

The first software engineering conference, sponsored by NATO in 1968, brought together experts to
discuss the problems and potential solutions for software development.

Key Goals:

The goal of software engineering was to establish a disciplined and organized approach to software
development, aiming to improve quality, reduce costs, and enhance reliability.

21. Evolution of Software Engineering:

Over time, software engineering evolved, incorporating various methodologies, tools, and techniques
to address the ever-changing landscape of software development
Emergence as a Profession:
By the early 1980s, software engineering had emerged as a recognized profession, alongside computer
science and traditional engineering.
Key Areas of Focus:
Software engineering encompasses various aspects of software development, including requirements
analysis, design, implementation, testing, and maintenance.
Modern Software Engineering:

Today, software engineering continues to evolve, with new technologies and methodologies emerging
to address the challenges of developing complex and scalable software systems.

22. Explain the concept of formal specification.

Formal specification in software engineering uses mathematical and logical techniques to define
system requirements and behavior precisely, aiming for clarity and unambiguousness, which is crucial
for building reliable and verifiable systems.
Here's a more detailed explanation:

Purpose:

Formal specifications aim to provide a precise and unambiguous description of what a software
system should do, rather than how it should do it.

Method:

They use formal languages (with a defined syntax and semantics) and mathematical models to
represent system requirements and behavior.

Benefits:

Clarity and Precision: Formal specifications eliminate ambiguity and vagueness, making it easier to
understand and verify the system's behavior.
Early Error Detection: Formal methods can help identify potential problems and inconsistencies in the
requirements early in the development process, which is cheaper to fix than later.
Verification and Validation: Formal specifications can be used as a basis for formal verification,
where mathematical proofs are used to demonstrate that the system meets its requirements.
Improved Reliability: By ensuring that the system's behavior is consistent with its formal
specification, formal methods can lead to more reliable and robust software.

23. Examples of Formal Specification Languages:

Z: A formal notation based on set theory and predicate calculus.

VDM (Vienna Development Method): Another formal method for specifying systems.
Lotos: A formal language for specifying communication protocols.

Relationship to Software Development Process:

Formal specifications are often used in the early stages of software development, during requirements
analysis and system design.
They serve as a foundation for building the system, ensuring that the implementation is consistent
with the intended behavior.

Formal Verification:

The process of proving or disproving properties of the software system against a formal specification.
Formal verification techniques can be used to demonstrate that the system meets its requirements,
ensuring its correctness and reliability.

24. Difference between coupling and cohesion.

Coupling and Cohesion are two key concepts in software engineering that are used to measure the
quality of a software system’s design. Both coupling and cohesion are important factors in
determining the maintainability, scalability, and reliability of a software system. High coupling and
low cohesion can make a system difficult to change and test, while low coupling and high cohesion
make a system easier to maintain and improve.
Types of Cohesion
The following are the types of cohesion:
Functional Cohesion
Procedural Cohesion
Temporal Cohesion:
Sequential Cohesion.
Layer Cohesion.
Communication Cohesion.

Coupling refers to the degree of interdependence between software modules. High coupling means
that modules are closely connected and changes in one module may affect other modules. Low
coupling means that modules are independent, and changes in one module have little impact on other
modules.

Types of Coupling
Following are the types of Coupling:
Data Coupling
Stamp Coupling
Control Coupling
External Coupling
Common Coupling
Content Coupling

Differences between Coupling and Cohesion

The differences between cohesion and coupling are given below:
Aspect Cohesion Coupling

Definition Coupling refers to the degree of

Cohesion refers to the degree to
interdependence between software modules.
which elements within a module
High coupling means that modules are closely
work together to fulfill a single,
connected and changes in one module may
well-defined purpose.
affect other modules.

Module Cohesion is the concept of an

Coupling is the concept of inter-module.
Dependency intro-module.

Purpose Cohesion represents the Coupling represents the relationships between

relationship within a module. modules.

Quality Increasing cohesion is good for

Increasing coupling is avoided for software.
software.

Focus Cohesion represents the functional Coupling represents the independence among
strength of modules. modules.

Relationship Highly cohesive gives the best Whereas loosely coupling gives the best
software. software.

Example In cohesion, the module focuses on In coupling, modules are connected to the other
a single thing. modules.
 Aspect Cohesion Coupling

Creation Cohesion is created between the Coupling is created between two different
same module. modules.

Types Types of Cohesion Types of Coupling

Functional Cohesion. Data Coupling
Procedural Cohesion. Stamp Coupling
Temporal Cohesion. Control Coupling
Sequential Cohesion. External Coupling
Layer Cohesion. Common Coupling
Communication Cohesion. Content Coupling
Example of High Cohesion and Low Coupling
Below diagram shows the example of high cohesive and low coupling:

High Cohesive and Low Coupling

25. Explain the use case model with neat diagram.

A Use Case Diagram is a type of Unified Modeling Language (UML) diagram that represents the
interaction between actors (users or external systems) and a system under consideration to accomplish
specific goals. It provides a high-level view of the system's functionality by illustrating the various ways
users can interact with it.
24. Explain different types of testing.