23IT531 – Object Oriented Software Engineering

UNIT I- SOFTWARE PROCESS AND AGILE DEVELOPMENT

Introduction to Software Engineering, Software Process, Perspective and Specialized Process
Models-Introduction to Agility-Agile process-Extreme programming-XP Process-Case
study.

PART-A
1. Write down the generic process framework that is applicable to any software
project / relationship between work product, task, activity and system

• Common process frame work

• Process frame work activities
• Umbrella activities
• Frame work activities
• Task sets

2. What is the difference between verification and validation?

Verification refers to the set of activities that ensure that software correctly implements a
specific function. Verification: "Are we building the product right?"
Validation refers to a different set of activities that ensure that the software that has been
built is traceable to customer requirements. Validation: "Are we building the right product?"
3. What are the two types of software products?
Generic products: these are stand-alone systems that are produced by a development
Organization and sold in the open market to any customer who wants to buy it.
Customized products: these are systems that are commissioned by a specific customer
and developed specially by some contractor to meet a special need.

4. What is software process? List its activities.

Software process is defined as the structured set of activities that are required to develop the
software system.
Activities – Specification, design & implementation, validation & evolution.

5. What are the various categories of software?

• System software
• Application software
• Engineering/Scientific software
• Embedded software
• Web Applications
• Artificial Intelligence software
 6. What are the umbrella activities of a software process? The umbrella activities of a
software process are

• Software project tracking and control.

• Risk management.
• Software Quality Assurance.
• Formal Technical Reviews.
• Software Configuration Management.
• Work product preparation and production.
• Reusability management.
• Measurement
7. What is Agile?
The word ‘agile’ means –

Able to move your body quickly and easily.

Able to think quickly and clearly.
In business, ‘agile’ is used for describing ways of planning and doing work wherein it is
understood that making changes as needed is an important part of the job. Business ‘agility’
means that a company is always in a position to take account of the market changes.

8. What is Agile Manifesto?

The Agile Manifesto states that –
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work, we have come to value –

• Individuals and interactions over processes and tools.

• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.
9. What is meant by Software engineering paradigm
The development strategy that encompasses the process, methods and
tools and generic phases is often referred to as a process model or software engineering
paradigm.

10. Define agility and agile team.

• Agility-Effective (rapid and adaptive) response to change (team members, new

technology, requirements)
• Effective communication in structure and attitudes among all team members,
technological and business people, software engineers and managers.
• Drawing the customer into the team. Eliminate “us and them” attitude. Planning in an
uncertain world has its limits and plan must be flexible.
11. What are the Characteristics of Agility?
Following are the characteristics of Agility –
• Agility in Agile Software Development focuses on the culture of the whole team
with multi-discipline, cross-functional teams that are empowered and self-
organizing.
• It fosters shared responsibility and accountability.

• Facilitates effective communication and continuous collaboration.

• The whole-team approach avoids delays and wait times.

12. What is Extreme Programming?

XP is a lightweight, efficient, low-risk, flexible, predictable, scientific, and
fun way to develop a software.
extreme Programming (XP) was conceived and developed to address the
specific needs of software development by small teams in the face of vague
and changing requirements.
13. Why is it called “Extreme?
Extreme Programming takes the effective principles and practices to extreme levels.
• Code reviews are effective as the code is reviewed all the time.
• Testing is effective as there is continuous regression and testing.
• Design is effective as everybody needs to do refactoring daily.
• Integration testing is important as integrate and test several times a day. • Short
iterations are effective as the planning game for release planning and iteration planning.

14. What is Scrum?

The Scrum approach is a general agile method but its focus is on managing iterative
development rather than specific agile practices. There are three phases in Scrum:
 The initial phase is an outline planning phase where you establish the general
objectives for the project and design the software architecture.
 This is followed by a series of sprint cycles, where each cycle develops an
increment of the system.
15. What is Scaling out.?

• How agile methods can be introduced across a large organization with many years of
software development experience.
• Project managers who do not have experience of agile methods may be reluctant to
accept the risk of a new approach.
• Large organizations often have quality procedures and standards that all projects are
expected to follow and, because of their bureaucratic nature, these are likely to be
incompatible with agile methods.

16. What is Scrum master?

The role of the Scrum Master is to protect the development team from external
distractions. At the end of the sprint the work done is reviewed and presented to
stakeholders (including the product owner).
 PART-B
1. Explain the following:

(i) waterfall model

(ii) Spiral model
(iii) RAD model
(iv) Prototyping model,
A Project management methodology based on asequential design process
Finishes one phase before another phase can begin

• SDLC Model
• Linear Sequential Model
• Simple to understand and easy to implement
(i) waterfall model
There are separate identified phases in the waterfall model:

1. Requirements analysis and definition

2. System and software design
3. Implementation and unittesting
4. Integration and system testing
5. Operation and maintenance
The main drawback of the waterfall model is the difficulty of accommodating change after
the process is underway. In principle, a phase has to be complete before moving onto the
next phase.

(ii) SPIRAL MODEL

The spiral model is divided into number of frame works. These frameworks are denoted
by task regions. Usually there are six task regions.
In spiral model project entry point axis is defined.
The task regions are:
Customer communication ,Planning Risk analysis., Engineering, Construct and release
and Customer evaluation.
Drawbacks

1. It is based on customer communication.

2. It demands considerable risk assessment.
 It provides the potential for rapid development of increasingly more complete versions of the
software.
The spiral model can be adopted to apply throughout the entire lifecycle of the application
from concept development tomaintenance.
Advantages

• In this approach, the project monitoring is easy and more effective compared to other
models.

• It reduces the number of risk in software development before they become serious
problem.

• Suitable for very high risk.

• Schedule and cost is more realistic
(ii) RAD Model
RAD or Rapid Application Development process is an adoption of the waterfall model; it
targets at developing software in a short span of time.
RAD follows the iterative SDLC RAD model has following phases

• Business Modeling
• Data Modeling
• Process Modeling
• Application Generation
IBM first proposed the Rapid Application Development or RAD Model in the 1980s.
The RAD model is a type of incremental process model in which there is a concise
development cycle. The RAD model is used when the requirements are fully understood and
the component-based construction approach is adopted.
iv) Prototyping Model
Prototype methodology is defined as a Software Development model in which a
prototype is built, test, and then reworked when needed until an acceptable prototype is
achieved. It also creates a base to produce the final system.
Software prototyping model works best in scenarios where the project's requirements are not
known. It is an iterative, trial, and error method which take place between the developer and
the client
Often, a customer defines a set of general objectives for software, but does not identify
detailed requirements for functions and features.

• In this case Prototyping is best suited

• Prototyping can be used together with other models for elicitation requirements
• The prototype can serve as “the first system.”

2. Discuss the various life cycle models in software development?

• SDLC is a process followed for a software project, within a software
organization.
• It consists of a detailed plan describing how to develop, maintain, replace and
alter or enhance specific software.
The life cycle defines a methodology for improving the quality of software and the
overall development process.
A typical Software Development Life Cycle consists of the following stages −
PLANNING

Requirement analysis is the most important and fundamental stage in SDLC. It is

performed by the senior members of the team with inputs from the customer, the sales
department, market surveys and domain experts in the industry.

This information is then used to plan the basic project approach and to conduct product
feasibility study in the economical, operational and technical areas.

Planning for the quality assurance requirements and identification of the risks associated
with the project is also done in the planning stage.

DEFINING

Once the requirement analysis is done the next step is to clearly define and document
the product requirements and get them approved from the customer or the market analysts.

This is done through an SRS (Software Requirement Specification) document which

consists of all the product requirements to be designed and developed during the project life
cycle.

DESIGNING

SRS is the reference for product architects to come out with the best architecture for
the product to be developed. Based on the requirements specified in SRS, usually more than
one design approach for the product architecture is proposed and documented in a DDS -
Design Document Specification.

A design approach clearly defines all the architectural modules of the product along
with its communication and data flow representation with the external and third party
modules (if any). The internal design of all the modules of the proposed architecture should
be clearly defined with the minutest of the details in DDS.

BUILDING

In this stage of SDLC the actual development starts and the product is built. The
programming code is generated as per DDS during this stage. If the design is performed in
a detailed and organized manner, code generation can be accomplished without much
hassle.
 Developers must follow the coding guidelines defined by their organization and
programming tools like compilers, interpreters, debuggers, etc. are used to generate the
code. Different high level programming languages such as C, C++, Pascal, Java and PHP
are used for coding.

The programming language is chosen with respect to the type of software being
developed.

TESTING

This stage is usually a subset of all the stages as in the modern SDLC models, the testing
activities are mostly involved in all the stages of SDLC.

However, this stage refers to the testing only stage of the product where product defects
are reported, tracked, fixed and retested, until the product reaches the quality standards
defined in the SRS.

DEPLOYMENT

Once the product is tested and ready to be deployed it is released formally in the
appropriate market. Sometimes product deployment happens in stages as per the business
strategy of that organization.

The product may first be released in a limited segment and tested in the real business
environment (UAT- User acceptance testing).

Then based on the feedback, the product may be released as it is or with suggested
enhancements in the targeting market segment.

2. List the principles of agile software development

• There are 12 agile principles mentioned in the agile.

• Agile principles are guidelines for flexible and efficient software development. They
emphasize frequent delivery, embracing change, collaboration, and continuous
improvement.
• The focus is on delivering value, maintaining a sustainable work pace, and ensuring
technical excellence.
These principles include:

1. Ensuring customer satisfaction through the early delivery of software.

2. Being open to changing requirements in the stages of the development.
3. Frequently delivering working software with a main focus on preference for
timeframes.

4. Promoting collaboration between business stakeholders and developers as an element.

5. Structuring the projects around individuals. Providing them with the necessary
environment and support.

6. Prioritizing face to face communication whenever needed.

7. Considering working software as the measure of the progress.
 8. Fostering development by allowing teams to maintain a pace indefinitely.
9. Placing attention on excellence and good design practices.
[Link] the simplicity as crucial factor aiming to maximize productivity by
minimizing the work.

[Link] self organizing teams as the approach to design and build systems.
[Link] reflecting on how to enhance effectiveness and to make adjustments
accordingly.

3. Write note on business process engineering and product engineering

Business Engineering

• Business process engineering is a way in which organizations study their current

business processes and develop new methods to improve productivity, efficiency, and
operational costs.
• As a business process engineer, you will examine the way an organization operates,
its long-term performance goals, and recommend ways it can work more seamlessly
to achieve overall improvement.
• Many business process engineers work as consultants contracted by companies
seeking improvements to their methodology and infrastructure.
• It refers to the process of designing and developing a device, assembly, or system such
that it is produced as an item for sale through some production manufacturing process.
• Business engineering usually entails activity dealing with issues of cost, reducibility,
quality, performance, reliability, serviceability, intended lifespan and user features.

Product engineering

• These product characteristics are generally all sought in the attempt to make the
resulting product attractive to its intended market and a successful contributor to the
business of the organization that intends to offer the product to that market.
• It includes design, development and transitioning to manufacturing of the product. The
term encompasses developing the concept of the product and the design and
development of its mechanical, electronics and software components.
• After the initial design and development is done, transitioning the product to
manufacture it in volumes is considered part of product engineering.
• Product engineers are the technical interface between the component development
team and the production side (Front End and Back End), especially after the
development phase and qualifications when the high volume production is running.
• Product engineers improve the product quality and secure the product reliability by
balancing the cost of tests and tests coverage that could impact the production fall-off.
They support failure analysis request from customers.

4. Describe in detail about Extreme programming?

XP is a lightweight, efficient, low-risk, flexible, predictable, scientific, and fun way to
develop a software.

eXtreme Programming (XP) was conceived and developed to address the specific needs of
software development by small teams in the face of vague and changing requirements.
 Extreme Programming is one of the Agile software development methodologies. It provides
values and principles to guide the team behavior. The team is expected to self-organize.
Extreme Programming provides specific core practices where −

• Each practice is simple and self-complete.

• Combination of practices produces more complex and emergent behavior.

Embrace Change
A key assumption of Extreme Programming is that the cost of changing a program can
be held mostly constant over time.

This can be achieved with −

• Emphasis on continuous feedback from the customer

• Short iterations
• Design and redesign
• Coding and testing frequently
• Eliminating defects early, thus reducing costs
• Keeping the customer involved throughout the development
• Delivering working product to the customer
Extreme Programming in a Nutshell
Extreme Programming involves −

• Writing unit tests before programming and keeping all of the tests running at all
times. The unit tests are automated and eliminates defects early, thus reducing the
costs.

• Starting with a simple design just enough to code the features at hand and redesigning
when required.

• Programming in pairs (called pair programming), with two programmers at one

screen, taking turns to use the keyboard. While one of them is at the keyboard, the
other constantly reviews and provides inputs.

• Integrating and testing the whole system several times a day.

• Putting a minimal working system into the production quickly and upgrading it
whenever required.

• Keeping the customer involved all the time and obtaining constant feedback.

Iterating facilitates the accommodating changes as the software evolves with the changing
requirements.
 UNIT 2 – REQUIREMENTS ANALYSIS AND SPECIFICATION
Requirement analysis and specification – Requirements gathering and analysis – Software
Requirement Specification – Formal system specification – Finite State Machines – Petrinets
– Object modelling using UML – Use case Model – Class diagrams – Interaction diagrams –
Activity diagrams – State chart diagrams – Functional modelling – Data Flow Diagram-
CASE TOOLS.

[Link] is Software Prototyping?

It is a rapid software development for validating the requirements. It is to help
customers & developers to understand the system requirements.
2. Define functional and non- Functional requirements.

FUNTIONAL REQUIREMENTS NON – FUNTIONAL

REQUIREMENTS
• Functional requirements describe all • Non functional requirements define
the functionality or system services. the system properties and
constraints.
• It should be clear how system should • It is divided in to product,
react to particular inputs and how organizational & external
particular systems behave in requirements.
particular situation.

3. Define non-functional requirements.

Non-functional requirements define the system properties and constraints.
It is divided in to product, organizational & external requirements

4. Distinguish between the term inception, elicitation, & elaboration with reference to
requirements?

• Inception – set of questions are asked to establish basic understanding of problem.

• Elicitation - collaborative requirements gathering & quality function deployment.
• Elaboration – It focuses on developing a refined technical model of software function,
features & constraints.

5. What is data dictionary?

It is organized collection of all the data elements of the system with precise and
rigorous definition so that user & system analyst will have a common understanding
of inputs, outputs, components of stores and intermediate calculations.

6. What is the linkage between Dataflow and ER diagram?

An ER diagram is the Entity Relationship Diagram, showing the relationship between
different entities in a process. A Data Flow diagram is a symbolic structure showing how the
flow of data is used in different process.
7. What is a state transition diagram?
State transition diagram is basically a collection of states and events. The events cause
the system to change its state. It also represents what actions are to be taken based on the
transition.

8. What is DFD?
Data Flow Diagram depicts the information flow and the transforms that are applied on
the data as it moves from input to output.

9. What is data modelling?

Data modelling is the basic step in the analysis modeling. In data modelling the data
objects are examined independently of processing. The data model represents how data are
related with one another.

10. What is requirement engineering?

Requirement engineering is the process of establishing the services that the
customer requires from the system and the constraints under which it operates and is
developed.

11. What is data modelling?

Data modelling is the basic step in the analysis modelling. In data modelling the data
objects are examined independently of processing. The data model represents how data are
related with one another.

12. Differentiate between normal and exciting requirements.

Normal requirements

• The objective and goal are stated for the system through the meetings with the customer.
• For the customer satisfaction these requirements should be there.
Exciting requirements

• These features are beyond the expectation of the customer.

• The developer adds some additional features or unexpected feature into the
software to make the customer more satisfied.

13. How do you design a software project for reuse?

 A clear and well-defined product vision is an essential foundation to an software
project.
 An evolutionary implementation strategy would be a more pragmatic strategy for
the company.
 There exist a need for continuous management support and leadership to ensure
success.
14. Specify at least four questionnaire which supports to select the prototyping approach.

• Prototype serves as a basis for deriving system specification.

• Design quality can be improved.
• System can be maintained easily.
• Development efforts may get reduced.
15. What is meant by structural analysis
The structural analysis is mapping of problem domain to flows and
transformations. The system can be modeled by using Entity Relationship diagram,
Data flow diagram and Control flow diagrams.
PART-B
1. What is Requirement engineering? Explain in detail the various processes in
requirement engineering. Explain Software requirement engineering process with neat
diagram

➢ The process of defining user expectations to build a new software product or

to modify an existing one is known as requirement analysis.
➢ Sometimes known as requirement engineering requirements gathering, or
requirements capture in software engineering.
➢ The tasks that go into determining the needs or conditions to meet for a new
or altered product, taking into account the potentially conflicting requirements
of the various stakeholders, and analyzing, documenting, validating, and
managing software or system requirements are all included in requirements
analysis.
REQUIREMENT ENGINEERING
Requirements engineering (RE) refers to the process of defining, documenting, and
maintaining requirements in the engineering design process.
Requirement Engineering Process
1. Feasibility Study
2. Requirement Elicitation and Analysis
3. Software Requirement Specification
4. Software Requirement Validation
5. Software Requirement Management

Software Requirement Engineering Process

Software Requirement Engineering (SRE) is the process of identifying, analyzing,
documenting, validating, and managing the requirements of a software system.
It is a crucial step in the Software Development Life Cycle (SDLC) and helps ensure that the
final software meets the needs of the users and stakeholders.
Main Activities in SRE:

1. Feasibility Study
2. Requirement Elicitation
3. Requirement Analysis
4. Requirement Specification
5. Requirement Validation
6. Requirement Management

1. Feasibility Study
• Determines if the project is technically, financially, and operationally feasible
• Outcomes: Feasibility report, initial cost estimates, and risk analysis

2. Requirement Elicitation
• Process of collecting requirements from stakeholders
• Techniques: Interviews, questionnaires, brainstorming, observation, document analysis

3. Requirement Analysis
• Examines the collected requirements for:
o Conflicts o Ambiguities
o Redundancy
• Requirements are prioritized and classified (functional/non-functional)

4. Requirement Specification
• Final requirements are documented in the Software Requirements Specification (SRS)
document
• SRS must be clear, complete, consistent, and verifiable

5. Requirement Validation
• Ensures that the requirements meet user needs
 • Activities: Reviews, prototyping, test-case generation
• Validates correctness and consistency

6. Requirement Management
• Ongoing activity throughout the project
• Tracks changes in requirements
• Ensures that changes are analyzed, approved, and documented

2. What is SRS? Explain the various components of an SRS

RS stands for Software Requirements Specification.
It is a formal document that clearly and completely describes the intended functionality,
performance, constraints, and interfaces of a software system. It acts as an agreement between
the client and the developer, ensuring both understand exactly what is to be built.

Objectives of SRS
• To define the scope and requirements of the software
• To act as a reference for designers, testers, and developers
• To reduce miscommunication between stakeholders
• To form the basis for validation and verification

Components of a Good SRS Document

An ideal SRS includes the following main components:

1. Introduction
• Purpose of the document
• Scope of the software
• Definitions, acronyms, and abbreviations
• References
• Overview of the document

2. Overall Description
Gives a general overview of the system:
• Product perspective
(How the system fits into a larger environment)
• Product functions
(High-level description of software capabilities)
• User characteristics
(Skill level, background of end-users)
 • Constraints
(Hardware, OS, development languages)
• Assumptions and dependencies

3. Specific Requirements
This is the core part of SRS.
a. Functional Requirements
• Describe what the system should do
• Example: “The system shall allow users to log in using email and password.”

b. Non-functional Requirements
• Define how the system should behave o Performance (e.g., response time) o Security
(e.g., encryption, access control) o Usability (e.g., user-friendly interface) o Reliability
and availability

c. External Interfaces
• Describes interactions with: o Hardware interfaces o Software interfaces o
Communication interfaces o User interfaces (UI)

d. Design Constraints
• Limitations imposed by: o Regulatory policies o Standards compliance

o Programming languages or DBMS to be used

4. Validation Criteria
• How the requirements will be tested or validated
• Can include test cases or acceptance criteria

5. Appendices
• Supporting information such as:
o Glossary o Diagrams o Sample data
o References to external documents

3. Explain use case modelling with example

Use Case Modeling is a technique used in software engineering to identify, clarify, and
organize system functional requirements. It describes what the system should do from a user's
point of view and how the user interacts with the system.
• It is an important part of UML (Unified Modeling Language)
• Helps in capturing the functional requirements of the system
• Shows actors (users or other systems) and their interactions with use cases (system
functionalities)
 Purpose of Use Case Modeling
• To understand user goals
• To define system boundaries
• To provide input for system design, test cases, and documentation
• To communicate with stakeholders effectively
Basic Components of a Use Case Model
Component Description

Actor A user or external system that interacts with the software

Use Case A specific function or service provided by the system

System A box that defines the scope of the system being modeled
Boundary

Include, Extend, Generalization between use cases and

Relationships actors

Benefits of Use Case Modelling

• Helps gather accurate requirements
• Provides clear communication between users and developers
• Serves as the basis for design and testing
• Easy to understand for non-technical stakeholders

Use Case Diagram for Bank ATM System

Automated Teller Machine (ATM) also known as ABM (Automated Banking Machine)
is a banking system. This banking system allows customers or users to have access to financial
transactions. These transactions can be done in public space without any need for a clerk,
cashier, or bank teller. Working and description of the ATM can be explained with the help of
the Use Case Diagram.
Step-1: The user is authenticated when enters the plastic ATM card in a Bank ATM. Then
enters the user name and PIN (Personal Identification Number). For every ATM transaction,
a Customer Authentication use case is required and essential. So, it is shown as include
relationship. Example of use case diagram for Customer Authentication is shown below:
 Step-2: User checks the bank balance as well as also demands the mini statement about the
bank balance if they want. Then the user withdraws the money as per their need. If they want
to deposit some money, they can do it. After complete action, the user closes the session.
Example of the use case diagram for Bank ATM system is shown below:

Step-3: If there is any error or repair needed in Bank ATM, it is done by an

ATM technician. ATM technician is responsible for the maintenance of the Bank ATM,
upgrades for hardware, firmware or software, and on-site diagnosis.
Example of use case diagram for working of ATM technician is shown below:
 4. list various diagrams in uml and explain the purpose of each diagram
Unified Modeling Language (UML) includes 14 different types of diagrams,
categorized into structure diagrams and behavior diagrams. Each diagram serves a
specific purpose in modeling a software system.
STRUCTURE DIAGRAMS
These diagrams show the static structure of a system—its classes, objects, components, and
their relationships.

1. Class Diagram
o Purpose: Represents the static structure of a system by showing classes, their
attributes, operations, and relationships (inheritance, associations).
o Use: Backbone of object-oriented modeling; useful for database design and
class-level programming.

2. Object Diagram
o Purpose: Shows instances (objects) of classes at a specific time.
o Use: Snapshot of a system’s objects and their links at a moment in time.

3. Component Diagram
o Purpose: Depicts components (software modules) and their dependencies.
o Use: Useful in modeling software architecture and deployment of components.

4. Composite Structure Diagram

o Purpose: Describes the internal structure of a class and the collaborations that
this structure makes possible.
o Use: For detailing the internals of a class or component.

5. Package Diagram
o Purpose: Organizes classes into packages (groups) and shows dependencies
among them.
o Use: High-level organization of large systems.

6. Deployment Diagram
o Purpose: Shows physical deployment of artifacts on nodes (e.g., server, client).
o Use: Useful in modeling hardware configurations and system distribution.

7. Profile Diagram
o Purpose: Defines custom stereotypes, tagged values, and constraints for
extending UML.
o Use: Tailoring UML for specific domains (e.g., embedded systems).
BEHAVIOR DIAGRAMS
These diagrams show how the system behaves and interacts with users and other systems.

8. Use Case Diagram

o Purpose: Describes functional requirements of the system from the user’s
perspective.
o Use: Captures high-level functionalities (use cases) and actors (users or
systems).
9. Activity Diagram o Purpose: Represents workflows of stepwise activities and actions.
o Use: Useful for modeling business processes or the logic of complex operations.

10. State Machine Diagram (State Chart)

• Purpose: Describes the states of an object and transitions between these states.
• Use: Models the lifecycle of an object, especially reactive systems.
11. Sequence Diagram
• Purpose: Shows object interactions in a time sequence.
• Use: Useful for detailing how operations are carried out step-by-step.
12. Communication Diagram (Collaboration Diagram)
• Purpose: Shows interactions between objects based on their relationships.
• Use: Emphasizes structural organization over time ordering.
13. Interaction Overview Diagram
• Purpose: Combines elements of activity and sequence diagrams to show control flow
among interactions.
• Use: High-level view of control flow across multiple interactions.
14. Timing Diagram
• Purpose: Shows change in state or condition of a classifier instance or role over time.
• Use: Useful for real-time and embedded systems.
 UNIT-3 SOFTWARE DESIGN
Software design – Design process – Design concepts – Coupling – Cohesion – Functional
independence – Design patterns – Model-view-controller – Publish-subscribe – Adapter –
Command – Strategy – Observer – Proxy – Facade – Architectural styles – Layered - Client
Server - Tiered - Pipe and filter- User interface design-Case Study.

PART-A
1. Define Software Design. Write different types of software design.
Software Design is the process of envisioning and defining software solutions to
one or more sets of problems. It involves converting the software requirements into a
blueprint for constructing the software system.
TYPES
• Architectural Design (High-Level Design)
• Detailed Design (Low-Level Design)
• Interface Design

2. List the principles of a software design

Software design principles are fundamental guidelines that help create robust,
maintainable, and scalable software. These principles guide developers in making informed
decisions during the design process, leading to better software architecture and code quality.

3. What is the benefit of modular design?

Modular design divides a software system into smaller, independent modules, each
responsible for a specific function.

• Improved Maintainability – Each module can be modified or updated independently

without affecting the entire system.
• Reusability – Modules can be reused across different projects or parts of the system,
saving development time.

4. Identify the characteristics of a good software design technique.

A good software design technique ensures that the software is efficient, reliable, scalable,
and easy to maintain. The key characteristics include:

1. Correctness
2. Understandability
3. Modularity
4. Reusability
5. Flexibility
5. What is a cohesive module? List the different types of
Cohesion?
A cohesive module is one in which all the elements work together to perform a single,
well-defined task. High cohesion means the module is focused and functionally strong, making
it easier to maintain and reuse.
Types of Cohesion:

1. Functional Cohesion
2. Sequential Cohesion.
3. Communicational Cohesion
4. Procedural Cohesion
5. Temporal Cohesion
6. Logical Cohesion
7. Coincidental Cohesion
6. Define Coupling. List the various types of Coupling
Coupling refers to the degree of interdependence between software modules. It
indicates how closely connected two modules are. Low coupling is desirable because it
makes modules easier to modify, test, and reuse.
Types of Coupling:

1. Content Coupling
2. Common Coupling
3. Control Coupling
4. Stamp Coupling
5. Data Coupling
6. No Coupling

7. What is meant by Low Coupling ?

Low Coupling means that software modules are independent or have minimal dependencies
on each other. In a system with low coupling, changes in one module are unlikely to affect
other modules, which enhances modularity and maintainability.

8. What is Meant by High Cohesion?

High Cohesion means that the elements within a module are highly related and work
together to perform a single, specific task. In a highly cohesive module, all functions and
data are focused on a single purpose, making the module well-organized and easy to
understand.

9. List the common activities in Design Process.

• Architectural Design – Defines the overall system structure and identifies major
modules.
• Interface Design – Specifies the interaction between modules and external systems.
• Component (Detailed) Design – Designs the internal logic of each module.
• Data Design – Specifies data structures and database organization.
10. Name the commonly used architectural styles.
• Layered Architecture
• Client-Server Architecture
• Pipe and Filter Architecture
• Event-Driven Architecture
• Microservices Architecture
• Model-View-Controller (MVC)
• Repository Architecture
• Service-Oriented Architecture (SOA)

11. What is an Architectural design?

Architectural design is the process of planning, designing, and constructing buildings
and other physical structures. It involves considering both the functional and aesthetic aspects
to create spaces that meet the needs of users and enhance their experience.

12. Define Patterns.

Patterns are reusable solutions to common problems that occur in software design. They
provide a standard way to solve recurring design issues and promote best practices in software
development.
They help in improving code reusability, maintainability, and clarity.

13. What do you mean by Design Patterns?

Design patterns are general, reusable solutions to common problems in software design.
They are proven templates that guide how to structure classes and objects to solve specific
design issues.
They help improve code reusability, scalability, and maintainability in object- oriented
software development.

14. What is pipe and filter?

• Pipe and Filter is an architectural style where the system is organized as a series of
independent processing components (filters) connected by data channels(pipes).
• Each filter processes input data and passes the output to the next filter through a pipe.
• It is commonly used in data transformation applications like compilers and data stream
processing.
15. Identify the reasons in favour of why functional independence is the key factor for a
good software design.

1. Easier Maintenance – Independent modules can be modified, tested, or replaced

without affecting other parts of the system.

2. Improved Reusability – Modules with a single, well-defined purpose can be reused in

other projects or systems.
Functional independence leads to better modularity, flexibility, and reliability in software
design.
 PART-B
1. Briefly Explain about Design process
Software Design Process is the phase where developers plan how to turn a set of
requirements into a working system.
Like a blueprint for the software. Instead of going straight into writing code, developers
break down complex requirements into smaller, manageable pieces, design the system
architecture, and decide how everything will fit together and work.

1. Interface Design

 Interface Design is the specification of the interaction between a system and its
environment. This phase proceeds at a high level of abstraction with respect to the
inner workings of the system
 i.e, during interface design, the internal of the systems are completely ignored, and
the system is treated as a black box.
 Attention is focused on the dialogue between the target system and the users,
devices, and other systems with which it interacts.
 The design problem statement produced during the problem analysis step should
identify the people, other systems, and devices which are collectively called agents.
Interface design should include the following details:

1. Precise description of events in the environment, or messages from agents to which the
system must respond.

2. Precise description of the events or messages that the system must produce.
3. Specification of the data, and the formats of the data coming into and going out of the
system.

4. Specification of the ordering and timing relationships between incoming events or

messages, and outgoing events or outputs.
2. Architectural Design

 Architectural design is the specification of the major components of a system,

their responsibilities, properties, interfaces, and the
relationships and interactions between them.
 In architectural design, the overall structure of the system is chosen, but the internal
details of major components are ignored. Issues in architectural design includes:

1. Gross decomposition of the systems into major components.

2. Allocation of functional responsibilities to components.
 3. Component Interfaces.
4. Component scaling and performance properties, resource consumption properties,
reliability properties, and so forth.

5. Communication and interaction between components.

The architectural design adds important details ignored during the interface design. Design
of the internals of the major components is ignored until the last phase of the design.
3. Detailed Design
Detailed design is the specification of the internal elements of all major system
components, their properties, relationships, processing, and often their algorithms and the
data structures. The detailed design may include:

1. Decomposition of major system components into program units.

2. Allocation of functional responsibilities to units.
3. User interfaces.
4. Unit states and state changes.
5. Data and control interaction between units.
6. Data packaging and implementation, including issues of scope and visibility of program
elements.

7. Algorithms and data structures.

2. Explain about functional independence.
• Functional independence is a fundamental concept in software design that
ensures each module or component in a software system performs a single, well-
defined function with minimal interaction or dependency on other modules.
• It is a key design principle used to develop high-quality, maintainable, and
reusable software systems.
• Functional independence means that a module or function performs only one
specific task and has minimal interactions (i.e., low coupling) and strong
internal focus (i.e., high cohesion). Such modules are easier to develop, test,
debug, maintain, and reuse.

1. Cohesion:
Cohesion refers to the degree to which the elements within a module belong together. A highly
cohesive module focuses on a single task or function.
• High Cohesion is desirable.
• Example: A module that only handles user input validation.

2. Coupling:
Coupling refers to the degree of interdependence between software modules. Lower coupling
indicates less dependency, which improves modularity.
• Low Coupling is desirable.
• Example: A logging module that does not affect the business logic of the application.
Why Functional Independence is Important:
1. Improves Modularity:
o Independent modules can be developed and understood separately.
2. Enhances Maintainability:
o Errors can be traced and corrected within individual modules without affecting
others.

3. Eases Testing and Debugging:

o Independent modules can be tested in isolation (unit testing).

4. Promotes Reusability:
o Well-designed, independent modules can be reused across different projects or
systems.

5. Facilitates Parallel Development:

o Teams can work on different modules simultaneously without interfering with
each other.

Achieving Functional Independence:

1. Functional Decomposition:
o Break down large tasks into smaller sub-tasks or modules.
2. Design Principles:
o Follow design principles like Single Responsibility Principle (SRP), Separation
of Concerns, and Information Hiding.
3. Use of Interfaces and Abstraction:
o Design modules with clear interfaces and abstract implementation details to
reduce interdependency.
4. Encapsulation:
o Keep internal data and functions hidden within the module.

Metrics to Measure Functional Independence:

1. Cohesion Metrics:
o Measures like LCOM (Lack of Cohesion in Methods) help determine the internal
unity of a module.
2. Coupling Metrics:
 o Metrics like Fan-in and Fan-out show how many modules call or are called by a
module.
3. Explain about User Interface Design
The user interface is the front-end application view to which the user interacts to use the
software. The software becomes more popular if its user interface is:

1. Attractive
2. Simple to use
3. Responsive in a short time
4. Clear to understand
5. Consistent on all interface screens
Types of User Interface

1. Command Line Interface: The Command Line Interface provides a command

prompt, where the user types the command and feeds it to the system. The user needs
to remember the syntax of the command and its use.

2. Graphical User Interface: Graphical User Interface provides a simple interactive

interface to interact with the system. GUI can be a combination of both hardware and
software. Using GUI, the user interprets the software.

1. User, Task, Environmental Analysis, and Modeling

Initially, the focus is based on the profile of users who will interact with the system,
i.e., understanding, skill and knowledge, type of user, etc., based on the user's profile
users are made into categories.:

1. Where will the interface be located physically?

2. Will the user be sitting, standing, or performing other tasks unrelated to the interface?
3. Does the interface hardware accommodate space, light, or noise constraints?
4. Are there special human factors considerations driven by environmental factors?
2. Interface Design
The goal of this phase is to define the set of interface objects and actions i.e., control
mechanisms that enable the user to perform desired tasks.
Indicate how these control mechanisms affect the system.

3. Interface Construction and Implementation

The implementation activity begins with the creation of a prototype (model) that
enables usage scenarios to be evaluated.
As iterative design process continues a User Interface toolkit that allows the creation of
windows, menus, device interaction, error messages, commands, and many other
elements of an interactive environment can be used for completing the construction of
an interface.
 4. Interface Validation
This phase focuses on testing the interface. The interface should be in such a way that
it should be able to perform tasks correctly, and it should be able to handle a variety
of tasks.
It should achieve all the user's requirements. It should be easy to use and easy to
learn. Users should accept the interface as a useful one in their work.
User Interface Design Rules

1. Define the interaction modes in such a way that does not force the user into
unnecessary or undesired actions: .
2. Provide for flexible interaction: Different people will use different interaction
mechanisms, some might use keyboard commands, some might use mouse, some
might use touch screen, etc., Allow user
3. Streamline interaction as skill level advances and allow the interaction to be
customized: Advanced or highly skilled user should be provided a chance to
customize the interface as user wants which allows different interaction
mechanisms so that user doesn't feel bored while using the same interaction
mechanism.
4. Hide technical internals from casual users: The user should not be aware of the
internal technical details of the system. He should interact with the interface just to
do his work.
5. Design for direct interaction with objects that appear on-screen: The user should be
able to use the objects and manipulate the objects that are present on the screen to
perform a necessary task. By this, the user feels easy to control over the screen.

5. Describe about Model-View Controller

• MVC(Model-View-Controller) Architecture is a fundamental design pattern in
software development, separating an application into Model, View, and Controller
components.
• This article explores its role in building robust, maintainable systems, emphasizing its
benefits and implementation strategies.
• MVC (Model-View-Controller) architecture is a universal pattern of a structure in
which an application is divided into three parts which are all dedicated to certain parts
of the whole application.
• This pattern is normally used in software development to create organized and easy-to-
maintain code. Here’s a deeper look at each component
 • Model: It is worth stating that the Model stands as the data layer for the application. It
is directly involved in managing the data as well as the control of the application’s logic
and rules.

• View: The View is in the presentation tier. It plays a role of presenting the information
given by the Model to the user and transferring the user commands to the Controller.
The View is used to display the data to the user in a readable and manageable way using
the interface created by the Controller.

• Controller: The Controller CE works in the middle between the Model and the View.
It takes the input from the View, sometimes modifies it
with the help of the Model, and sends it back to the View. the results back to the View.
The MVC architecture is significant in system design for the following reasons:

• Separation of Concerns: MVC structures an application into three integrated elements

and that really separates concern. Due to the clear division of responsibilities among
each of the components, the functioning of the application becomes more logical and
comprehensible.

• Reusability: Due to the fact that Model, View, and Controller are all the distinct
entities, components can be utilized in the various sections of the application or
different projects. For example, a Model class that contains user data can be used many
times in the views and the controllers.

• Scalability: MVC amplifies the creation of applications that can be developed further.
When the application advances, new functionalities of the application can be added
without significant alterations to some parts of the application because they are elusive.

• Testability: This separation of concerns make it easier for the testing of each part from
the other as we as from other problems. One of the testing strategies is to have separate
tests for Model, View, and Controller parts, in this way, one is sure that each part is
functioning properly before combining them.

Benefits of MVC

• Enhanced Organization: MVC is useful in splitting the application into different parts
thus improving on the way the codebase is structured.

• Parallel Development: It means that two or more developers can work on Model, View,
and Controller form at the same time without attempting or interfering with the work
of the other.

• Code Reusability: Compared with other designs, elements of MVC can be reused from
part of the application to another.

• Improved Maintainability: It bellows from the fact that this methodology of separation
of concerns makes it easier to maintain and update the application.

• Testability: Compared with other architectures, MVC architecture is relatively easy to

test because each component of the architecture can be tested separately. Writing unit
tests can be done for the Model, View and
Controller, thus assuring that each component is correct before the others.
 Unit IV SOFTWARE TESTING AND MAINTENANCE
Testing – Unit testing – Black box testing– White box testing – Integration and System
testing– Regression testing – Debugging - Program analysis – Symbolic execution –
Model Checking-Case Study
PART-A

1. Define Software Testing

Software testing is a comprehensive process of evaluating a software application or
system to ensure it functions as expected and meets all defined requirements. It involves
identifying and fixing defects or bugs to deliver high- performing, reliable software that
meets user needs.

2. What are the objectives of testing?

The primary objectives of testing, particularly in the context of software development,
are to identify and prevent defects, ensure quality, and validate that the software meets user
and business requirements. Testing also aims to build confidence in the software's reliability
and functionality.

3. What are the testing principles the software engineer must apply while
performing the software testing?
software engineer must apply the following key testing principles while performing software
testing:

1. Testing shows the presence of defects – Testing can show that defects are present,
but cannot prove that there are no defects.
2. Early testing – Testing should begin as early as possible in the software development
lifecycle to detect defects early and reduce cost.
These principles help ensure effective and efficient software testing.

4. List the levels of object oriented testing.

• Unit Testing – Tests individual classes and methods in isolation.
• Integration Testing – Tests interactions between objects and classes.
• System Testing – Tests the complete object-oriented system as a whole.
• Acceptance Testing – Validates the system against user requirements.

5. What are the two levels of testing?

• Static Testing – Involves reviewing and analyzing the code or documents without
executing the program (e.g., code reviews, inspections).

• Dynamic Testing – Involves executing the code to validate the software’s behavior
and functionality (e.g., unit testing, system testing)

6. What are the reasons behind to perform white box testing?

• To verify internal logic and structure – Ensures that all internal operations, paths,
and conditions of the code work as intended.
• To achieve maximum code coverage – Helps identify untested paths, unreachable
code, and logical errors in the program.
7. Write short note on Black box testing.
• Black box testing is a software testing method where the tester evaluates the
functionality of the software without knowing its internal code or structure.
• It focuses on input-output behavior to verify if the system meets specified
requirements. Common techniques include equivalence partitioning, boundary
value analysis, and decision table testing.
8. Define integration testing.
Integration testing is the process of testing the interfaces and interaction between
integrated modules or components of a software system. It ensures that combined parts work
together as expected and data flows correctly between them.

9. What are the various testing strategies for conventional software

1. Unit Testing – Tests individual modules or components.
2. Integration Testing – Tests the interaction between integrated units.
3. Validation Testing – Ensures the software meets user requirements.
4. System Testing – Verifies the complete and integrated software system in its
environment.

10. Write about drivers and stubs.

• Drivers are dummy programs used to call and test lower-level modules during bottom-
up integration testing.
• Stubs are dummy modules that simulate the behavior of missing components during
top-down integration testing.
They help in testing incomplete systems by simulating missing parts.

11. Distinguish between verification and validation.

• Verification checks whether the software is built correctly (i.e., conforms to design
specifications).
• Validation checks whether the right software is built (i.e., meets user needs and
requirements).
Verification = Are we building the product right?
Validation = Are we building the right product?

12. What are the conditions exists after performing validation testing
• Validation Success – The software meets all user requirements and is ready for
delivery or deployment.
• Validation Failure – The software does not meet the specified requirements, and
necessary modifications or corrections must be made.
13. Distinguish between alpha testing and beta testing.
• Alpha testing is an early-stage testing process conducted by internal teams
(developers, testers, etc.) to identify bugs and ensure core functionality before
releasing the product to external users.
• Beta testing, on the other hand, involves releasing the software to a wider audience of
real users (beta testers) to gather feedback on usability, performance, and identify any
remaining issues in a real-world environment.
 14. What are the various types of system testing
• System testing encompasses a variety of testing types, broadly categorized into
functional and non-functional testing, with further specialized areas.
• Functional testing ensures the system meets requirements, while non- functional
testing evaluates aspects like performance, security, and usability. Specific types
include load, stress, regression, recovery, compatibility, and usability testing.
15. Define debugging. What are the common approaches in debugging
Debugging is the process of identifying, analyzing, and correcting errors or bugs in a software
program.
Common Approaches in Debugging:

1. Brute Force Method – Using print statements or debuggers to trace and locate errors.
2. Backtracking – Tracing the code backward from the point of failure to find the cause
of the bug.

PART-B

1. Explain about Unit Testing.

TESTING
• Testing in software testing and maintenance refers to the process of evaluating
a software application or system to identify defects, errors, or bugs.
• It is a crucial phase in the software development lifecycle (SDLC) and plays a
significant role in ensuring the quality and reliability of the software product

UNIT TESTING

• Unit testing is a software testing technique where individual units or

components of a software application are tested independently to ensure that
they perform as expected.

• A unit is the smallest testable part of any software, typically a function,

method, or procedure.

• The purpose of unit testing is to validate that each unit of the software behaves
as designed and to identify any defects or errors early in the development
process.
 Here's a detailed explanation of unit testing:

1. Scope:
• Unit testing focuses on testing individual units or components in isolation from the
rest of the software.
• This means that each unit is tested independently, regardless of its dependencies on
other units or external systems.
• Unit testing ensures that each unit functions correctly and produces the expected
output when given specific inputs.

1. Testing Environment
• Unit tests are usually performed in a controlled environment, such as an integrated
development environment (IDE) or a unit testing framework.
• Developers write test cases that include specific inputs, expected outputs, and
assertions to verify the behavior of each unit.
• These tests can be automated and executed repeatedly to ensure consistent results.

2. Isolation
• Unit testing requires isolating the unit being tested from its dependencies.
• This is typically achieved using techniques such as mocking or stubbing, where fake
implementations of dependencies are provided to simulate their behavior.
• By isolating units, developers can identify defects within the unit itself without being
affected by issues in other parts of the software.

3. Test Cases
• Test cases for unit testing are designed to cover various scenarios and edge cases that
the unit may encounter during execution.
• These test cases are based on the unit's specifications, requirements, and expected
behavior.
 • Test cases should be comprehensive enough to validate all possible paths through the
unit's code, including both normal and exceptional conditions.

4. Test Frameworks
• Unit testing is facilitated by various testing frameworks and tools available for
different programming languages and platforms.
• These frameworks provide functionalities for defining and running tests, as well as
reporting test results. Examples of popular unit testing frameworks include JUnit for
Java, NUnit for .NET, PHPUnit for PHP, and for Python.

Benefits

• Early Detection of Defects:

Unit testing allows developers to identify and fix defects early in the development
process, reducing the cost and effort required for debugging and maintenance later
on.

• Improved Code Quality

Writing unit tests encourages developers to write modular, well− structured, and
maintainable code, leading to higher overall code quality.

• Regression Testing
Unit tests serve as a safety net against regressions by ensuring that changes to the
codebase do not introduce new defects or break existing functionality.

• Documentation
Unit tests also serve as executable documentation, providing insights into the intended
behavior and usage of each unit within the software.
2. Describe about Black Box Testing

• Black box testing is a software testing technique where the internal workings or
structure of the software being tested are not known to the tester.

• Instead, the tester focuses on examining the software's functionality based solely on
its inputs and outputs, without considering its internal implementation.

• The term "black box" refers to the idea that the software is treated as an opaque entity,
similar to a sealed black box, where only the externally visible behavior is considered.
Here's a detailed explanation of black box testing:
Objective
• The primary objective of black box testing is to validate the correctness and
functionality of the software from the perspective of the end−user.
• Testers do not have access to the source code or internal design details of the software;
instead, they interact with the software through its user interface or API.

Testing Scenarios
• Black box testing encompasses various testing scenarios, including functional testing,
non−functional testing, and regression testing.
• Functional testing involves verifying that the software functions according to its
specifications and requirements, while non−functional testing evaluates aspects such
as performance, usability, reliability, and security.
• Regression testing ensures that recent changes or updates to the software do not
adversely affect existing functionality.
Test Design
• Test cases for black box testing are designed based on the software's requirements,
specifications, and user documentation.
• Testers identify different inputs, actions, and conditions that the software should
handle and design test cases to validate these aspects.
• Test cases are created to cover both typical and boundary scenarios, as well as
error−handling and exception scenarios.
Techniques
• Various black box testing techniques are employed to maximize test coverage and
effectiveness.
• These include equivalence partitioning, boundary value analysis, decision table
testing, state transition testing, and use case testing.
• Each technique focuses on different aspects of the software's behavior and helps
identify potential defects or issues

Independence
• Black box testing promotes independence between testers and developers. Testers do
not need to have knowledge of the internal implementation details or programming
languages used in the software.
• This independence allows for unbiased testing and helps uncover defects that might
be overlooked by developers.

Advantages
• Encourages a user−centric approach to testing, ensuring that the software meets user
requirements and expectations.

• Facilitates early defect detection by focusing on the software's external behavior and
functionality.

• Allows for parallel testing efforts, where multiple testers can work simultaneously on
different aspects of the software.

• Promotes reusability of test cases across different versions or variations of the

software.
 Disadvantages

• Limited coverage of internal logic or code paths, which may result in certain defects
remaining undetected.

• Relies heavily on the quality and accuracy of requirements and specifications provided
to testers.

• May overlook certain implementation−specific defects or performance issues that

require knowledge of internal workings.

3. Describe in detail about Program Analysis.

• Program analysis is a broad term in computer science that refers to the process of
automatically analyzing software programs to gain insights into their behavior,
properties, and quality.

• Program analysis techniques aim to extract useful information about programs, such
as their correctness, performance, security vulnerabilities, and other characteristics.

• Program analysis can be performed statically, by examining the source code or binary
without executing it, or dynamically, by observing program behavior during
execution. Here's an explanation of key aspects of program analysis:
Static Analysis

• Static Analysis Techniques:

Static analysis techniques analyze software artifacts, such as source code, bytecode,
or binary executables, without executing them. Techniques include data flow
analysis, control flow analysis, abstract interpretation, and symbolic execution.

• Code Quality Static

analysis tools can assess code quality metrics, identify coding standards violations,
and detect potential bugs or defects in the code.

• Code Optimization
Static analysis can help identify opportunities for code optimization, such as dead code
elimination, loop unrolling, and inlining of functions.

Dynamic Analysis
• Runtime Behavior
Dynamic analysis observes the behavior of a program during execution. Techniques
include profiling, memory analysis, code coverage analysis, and runtime monitoring.

• Performance Profiling
Dynamic analysis tools can measure program execution time, memory usage, and
other performance metrics to identify bottlenecks and optimize resource utilization.

• Fault Localization
Dynamic analysis can help pinpoint the root cause of runtime errors, crashes, or
exceptions by tracing program execution and analyzing runtime states.
Security Analysis
• Vulnerability Detection
 Program analysis techniques can detect security vulnerabilities in software, such as
buffer overflows, injection attacks, race conditions, and privilege escalation.

• Malware Detection
Program analysis tools can analyze software binaries to identify characteristics of
malware, such as suspicious code patterns, behavior, and signatures.

Verification and Validation

• Formal Verification
Program analysis techniques, such as model checking and theorem proving, can
formally verify software correctness with respect to specified properties or
requirements.

• Testing Support
Program analysis tools can assist in test case generation, test coverage analysis, and
test result interpretation to support software testing efforts.

Program Understanding and Maintenance

• Code Understanding
Program analysis techniques provide insights into program structure, dependencies,
and relationships to aid in program comprehension and maintenance tasks.

• Refactoring Support
Program analysis tools can identify opportunities for code refactoring, such as code
duplication, unused variables, and unreachable code.

Automated Program Repair

• Automated Bug Fixing
Program analysis techniques can automatically generate patches or fixes for identified
bugs or defects in software code.

• Code Synthesis
Program analysis tools can synthesize code snippets or templates to automate
repetitive programming tasks or generate code that satisfies specified requirements.
Challenges and Limitations
• Scalability
Program analysis techniques may face scalability challenges when
analyzing large− scale or complex software systems due to the
exponential growth of analysis paths.

• Precision and Soundness

Balancing precision and soundness in program analysis is a challenge, as overly
conservative analyses may miss real defects, while overly aggressive analyses may
report false positives.
4. Build the process of Model Checking.

• Model checking is a formal verification technique used to systematically check

whether a model of a system satisfies a given specification or property. It involves
exhaustively exploring all possible states and transitions of the model to verify
whether certain properties, such as safety or liveness, hold under all possible
conditions.
• Model checking is commonly used in the verification of hardware and software
systems, protocol validation, and formal analysis of concurrent and distributed
systems.

1. Modeling the System:

• System Representation
The first step in model checking is to create a formal model of the system being
analyzed. The system is typically represented as a mathematical or computational
model, such as a finite−state machine, transition system, Petri net, or temporal logic
formula.

• State Space Representation

The model captures the system's states, transitions, and behavior. The state space
represents all possible states of the system, and transitions define how the system
moves from one state to another based on its actions or inputs.

2. Specifying Properties
• Property Formulation
Model checking requires specifying formal properties or requirements that the
system should satisfy. Properties can be expressed using temporal logic formulas,
such as Linear Temporal Logic (LTL) or Computation Tree Logic (CTL), to specify
safety, liveness, fairness, or other properties.

• Safety vs. Liveness

Safety properties specify that certain undesirable states or behaviors are not
reachable in the system, while liveness properties ensure that desirable states or
behaviors will eventually occur.

3. Verification Process

• State Space Exploration

Model checking systematically explores all possible states and transitions of the
system's model to verify whether the specified properties hold. This exploration is
typically performed using algorithms that traverse the state space in a systematic
and efficient manner.

• Property Verification
At each state visited during the exploration, model checking checks whether the
properties specified in the specification hold. If a violation is detected, the model
checker provides a counterexample demonstrating how the property is violated.

• Completeness and Soundness

 Model checking algorithms are designed to be complete and sound, meaning that
they explore all reachable states of the system and produce correct results
regarding property satisfaction.

4. Tools and Techniques

• Model Checking Algorithms
Various model checking algorithms, such as breadth−first search, depth−first search,
symbolic model checking, and bounded model checking, are used to explore the state
space efficiently and verify properties.

• Model Checking Tools

There are numerous model checking tools and frameworks available, such as
NuSMV, SPIN, PRISM, and Alloy, that provide support for specifying models,
properties, and performing verification.
Advantages of build process modeling

• Automated and systematic verification technique.

• Guarantees completeness and correctness of results.
• Can verify complex systems with large state spaces.
 UNIT-V PROJECT MANAGEMENT
Software Project Management- Software Configuration Management - Project Scheduling-
DevOps: Motivation-Cloud as a platform-Operations- Deployment Pipeline: Overall
Architecture Building and Testing-Deployment- Tools- Case Study
PART-A
1. What is Software Project Management?
Software project management (SPM) is the process of planning, organizing, and
overseeing the development and delivery of software projects. It involves coordinating
resources, tasks, and timelines to ensure a project meets its goals within the constraints of scope,
time, cost, and quality.

2. List the three activity of Software Project Management

Project Planning – Defining project scope, objectives, resources, schedules, and budget.
Project Monitoring and Control – Tracking progress, managing risks, and ensuring the
project stays on schedule and within budget.
Project Termination (Closure) – Finalizing all activities, delivering the product, and
evaluating project outcomes.

3. What is Software Configuration Management?

Software Configuration Management is a process of systematically managing
changes to software to maintain integrity and traceability throughout the software
development lifecycle.
It involves version control, change control, and configuration audits to ensure that the
software system is consistent and functions correctly as changes are made.

4. Why do we need Configuration Management?

Configuration Management is needed to:

• Track and control changes in software to avoid confusion and ensure consistency.
• Maintain integrity and traceability of the software system throughout its lifecycle,
especially in large or evolving projects.

5. Write short note on the various estimation techniques.

Software estimation techniques help predict effort, time, and cost. Common techniques
include:

• Expert Judgment – Based on experience of experts.

• Delphi Technique – Group consensus through multiple expert rounds.
• COCOMO Model – Uses mathematical formulas based on project size.
• Function Point Analysis – Estimates based on system functionality.
• Use Case Point Method – Based on use cases and system complexity
Write about the types of project plan.
• Development Plan – Outlines the overall approach, schedule, and resources for
developing the software.

• Quality Assurance Plan – Describes procedures and standards to ensure software

quality.
 • Configuration Management Plan – Details how changes to the software will be
managed.

• Risk Management Plan – Identifies potential risks and defines strategies to manage
them.

6. What are the advantages and disadvantages of size measure?

Advantages:

• Easy to understand and compute (e.g., Lines of Code – LOC).

• Useful for estimating effort, cost, and time.
Disadvantages:

• Language-dependent and not suitable for early stages.

• Does not reflect software complexity or functionality accurately.
7. What is COCOMO model?
COCOMO (Constructive Cost Model) is a software estimation model developed by Barry
Boehm. It uses mathematical formulas based on the size of the software (usually in KLOC –
thousands of lines of code) to estimate the cost, effort, and time required for development.

8. Give the purpose of timeline chart

A Timeline Chart (also known as a Gantt Chart) is used to:

• Visually represent the project schedule, showing start and end dates of tasks.
• Track progress and ensure that activities are completed on time.

10. What is EVA?

Earned Value Analysis (EVA) is a project management technique used to measure project
performance and progress objectively.
It compares the planned work with the actual work completed to assess:

• Cost performance, and

• Schedule performance.

11. What is the primary objective of DevOps?

The primary objective of DevOps is to integrate development and operations
teams to enable faster, more reliable, and continuous delivery of software.
It aims to improve collaboration, automation, and efficiency across the software
development lifecycle, from coding to deployment and maintenance.

12. How is Devops different from agile methodology?

• Agile focuses on iterative development, emphasizing collaboration and customer
feedback during the software development process.
• DevOps extends Agile by focusing on automation, integration, and continuous delivery,
bridging the gap between development and operations.
13. What are the core operations of DevOps with application development and
infrastructure.

1. Continuous Integration and Continuous Deployment (CI/CD) – Automates building,

testing, and releasing code changes.

2. Infrastructure as Code (IaC) – Manages infrastructure using code for consistency and
scalability.
These operations ensure faster, reliable, and scalable application development and deployment.

14. What is the role of AWS in DevOps

AWS (Amazon Web Services) provides cloud-based tools and services that support
automation, scalability, and continuous delivery in DevOps.

• CI/CD services (e.g., AWS CodePipeline, CodeBuild).

• Infrastructure management using Infrastructure as Code (e.g., AWS CloudFormation).
15. List down the components of a DevOps pipeline.
• Source Code Management – Handles version control (e.g., Git).
• Build – Compiles code and generates executable files.
• Test – Runs automated tests to ensure code quality.
• Release – Prepares code for deployment.
• Deploy – Automatically deploys to production or staging.
• Monitor – Tracks application performance and issues.

PART-B
1. Explain in detail about Software Project Management

o Software Project Management (SPM) is a proper way of planning

and leading software projects.

o It is a part of project management in which software projects are

planned, implemented, monitored, and controlled.

o there are three needs for software project management. These are:
[Link]
[Link]
[Link]

Need for Software Project Management

• Software is a non-physical product. Software development is a new stream in business

and there is very little experience in building software products.

• it is essential to manage software projects efficiently. It is necessary for an organization

to deliver quality products, keep the cost within the client’s budget constraint, and
deliver the project as per schedule.
Types of Management in SPM

1. Conflict Management

• Conflict management is the process to restrict the negative features of conflict while
increasing the positive features of conflict.

• The goal of conflict management is to improve learning and group results including
efficacy or performance in an organizational setting. Properly managed conflict can
enhance group results

2. Risk Management

Risk management is the analysis and identification of risks that is followed by

synchronized and economical implementation of resources to minimize, operate and
control the possibility or effect of unfortunate events or to maximize the realization of
opportunities
3. Requirement Management
It is the process of analyzing, prioritizing, tracking, and documenting
requirements and then supervising change and communicating to
pertinent stakeholders. It is a continuous process during a project.
4. Change Management
Change management is a systematic approach to dealing with the
transition or transformation of an organization’s goals, processes, or
technologies. The purpose of change management is to execute
strategies for effecting change, controlling change, and helping
people to adapt to change.

5. Software Configuration Management

Software configuration management is the process of controlling and
tracking changes in the software, part of. Software configuration
management includes revision control and the inauguration of
baselines.

6. Release Management
Release Management is the task of planning, controlling, and
scheduling the built-in deploying releases. Release management
ensures that the organization delivers new and enhanced services
required by the customer while protecting the integrity of existing
services. Aspects of Software Project Management

2. Describe in detail about COCOMO model for software cost estimation

COCOMO Model is a procedural cost estimate model for SOFTWARE PROJECT and
is often used as a process of reliably predicting the various parameters associated with
making a project such as size, effort, cost, time, and quality.
Types of Projects in COCOMO Model
In the COCOMO model, software projects are categorized into three types based on
their complexity, size, and the development environment.
These types are:

1. Organic
A software project is said to be an organic type if the team size required is adequately
small, the problem is well understood and has been solved in the past and also the team
members have a nominal experience regarding the problem.

2. Semi-detached
A software project is said to be a Semi-detached type if the vital characteristics such as
team size, experience, and knowledge of the various programming environments lie in
between organic and embedded.
The projects classified as Semi-Detached are comparatively less familiar and difficult to
develop compared to the organic ones and require more experience better guidance and
creativity. Eg: Compilers or different Embedded Systems can be considered Semi-
Detached types.

3. Embedded
A software project requiring the highest level of complexity, creativity, and experience
requirement falls under this category. Such software requires a larger team size than the
other two models and also the developers need to be sufficiently experienced and creative
to develop such complex models.

Structure of COCOMO Model

 1. Planning and requirements: This initial phase involves defining the scope, objectives,
and constraints of the project. It includes developing a project plan that outlines the
schedule, resources, and milestones

2. System design: : In this phase, the high-level architecture of the software system is
created. This includes defining the system’s overall structure, including major
components, their interactions, and the data flow between them.

3. Detailed design: This phase involves creating detailed specifications for each
component of the system. It breaks down the system design into detailed descriptions
of each module, including data structures, algorithms, and interfaces.

4. Module code and test: This involves writing the actual source code for each module
or component as defined in the detailed design. It includes coding the functionalities,
implementing algorithms, and developing interfaces.

5. Integration and test: This phase involves combining individual modules into a
complete system and ensuring that they work together as intended.

6. Cost Constructive model: The Constructive Cost Model (COCOMO) is a widely used
method for estimating the cost and effort required for software development projects.
Types of cocomo model

1. Basic COCOMO Model

The Basic COCOMO model is a straightforward way to estimate the effort needed for a
software development project. It uses a simple mathematical formula to predict how many
person-months of work are required based on the size of the project, measured in thousands
of lines of code (KLOC).

2. Intermediate COCOMO Model

The basic COCOMO model assumes that the effort is only a function of the number of lines
of code and some constants evaluated according to the different software systems.
However, in reality, no system's effort and schedule can be solely calculated based on Lines
of Code. For that, various other factors such as reliability, experience, and Capability.
These factors are known as Cost Drivers (multipliers) and the Intermediate Model utilizes
15 such drivers for cost estimation

3. Detailed COCOMO Model

Detailed COCOMO goes beyond Basic and Intermediate COCOMO by diving deeper into
project-specific factors. It considers a wider range of parameters, like team experience,
development practices, and software complexity.
By analyzing these factors in more detail, Detailed COCOMO provides a highly accurate
estimation of effort, time, and cost for software projects. It's like zooming in on a project's
unique characteristics to get a clearer picture of what it will take to complete it successfully.

3. Describe about Project Scheduling

• A schedule in your project's time table actually consists of sequenced activities and
milestones that are needed to be delivered under a given period of time.
• Project schedule simply means a mechanism that is used to communicate and know
about that tasks are needed and has to be done or performed and which
organizational resources will be given or allocated to these tasks and in what time
duration or time frame work is needed to be performed.
 • Effective project scheduling leads to success of project, reduced cost, and increased
customer satisfaction. Scheduling in project management means to list out
activities, deliverables, and milestones within a project that are delivered.
• It contains more notes than your average weekly planner notes. The most common
and important form of project schedule is Gantt chart.

Process:
o The manager needs to estimate time and resources of project while scheduling
project.
o All activities in project must be arranged in a coherent sequence that means
activities should be arranged in a logical and well- organized manner for easy
to understand.
o Initial estimates of project can be made optimistically which means estimates
can be made when all favorable things will happen and no threats or problems
take place.
o The total work is separated or divided into various small activities or tasks
during project schedule. Then, Project manager will decide time required for
each activity or task to get completed.
o Even some activities are conducted and performed in parallel for efficient
performance. The project manager should be aware of fact that each stage of
project is not problem-free.
Problems arise during Project Development Stage :
• People may leave or remain absent during particular stage of development.
• Hardware may get failed while performing.
• Software resource that is required may not be available at present, etc.

4. Describe about DevOps Motivation and cloud as a platform

DevOps is a software development methodology that emphasizes collaboration
between development and operations teams, with a goal to automate and integrate
the processes of software development, testing, deployment, and infrastructure
management.
The traditional software development models like Waterfall or even Agile often faced
challenges such as:
• Slow release cycles
• Lack of coordination between Dev and Ops teams
• Manual errors during deployment
• Poor feedback loops
• Difficulty in scaling applications
These limitations motivated the adoption of DevOps with the aim to:
• Faster Time to Market:
DevOps enables continuous integration and continuous delivery (CI/CD), which
drastically reduces the time required to deliver new features or fixes.
• Improved Collaboration:
Breaks silos between development, testing, and operations teams. All teams work
toward a common goal with shared responsibilities.
• Increased Deployment Frequency:
Automation tools allow teams to deploy code multiple times a day, improving
flexibility and responsiveness.
• Enhanced Quality and Reliability:
Automated testing and monitoring ensure that issues are detected and resolved early,
improving software quality.
• Better Resource Utilization:
Using Infrastructure as Code (IaC), teams can provision and manage infrastructure
efficiently, reducing manual intervention.
• Faster Recovery:
In case of failures, rollbacks and fixes can be performed quickly using versioned
deployments and monitoring tools.

Cloud as a Platform in DevOps

1. Role of Cloud Computing in DevOps:

Cloud platforms provide the foundation and tools necessary for implementing DevOps
practices. It offers a flexible, scalable, and on- demand environment suitable for
automation, development, and deployment.

2. Benefits of Using Cloud in DevOps:

• On-demand Infrastructure:
Teams can provision environments instantly, without waiting for physical hardware
setup.
• Scalability:
Cloud platforms like AWS, Azure, and Google Cloud can automatically scale resources
based on demand.
• Cost Efficiency:
Pay-as-you-use model avoids over-provisioning of hardware and reduces infrastructure
costs.
• Global Accessibility:
Teams across different locations can collaborate on the same cloud platform.
• Integrated DevOps Tools:
Most cloud platforms offer built-in DevOps tools:
o AWS CodePipeline, CodeBuild, CloudFormation o Azure DevOps,
Azure Pipelines
o Google Cloud Build, Cloud Deployment Manager
 3. Cloud Services Supporting DevOps:
• Compute Services:
(e.g., AWS EC2, Azure VMs) for hosting applications.
• Storage Services:
(e.g., AWS S3, Azure Blob Storage) for storing build artifacts and logs.
• Networking Services:
For connecting various components of the pipeline securely.
• Monitoring & Logging:
Tools like AWS CloudWatch or Azure Monitor provide real-time insights.
• Security and Compliance:
Role-based access control, encryption, and audit logs help meet enterprise security
standards.
5. Explain in detail about Deployment Tools in DevOps.
In DevOps, deployment tools play a critical role in automating the process of
delivering software applications to various environments— such as development,
testing, staging, and production. These tools help ensure faster, more reliable, and
error-free deployments.

Need for Deployment Tools in DevOps

Traditional software deployment is often manual, time-consuming, and error-prone.
DevOps practices aim to automate these processes to:
• Enable Continuous Deployment (CD)
• Reduce human error
• Ensure repeatability and consistency
• Allow rollbacks in case of failures
• Improve collaboration and visibility

Features of Deployment Tools

1. Automation of build and deployment processes

2. Rollback support in case of deployment failures
3. Environment configuration management
4. Version tracking and artifact storage
5. Integration with CI/CD pipelines

Popular Deployment Tools in DevOps

1. Jenkins
• Open-source CI/CD automation server.
• Can be used for automated deployment via plugins like "Deploy to container".
• Supports pipelines as code using Groovy scripts.
• Integrates well with tools like Git, Maven, Docker, and Kubernetes.
2. GitLab CI/CD
• Built into GitLab platform.
• Automates building, testing, and deploying applications.
• Uses YAML files (.[Link]) to define deployment pipelines.
• Supports Kubernetes, Docker, and multiple cloud platforms.
 3. AWS Code Deploy
• A fully managed deployment service from AWS.
• Automates application deployment to AWS EC2, Lambda, or on-premise servers.
• Supports blue/green and in-place deployments.
• Integrates with AWS CodePipeline and CodeBuild.
4. Ansible
• Open-source automation tool by Red Hat.
• Used for configuration management and application deployment.
• Uses YAML playbooks for defining deployment steps.
• Agentless architecture, relies on SSH.
5. Docker
• Containerization platform that packages applications and dependencies.
• Used to deploy applications as lightweight, portable containers.
• Helps achieve consistency across different environments.
6. Kubernetes
• Open-source container orchestration tool.
• Automates deployment, scaling, and management of containerized applications.
• Supports self-healing, load balancing, and rolling updates.
• Works well with CI/CD pipelines for automated deployments.
7. Octopus Deploy
• A deployment automation tool that focuses on .NET applications.
• Supports advanced deployment patterns like canary and blue/green.
• Integrates with Jenkins, TeamCity, Azure DevOps.
8. Spinnaker
• Open-source, multi-cloud continuous delivery platform.
• Developed by Netflix.
• Supports complex deployment strategies and integrates with Kubernetes, AWS, GCP.

Deployment Strategies Supported by Tools

• Rolling Deployment – Deploy updates gradually across servers.
• Blue/Green Deployment – Deploy to a separate environment, then switch traffic.
• Canary Deployment – Release to a small subset of users before full deployment.
• Recreate Deployment – Shut down old version before deploying the new one.

Benefits of Using Deployment Tools

1. Faster and more frequent releases
2. Improved reliability and consistency
3. Reduced manual effort and human error
4. Greater visibility and control
5. Automated rollback in case of failure