CCS356 – OBJECT ORIENTED SOFTWARE ENGINEERING

UNIT – 1
2 MARKS

1. What is Software Engineering?

Software Engineering is the systematic application of engineering principles to the
development, operation, and maintenance of software to ensure reliability, efficiency, and
scalability.

2. What is Software Development Lifecycle (or) Software Process? List out its phases.
The Software Development Lifecycle (SDLC) is a structured process for developing software
that includes distinct phases:
Phases: Requirements gathering, System design, Implementation, Testing, Deployment, and
Maintenance.

3. What is XP (Extreme Programming)?

Extreme Programming (XP) is an Agile software development methodology that emphasizes
customer satisfaction, continuous feedback, rapid releases, and practices like pair
programming, test-driven development, and frequent integration.

4. Recall Agile process?

Agile process is an iterative and incremental software development approach focused on
flexibility, collaboration, customer feedback, and rapid delivery through short development
cycles called sprints.

5. Compare Waterfall model and Spiral model.

• Waterfall Model: Linear and sequential; each phase must be completed before
moving to the next.
• Spiral Model: Combines iterative development with risk analysis; involves repeated
cycles (spirals) of planning, risk assessment, and prototyping.
13 MARKS
1.Introduction to Agility:

Agility in software development refers to the ability to respond quickly and effectively to
changes, whether in requirements, market conditions, or customer needs. Agile teams aim to
deliver high-quality software through iterative development, continuous feedback, and
close collaboration with stakeholders.

Agility focuses on:

• Delivering working software early and often

• Embracing changes even late in development
• Collaborating closely with customers
• Ensuring continuous improvement

Agile Process:

The Agile process is a development approach that breaks the project into small, manageable
units called iterations or sprints, typically lasting 1 to 4 weeks. At the end of each iteration:

• A working product is delivered

• Customer feedback is collected
• Plans are adjusted for the next iteration

This process allows for adaptive planning, frequent reassessment, and faster delivery of
value.

Agile Methodology:

Agile methodology refers to a set of principles and practices for software development
based on the Agile Manifesto. It includes various frameworks such as:

• Scrum – Focuses on roles, time-boxed sprints, and meetings (e.g., daily stand-ups).
• Extreme Programming (XP) – Emphasizes coding practices like pair programming
and TDD.
 • Kanban – Focuses on visualizing the workflow and limiting work-in-progress.

Agile methodologies emphasize collaboration, adaptability, and customer satisfaction

through continuous delivery.

Agile Principles (from the Agile Manifesto):

1. Customer satisfaction through early and continuous delivery.

2. Welcome changing requirements, even late in development.
3. Deliver working software frequently (in weeks, not months).
4. Collaboration between business and developers daily.
5. Build projects around motivated individuals.
6. Use face-to-face conversation as the best form of communication.

Pros of Agile:

• Flexibility to adapt to changes.

• Customer involvement leads to better satisfaction.
• Delivers working software early and often.

Cons of Agile:

• Lack of documentation can be risky in complex systems.

• Not suitable for fixed-scope, fixed-budget projects.
• Requires experienced and collaborative teams.
2.Perceptive and Specialized Software Development Models

Introduction:

Software development models provide a structured approach for planning, executing, and
managing software projects. They guide teams in organizing development activities,
improving productivity, and ensuring quality outcomes.

These models are broadly classified into:

1. Perceptive (Prescriptive) Models

2. Specialized (Adaptive or Domain-Specific) Models

1. Perceptive (Prescriptive) Software Development Models:

Perceptive models are traditional or generic software development approaches that follow a
well-defined sequence of phases such as requirements gathering, design, coding, testing, and
maintenance. These models are best suited for predictable and well-understood projects.

1. Need for a Process Model:

A process model is required to provide a structured approach to software development.

Without a clear model, projects may suffer from poor planning, unclear requirements, missed
deadlines, and low quality.

Importance of a Process Model:

• Defines clear phases and responsibilities

• Helps in project planning and estimation
• Ensures systematic testing and validation
• Improves communication among stakeholders
• Facilitates monitoring and control of progress

2. Prescriptive Process Models:

Prescriptive process models are traditional models that define a set of activities, milestones,
and deliverables in a specific sequence. They assume that software projects follow
predictable paths.

Key Characteristics:

• Structured and systematic

• Emphasize documentation and planning
• Best suited for well-defined requirements
3. Waterfall Model:

The Waterfall Model is the earliest and simplest prescriptive model. It follows a linear
sequential flow, where progress is seen as flowing steadily through phases.

Phases of Waterfall Model:

1. Requirement Analysis
2. System Design
3. Implementation
4. Testing
5. Deployment
6. Maintenance

Advantages:

• Simple to understand and manage

 • Each phase has clearly defined deliverables
• Suitable for small, stable projects

Limitations:

• Difficult to accommodate changes once a phase is completed

• No working software is produced until late in the cycle
• Poor model for complex or evolving requirements

4. Incremental Process Model:

The Incremental Model divides the system into smaller parts (increments) that are
developed and delivered over time.

How It Works:

• Basic functionality is developed first

• Additional features are added in subsequent increments
• Each increment is fully tested and operational

Advantages:

• Early delivery of partial functionality

• Easier to test and debug smaller units
• User feedback is integrated continuously

Limitations:

• Requires well-planned architecture

• Later increments may be costly to change if the base is weak
5. RAD Model (Rapid Application Development):

Rapid Application Development (RAD) is a software development model that emphasizes

quick development and delivery of high-quality software using component-based
construction, prototyping, and user involvement.

Phases of RAD Model:

1. Business Modeling – Understand business functions and information flow.

2. Data Modeling – Define data objects and relationships.
3. Process Modeling – Transform data into usable information processes.
4. Application Generation – Use automated tools to build software quickly.
5. Testing and Turnover – Conduct modular testing and deploy software.

Key Features:

• Short development cycles (30–90 days)

• Heavy use of prototyping
• Reusable components and CASE tools
• Active customer involvement

Advantages:

• Faster development and delivery

• Improved user satisfaction through continuous feedback
• Encourages reuse of software components
Disadvantages:

• Not suitable for large, complex projects

• Requires skilled developers and high user involvement
• Poor scalability for long-term maintenance

6. Evolutionary Process Model:

The Evolutionary Model focuses on developing an initial version of the software, then
continuously refining it based on feedback.

Two Key Types:

1. Prototyping Model – Quickly builds a working prototype to clarify requirements

2. Spiral Model – Combines iterative development with risk analysis

Spiral Model Phases:

1. Planning
2. Risk Analysis
3. Engineering
4. Evaluation
Advantages:

• Encourages early user involvement

• Better suited for complex and high-risk projects
• Facilitates continuous improvement

Limitations:

• Requires more resources and expertise

• Difficult to manage without strong risk assessment

Comparison Summary:

Model Flexibility Risk Handling User Involvement Delivery Time

Waterfall Low Low Low Late in project
Incremental Medium Medium Medium Early & gradual
Evolutionary High High High Early & frequent

2. Specialized Software Development Models:

1. Specialized Software Process Models:

Specialized models are tailored for specific project types, domains, or development
constraints. Unlike general-purpose (prescriptive) models, specialized models address
unique requirements such as high risk, need for rapid prototyping, or strong mathematical
precision.

These models include:

• Component-Based Development (CBD)

• Formal Methods Model
• Aspect-Oriented Software Development (AOSD)
• Spiral Model, Prototyping, and Agile (context-dependent)

They offer flexibility, risk handling, or domain-specific solutions, especially for complex
or evolving systems.

2. Component-Based Development (CBD):

CBD is a development approach that focuses on building software by assembling pre-

existing components, much like building hardware using standardized parts.

Key Concepts:

• Software is divided into independent, reusable modules (components)

• Each component has clearly defined interfaces
 • Components can be developed, tested, and maintained separately

Advantages:

• Promotes reusability and modularity

• Reduces development time and cost
• Improves system reliability through pre-tested components

Disadvantages:

• Integration can be complex

• Component compatibility issues may arise
• May require significant customization or adaptation

3. Formal Methods Model:

Formal methods use mathematical models and logic to specify, develop, and verify
software systems—especially critical where failure is unacceptable (e.g., avionics, medical
systems).

Steps in Formal Methods:

1. Specification – Define system behavior mathematically.

2. Development – Translate specifications into code.
3. Verification – Prove that code conforms to the specification using logical proofs.

Advantages:

• Highly accurate and error-free

• Ensures consistency, completeness, and correctness
• Suitable for safety-critical systems

Disadvantages:

• Requires specialized skills in formal logic/mathematics

• Time-consuming and costly
• Not practical for all types of projects

4. Aspect-Oriented Software Development (AOSD):

AOSD addresses cross-cutting concerns (aspects) that are hard to modularize using
traditional methods, such as:

• Logging
• Security
• Error handling

Core Idea:

Separates core business logic from cross-cutting concerns to improve modularity and
maintainability.

Key Concepts:

• Aspect: A module representing a cross-cutting concern.

• Join point: A point in the execution of a program (e.g., method call).
• Advice: Code that is executed at a join point.
• Weaving: The process of integrating aspects into the main code.

Advantages:

• Improves separation of concerns

• Simplifies code maintenance
• Enhances reusability and clarity

Disadvantages:

• Tool support is still evolving

• Debugging and tracing can become difficult
• May increase learning curve for developers

Comparison Table:

Model Focus Area Suitable For Pros Cons

Component- Reuse of Large systems with Faster Integration
Based existing repeatable development, challenges
modules functions reusable
components
Formal Mathematical Safety-critical High accuracy High cost and
Methods correctness systems and reliability complexity
AOSD Cross-cutting Large modular Clean Hard to
concerns applications separation, debug and
maintainable test
code
Specialized Domain- Complex/custom Tailored Less general
Models specific systems solutions for applicability
(General) requirements special
scenarios
 UNIT – 2
2 MARKS

1. What are Petri Nets?

Petri Nets are a mathematical modeling tool used to represent concurrent, distributed, and
parallel systems. They consist of places, transitions, and tokens and help analyze system
behavior such as deadlocks and synchronization.

2. What is Software Requirement Specification (SRS)?

An SRS is a detailed document that clearly describes the software system's functional and
non-functional requirements. It acts as an agreement between stakeholders and developers,
serving as a basis for design, development, and testing.

3. List out the various diagrams used in object modeling using UML.

The various UML diagrams for object modeling include:

• Use Case Diagram

• Class Diagram
• Object Diagram
• Sequence Diagram
• Collaboration Diagram
• State Chart Diagram
• Activity Diagram
• Component Diagram
• Deployment Diagram

4. What are the types of requirements?

Requirements are mainly of three types:

1. Functional Requirements – Define what the system should do.

2. Non-functional Requirements – Define system performance, usability, reliability,
etc.
3. Domain Requirements – Constraints from the application domain.
5. Define: Finite State Machine.

A Finite State Machine (FSM) is a computational model consisting of a finite number of

states, transitions, and inputs. It is used to design systems with predictable behavior based
on input sequences, such as control systems and protocol design.

13 MARKS
1.Requirements Are Gathered And Analyzed

Introduction:

In Object-Oriented Software Engineering (OOSE), requirements gathering and analysis

involve identifying system behavior in terms of objects, classes, and their interactions.
The goal is to capture what the system should do using models that can later transition
smoothly into design and implementation.

1. Requirements Gathering in OOSE:

a) Stakeholder Identification:

• Identify people who have an interest in the system (users, clients, developers,
regulators).
• Determine their needs and expectations.

b) Techniques for Gathering Requirements:

• Interviews: Structured or unstructured discussions with stakeholders.

• Questionnaires: Used to collect data from a large group.
• Workshops/Brainstorming: Collaborative sessions to elicit ideas.
• Observation: Analyzing how users interact with current systems.
• Use Case Analysis: Capturing functional requirements through user interactions.

c) Use Case Modeling (Core to OOSE):

• A use case describes how a user (actor) interacts with the system to achieve a goal.
• Diagrams are used to visualize actors and their interactions.
• Helps in understanding functional behavior early on.

2. Requirements Analysis in OOSE:

Once the requirements are gathered, the analysis focuses on organizing, modeling, and
validating them.
a) Identifying Classes and Objects:

• Find real-world entities relevant to the system.

• Extract potential classes from use cases, noun-phrase analysis, etc.

b) Creating Object Models:

• Use Class Diagrams to show classes, attributes, and relationships.

• Identify associations, generalizations, and aggregations.

c) Modeling Interactions:

• Use Sequence Diagrams or Collaboration Diagrams to show how objects interact

during use cases.
• Defines the dynamic behavior of the system.

d) State Chart Diagrams:

• Model the states and transitions of objects.

• Especially useful for objects with complex lifecycles.

e) Activity Diagrams:

• Show the workflow or process logic of operations or use cases.

3. Validation of Requirements:

• Ensure that all use cases, scenarios, and object models are consistent, complete, and
correct.
• Conduct walkthroughs, reviews, and prototyping for validation.
• Confirm that requirements reflect user needs and can be implemented.

4. Tools Used in OOSE:

• UML (Unified Modeling Language): Standard language for visualizing and

documenting OO systems.
• CASE Tools: Help generate models and maintain consistency across diagrams.

Advantages of Requirements:

• Close mapping between problem domain and software system

• Easy transition from analysis to design
• Promotes reusability and maintainability
• Encourages modular thinking
2. Software Requirement Specification (SRS)

Definition:

A Software Requirement Specification (SRS) is a formal document that describes the

complete functional and non-functional requirements of the system to be developed. It
acts as a contract between the customer and the developer.

Contents of an SRS Document:

1. Introduction
o Purpose
o Scope
o Definitions
o References
2. Overall Description
o Product perspective
o Product functions
o User characteristics
o Constraints and assumptions
3. Specific Requirements
o Functional requirements (what the system should do)
o Non-functional requirements (performance, reliability, etc.)
o Interface requirements (user, hardware, software)
4. Appendices (Glossaries, diagrams, etc.)

Characteristics of a Good SRS:

• Correct – Accurately describes all system functions

• Complete – Covers all significant requirements
• Unambiguous – Requirements are clearly stated
• Verifiable – Requirements can be tested or measured
• Modifiable – Can be updated easily
• Traceable – Each requirement can be traced to its origin

Importance of SRS:

• Serves as a reference for design, development, and testing

• Reduces development cost and time
• Minimizes miscommunication between stakeholders
• Provides a basis for project management and documentation
3.Formal System Specification

Definition:

Formal System Specification is a process of describing the software system using formal
mathematical methods such as logic, set theory, and algebra to ensure high precision,
accuracy, and verification of requirements.

Key Elements:

1. Formal Syntax – A well-defined grammar for expressing specifications.

2. Formal Semantics – The meaning of the constructs is clearly defined.
3. Formal Verification – Mathematical techniques like proof or model checking ensure
correctness.

Common Formal Specification Languages:

• Z notation
• VDM (Vienna Development Method)
• B-Method
• Alloy

Steps in Formal Specification:

1. Define the abstract model of the system

2. Specify the state and operations formally
3. Apply mathematical proofs or tools to verify the specification
4. Refine and transform into design and code

Advantages:

• Eliminates ambiguity and inconsistency

• Enables early error detection
• Suitable for safety-critical systems (e.g., aviation, nuclear control)
• Provides a verifiable foundation for software design

Disadvantages:

• Requires specialized knowledge in mathematics and logic

• May be time-consuming and costly
• Difficult for non-technical stakeholders to understand

Comparison Table:

Feature SRS Formal Specification

Language Used Natural Language Mathematical / Formal Notation
(structured)
 Understandable by Customers, Developers, Primarily Developers and Formal
Testers Method Experts
Accuracy & Prone to ambiguity Precise and unambiguous
Ambiguity
Verification Through review and Formal proofs and model checking
prototyping
Application Area General-purpose projects Safety-critical and high-assurance
systems

4. Explain Briefly About Elements of Use Case Diagram with Examples

A Use Case Diagram is used in UML to represent the functional behavior of a system as
seen by users (actors). It shows what the system does, not how it does it.

Elements of a Use Case Diagram:

1. Actors:

o External entities that interact with the system.

o Example: Student, Admin in an Online Course Reservation System.
2. Use Cases:

o Functions or services provided by the system.

o Represented by ovals.
o Example: Register Course, Make Payment, View Schedule.

3. System Boundary:

o A box that defines the scope of the system.

o Contains all use cases.

4. Relationships:

o Association: Connects an actor to a use case.

 Example: Student → Register Course

o Include: A use case uses another use case.
 Example: Register Course includes Validate Payment
o Extend: A use case optionally extends another.
 Example: Register Course may be extended by ApplyDiscount
o Generalization: Inheritance between actors or use cases.
 Example: Admin is a specialized form of User
 UNIT – 3
2 MARKS

1. List out the software design patterns.

Software design patterns are reusable solutions to common design problems. They are
generally categorized as:

• Creational Patterns (e.g., Singleton, Factory, Builder)

• Structural Patterns (e.g., Adapter, Composite, Proxy, Facade)
• Behavioral Patterns (e.g., Observer, Strategy, Command, Iterator)

2. What is meant by Adapter in software design?

The Adapter pattern is a structural design pattern that allows incompatible interfaces to
work together. It acts as a bridge between two incompatible classes by converting one
interface into another expected by the client.

3. What is publish-subscribe in software design?

The Publish-Subscribe pattern is a messaging pattern where publishers send messages

without knowing the subscribers, and subscribers receive messages of interest without
knowing the publishers. It supports loose coupling and scalability.

4. What is Proxy, Facade in software design?

• Proxy Pattern: Provides a surrogate or placeholder for another object to control

access to it (e.g., virtual proxy, protection proxy).
• Facade Pattern: Provides a unified and simplified interface to a complex
subsystem, making it easier for clients to interact with the system.

5. What is UI Design?

UI (User Interface) Design refers to the process of designing the visual layout and
interactive elements of software applications. It focuses on usability, aesthetics, and user
experience, ensuring intuitive and user-friendly interfaces.
13 MARKS
1.Architectural Styles
• Architectural style is a pattern for creating the system architecture for the given
problem. Most of the large systems are heterogeneous and do not follow a single
architectural style.
• These styles can provide ideas for creating an architectural view for the given
problem.
• Styles can be combined to form richer views.
• Many systems use multiple styles and different parts of a system may use different
styles.
• Various architectural styles are -
1. Layered architectural style
2. Client Server style
3. Tiered architecture
4. Pipe and Filter style

1. Layered Architecture:

• Also called n-tier architecture.

• The system is organized into hierarchical layers, each with specific responsibilities
(e.g., Presentation, Business Logic, Data Access).

Advantages:

• Enhances modularity and separation of concerns.

• Easier to maintain and test.

Disadvantages:

• Can be less efficient due to overhead of crossing layers.

2. Client-Server Architecture:

• Divides the system into clients (requesters) and servers (responders).

• Commonly used in web applications and distributed systems.

Advantages:

• Supports centralized control and security.

• Clients and servers can be independently maintained.

Disadvantages:

• Server can become a performance bottleneck.

• Requires network communication, which adds complexity.
2. Tiered Architecture:

Tiered architecture is a software design model that separates the system into multiple
logical layers (tiers), where each tier is responsible for a specific functionality. This
promotes modularity, scalability, and maintainability.

Common Tiers:

1. Presentation Tier (Client Layer):

o The user interface.
o Handles input/output and interaction with the user.
o Example: Web browsers, mobile apps.
2. Application Tier (Business Logic Layer):
o Contains the core functionality and business rules.
o Processes user commands and makes logical decisions.
o Example: Login authentication, order processing.
3. Data Tier (Database Layer):
o Manages data storage, retrieval, and management.
o Interfaces with the database system.
o Example: MySQL, Oracle, MongoDB.

Advantages:

• Separation of concerns improves code manageability.

• Easier to scale and maintain individual tiers.
• Reusability of components (e.g., same business logic for web and mobile apps).

Disadvantages:

• Slightly increased complexity in design and deployment.

• May introduce performance overhead due to inter-tier communication.

Example:

A web application where:

• Frontend is built in HTML/CSS/JavaScript (Presentation Tier),

• Backend logic is in Java or Python (Application Tier),
• Data is stored in PostgreSQL or MySQL (Data Tier).
4. Pipe and Filter Architecture:

• Data flows through a sequence of processing elements (filters) connected by pipes.

• Each filter processes the data and passes it on.

Advantages:

• Easy to reuse and test individual filters.

• Supports concurrent processing.

Disadvantages:

• Not ideal for systems requiring shared state or context.

2. Explain the Software Design Process

Definition:

The software design process transforms requirements into a blueprint for constructing
software. It bridges the gap between requirement specification and implementation,
focusing on structure, behavior, and interaction of software components.

Phases of the Software Design Process:

1. Architectural Design (High-level Design):

• Identifies the overall system structure.

• Defines major components (modules), their responsibilities, and interactions.
• Output: Architectural diagrams and descriptions.
2. Data Design:

• Specifies the data structures, database schemas, and data flows.

• Ensures efficient access, storage, and manipulation of data.

3. Interface Design:

• Describes interactions between system components and between system and users.
• Includes API definitions, UI screens, and communication protocols.

4. Component-Level Design (Detailed Design):

• Defines the logic within each module.

• Includes algorithm selection, control structures, and low-level processing logic.

5. Design Validation:

• Ensure that the design aligns with requirements using walkthroughs, reviews, or
prototyping.

Design Principles Used:

• Modularity
• Abstraction
• Information hiding
• Separation of concerns
• Consistency

3. Explain Coupling, Cohesion, and Functional Independence

1. Functional Independence:

• A design principle where modules or components perform one function and

perform it well.
• Each module should have high cohesion and low coupling.
• Benefits: Easier to develop, test, maintain, and reuse.

2. Cohesion:

• Measures the degree to which the elements within a module belong together.
• High cohesion means a module performs a single, well-defined task.

Types of Cohesion (from lowest to highest):

1. Coincidental – Random tasks (worst)

2. Logical – Related functions grouped (e.g., input handling)
 3. Temporal – Tasks done at the same time (e.g., init tasks)
4. Procedural – Tasks done in sequence
5. Communicational – Tasks using the same data
6. Sequential – Output of one part is input to another
7. Functional – One single, well-defined task (best)

3. Coupling:

• Refers to the degree of interdependence between modules.

• Low coupling is preferred as it means modules are independent and interact
minimally.

Types of Coupling (from highest to lowest):

1. Content Coupling – One module modifies another's code (worst)

2. Common Coupling – Shared global data
3. Control Coupling – One module controls another’s flow
4. Stamp Coupling – Passes composite data structures
5. Data Coupling – Only necessary data is shared (best)

Why They Matter:

• High cohesion and low coupling ensure modularity, which leads to:
o Easier debugging
o Simpler updates
o Better scalability
o Reusability of components

UNIT – 4
2 MARKS
1. What is Symbolic Execution?

Symbolic execution is a software testing technique where program inputs are treated as
symbolic values instead of concrete data. It explores program paths by analyzing the logic
with symbolic inputs to detect bugs, unreachable code, and security issues.

2. What is Model Checking?

Model checking is an automated technique used to verify whether a system model satisfies
formal specifications (e.g., properties expressed in temporal logic). It exhaustively checks
all possible system states to detect errors like deadlocks, safety violations, and liveness
issues.
3. Define: Debugging

Debugging is the process of identifying, analyzing, and removing errors (bugs) in a

software program. It involves locating the source of the defect and modifying the code to
ensure correct behavior.

4. What is Regression Testing?

Regression testing is the process of re-testing a software system after changes (like bug
fixes or enhancements) to ensure that existing functionalities still work as intended and that
new bugs haven’t been introduced.

5. Write the Difference Between Black Box and White Box Testing:

Black Box Testing White Box Testing

Tests without knowledge of internal code. Tests with full access to source code.
Focuses on functionality. Focuses on logic and structure.
Performed by testers. Often done by developers.

13 MARKS

1. What is software testing? Explain the steps involved in it.

Definition:

Software testing is the process of evaluating a software application to ensure it meets the
specified requirements and is free of defects. It helps to verify the correctness, completeness,
and quality of the software product.

Goals of Software Testing:

• Detect bugs and defects

• Ensure reliability and performance
• Validate that the software behaves as expected

Steps Involved in Software Testing Process:

 1. Test Planning:
o Define the scope, objectives, schedule, and resources of testing.
o Identify tools, responsibilities, and test environments.
2. Test Design:
o Prepare test cases, test data, and test scenarios based on requirements.
o Use techniques like equivalence partitioning, boundary value analysis, etc.
3. Test Environment Setup:
o Prepare hardware and software environment where testing will be executed.
o Includes server setup, database, and configurations.
4. Test Execution:
o Run the test cases manually or using automation tools.
o Record actual results and compare with expected results.
5. Defect Reporting and Tracking:
o Log defects in a bug-tracking system (e.g., JIRA, Bugzilla).
o Assign severity and priority for fixing.
6. Test Closure:
o Evaluate test completion criteria, finalize test reports.
o Document lessons learned and release for production.

2. Explain integration and system testing with application.

1. Integration Testing:

Definition:

Integration testing focuses on verifying data flow and interactions between integrated
modules.

Purpose:

• Ensure that interfaces between modules work correctly.

• Identify interface defects early.

Approaches:

• Top-down, bottom-up, big bang, and sandwich integration.

Example:

In an online shopping app, after unit testing the "cart" and "payment" modules, integration
testing checks:

• Whether the cart transfers correct total to payment,

• Whether payment confirms and updates the cart state.

2. System Testing:
Definition:

System testing validates the entire software system against its functional and non-functional
requirements.

Purpose:

• Ensure the system works as a whole.

• Covers end-to-end scenarios, including UI, database, security, and performance.

Types of System Testing:

• Functional testing
• Performance testing
• Security testing
• Usability testing

Example:

For the same shopping app:

• A user logs in, searches for a product, adds it to the cart, makes payment, and receives
a confirmation.
• All functions are tested in sequence.

4.Explain white box and black box testing with applications.

Introduction to Software Testing:

Software testing ensures that a system works correctly, meets requirements, and is free of
defects. Two primary testing methods used during the software development lifecycle are
White Box Testing and Black Box Testing.

1. White Box Testing:

Definition:

White box testing (also called structural, clear box, or glass box testing) is a method where
the internal structure and logic of the program are known and tested.

Characteristics:

• Performed by developers or testers with knowledge of source code.

 • Focuses on control flow, code paths, and data flow.
• Used primarily during unit testing and integration testing.

Techniques in White Box Testing:

• Statement Coverage – Every statement in the code is executed at least once.

• Branch Coverage – All decision branches (if/else, switch) are tested.
• Path Coverage – All possible execution paths are tested.
• Loop Testing – Ensures loops (for, while) behave as expected.

Advantages:

• Helps optimize and improve code.

• Detects hidden bugs like logical errors, unreachable code, or dead code.
• Supports test case optimization.

Disadvantages:

• Requires access to and understanding of code.

• Not effective for missing functionalities.

Applications:

• Embedded systems (where logic must be tested precisely).

• Banking software (to test logic-heavy components like interest calculation).

2. Black Box Testing:

Definition:

Black box testing is a method where the tester does not know the internal logic or code of
the application and tests it purely based on inputs and expected outputs.

Characteristics:

• Conducted by testers or QA engineers.

• Focuses on functional correctness, user interactions, and system behavior.
• Used during system testing, acceptance testing, and regression testing.

Techniques in Black Box Testing:

• Equivalence Partitioning – Divide inputs into valid and invalid groups.

• Boundary Value Analysis – Test edge cases.
• Cause-Effect Graphing – Understand relationships between input and output.
• Decision Table Testing – Represent rules and conditions.

Advantages:

• Tests from a user perspective.

 • No need to understand the internal code.
• Effective for functional and acceptance testing.

Disadvantages:

• Limited in identifying internal code issues.

• Difficult to design test cases if requirements are ambiguous.

Applications:

• Web applications (testing forms, login pages).

• Mobile apps (testing interface responsiveness and usability).
• Retail/Banking software (test transaction workflows, UI behavior).

Comparison Table:
Feature White Box Testing Black Box Testing
Knowledge Requires code knowledge No code knowledge needed
Required

Focus Internal logic and structure Functionality and behavior

Performed By Developers/Testers QA Engineers/Testers
Testing Level Unit, Integration System, Acceptance
Tools JUnit, NUnit, Code Coverage Selenium, QTP,
tools TestComplete
Examples Algorithm testing Login form validation

UNIT – 5
2 MARKS

1. What is Software Project Management?

Software Project Management is the process of planning, organizing, monitoring, and

controlling software projects to ensure they are completed on time, within budget, and
meet quality requirements. It involves resource management, risk handling, scheduling, and
team coordination.
2. Define: Software Configuration Management (SCM)

Software Configuration Management is the process of systematically managing changes

to software to maintain integrity and traceability throughout the development lifecycle. It
involves version control, change control, and status reporting.

3. What is Project Scheduling?

Project Scheduling is the process of defining and organizing project tasks and timelines,
allocating resources, and establishing start and end dates to ensure the project progresses in a
controlled and timely manner.

4. Add a Note on: Cloud as a Platform

Cloud as a Platform (PaaS) provides a framework and environment for developers to

build, test, and deploy applications over the internet. It offers scalability, flexibility, and
reduced infrastructure costs, with services like databases, development tools, and
application hosting.

5. What are Deployment Tools?

Deployment tools are software utilities that help automate the process of deploying
applications to production environments. Examples include Docker, Jenkins, Ansible, and
Kubernetes, which streamline updates, rollbacks, and environment management.

13 MARKS
1. Project Scheduling

Definition:

Project scheduling is the process of defining the timeline, tasks, resources, and milestones
of a software project to ensure timely delivery.

Objectives:

• Allocate time and resources efficiently

• Identify task dependencies and sequencing
• Monitor project progress and deadlines
Key Elements:

1. Work Breakdown Structure (WBS):

o Breaking the project into manageable tasks or modules.
2. Task Sequencing & Dependencies:
o Identify which tasks must be completed before others begin.
o Represented using tools like PERT or Gantt charts.
3. Estimation Techniques:
o Time and effort estimates using models like COCOMO or expert judgment.
4. Resource Allocation:
o Assign developers, testers, and tools for each task.
5. Milestones and Deadlines:
o Key deliverables and checkpoints to assess progress.

Tools Used:

• Microsoft Project
• JIRA
• GanttPRO
• Trello

Benefits:

• Improved transparency and planning

• Early detection of delays and risks
• Better team coordination

2. DevOps

Definition:

DevOps is a software development methodology that emphasizes collaboration between

development (Dev) and operations (Ops) teams to enable continuous integration,
delivery, and deployment (CI/CD).
Key Principles:

1. Automation – Automated build, test, and deployment pipelines.

2. Continuous Integration (CI) – Frequent code integration and testing.
3. Continuous Delivery (CD) – Rapid, reliable release of software.
4. Monitoring – Constant system monitoring for performance and issues.
5. Collaboration – Bridging gaps between development and operations teams.

DevOps Tools:

• Version Control: Git, GitHub

• CI/CD: Jenkins, GitLab CI
• Containerization: Docker, Kubernetes
• Monitoring: Prometheus, Grafana

Benefits:

• Faster delivery of features

• Improved quality and reliability
• Reduced time between development and production

3. Cloud as a Platform (PaaS)

Definition:

Cloud as a Platform, also known as Platform as a Service (PaaS), provides a development

and deployment environment in the cloud. Developers use it to build and deploy
applications without worrying about underlying infrastructure.

Examples of PaaS Providers:

• Microsoft Azure
• Google App Engine
• AWS Elastic Beanstalk
 • Heroku

Features:

• Pre-configured servers, databases, and frameworks

• Integrated development tools
• Scalability and high availability
• Security and compliance management

Advantages:

• Reduces infrastructure setup time

• Promotes rapid application development
• Supports collaborative development with version control
• Scales automatically with user demand

Use Cases:

• Hosting web apps and APIs

• Mobile backend services
• Continuous testing and deployment

4.Deployment Pipeline – Overall Architecture

Definition:

A Deployment Pipeline is an automated process that supports continuous integration (CI),

continuous delivery (CD), and continuous deployment. It ensures that code changes move
smoothly from development to production in a reliable and repeatable manner.

Phases of Deployment Pipeline Architecture:

1. Code Commit (Source Control)

• Developers write code and commit changes to a version control system (VCS).
• Tool Examples: Git, GitHub, GitLab, Bitbucket

2. Build Phase

• Source code is compiled and dependencies are resolved.

• Artifacts (executables, binaries) are generated.
• Tool Examples: Maven, Gradle, Ant

3. Automated Testing
 • Unit, integration, and functional tests are run to validate the code.
• Ensures code quality before proceeding to next stages.
• Tool Examples: JUnit, Selenium, TestNG

4. Continuous Integration (CI)

• Combines code from multiple developers and tests the integrated code automatically.
• Detects errors early.
• Tool Examples: Jenkins, CircleCI, Travis CI

5. Artifact Repository

• Successfully built artifacts are stored for reuse in deployment.

• Tool Examples: Nexus Repository, JFrog Artifactory

6. Staging Environment

• Code is deployed to a pre-production environment to simulate real-world usage.

• Performance and user acceptance tests are done here.
• Tools Used: Docker, Kubernetes (for containerization)

7. Continuous Delivery/Deployment (CD)

• In Continuous Delivery, the code is automatically ready for release.

• In Continuous Deployment, the code is automatically pushed to production after
passing tests.
• Tool Examples: Spinnaker, GitLab CI/CD, Harness

8. Production Deployment

• Final tested version is deployed to the live server.

• Supports features like blue-green deployment or canary releases.

9. Monitoring and Feedback

• Application performance and errors are monitored continuously.

• Feedback is provided to developers.
• Tool Examples: Prometheus, Grafana, New Relic, ELK Stack

Deployment Pipeline Architecture Diagram (Text Format)

[Code Commit] → [Build] → [Test] → [Artifact Repository] → [Deploy to
Staging]
↓ ↓ ↓ ↓
GitHub Maven JUnit/Selenium Docker/Kubernetes
→ [Deploy to Production]
↓
Spinnaker, Jenkins
→ [Monitor & Feedback]
↓
Prometheus, Grafana, ELK
Benefits of Deployment Pipeline:

• Faster Releases: Automates all stages of development and deployment.

• Improved Quality: Automated testing ensures bugs are caught early.
• Reduced Risk: Controlled and predictable deployments.
• Continuous Feedback: Helps teams improve software and user experience rapidly.
Various UML Diagrams and Their Purpose
Unified Modeling Language (UML) is a standardized modeling language used to
visualize, specify, construct, and document the artifacts of a software system. UML
provides a set of diagram types, each serving a specific purpose. UML diagrams are
categorized into structural diagrams and behavioral diagrams.

1. Structural Diagrams

Structural diagrams focus on the static aspects of the system, such as objects, classes,
and components. They describe the system's structure and the relationships between
elements.

1.1. Class Diagram

• Purpose:
Describes the static structure of a system in terms of its classes, attributes,
methods, and their relationships (associations, inheritance, dependencies).

• Usage:
It is used to model the objects and classes in the system, their attributes, and
their interactions.

• Purpose:
Represents a snapshot of the system at a particular moment in time, showing
instances of classes and their relationships.

• Usage:
Used to visualize real-time instances or objects and their state at a certain point
in time.
1.3. Component Diagram

• Purpose:
Describes the organization and dependencies of the components within the
system, including their interfaces and the relationships between them.

• Usage:
Used to model the physical structure of the system and the interaction between
various components (e.g., libraries, services)

1.4. Deployment Diagram

• Purpose:
 Describes the physical deployment of software artifacts on hardware nodes. It
represents how software components are distributed across servers,
workstations, and other devices.

• Usage:
Used to model the hardware architecture of the system, focusing on physical
nodes (computers, devices) and their communication

1.5. Package Diagram

• Purpose:
Shows how the system is divided into packages (groups of related classes,
components, etc.) and how they depend on each other.

• Usage:
Used to organize and manage large systems, displaying dependencies between
packages.
2. Behavioral Diagrams

Behavioral diagrams describe the dynamic aspects of the system, focusing on the
interaction, flow, and state of components.

2.1. Use Case Diagram

• Purpose:
Represents the functional requirements of a system by showing actors (users or
other systems) and the use cases (system functionalities) that they interact with.

• Usage:
Used to capture the requirements and user interactions with the system.

• Purpose:
Models the interactions between objects or components over time, showing the
sequence of messages exchanged between objects.

• Usage:
Used to capture the detailed flow of control in a use case or scenario.
• Purpose:
Represents the interaction between objects, focusing on the organization of
objects and the messages they exchange.

• Usage:
Used to show the collaboration between components during a specific interaction
or scenario.
2.4. State Machine Diagram (Statechart)

• Purpose:
Represents the states of an object or system and the transitions between those
states based on events.

• Usage:
Used to model the behavior of objects over time, especially those with complex
states (e.g., workflows, state-based systems).

• Purpose:
Describes the flow of control and activities within a process, showing activities,
decisions, and concurrent actions.

• Usage:
Used to model business workflows, processes, or algorithms.
2.6. Communication Diagram

• Purpose:
Similar to the sequence diagram, but focuses on the objects and their
relationships rather than the time sequence of interactions.

• Usage:
Used to model dynamic interactions between objects, emphasizing collaborations
rather than sequential messages.

2.7. Timing Diagram

• Purpose:
Focuses on the timing constraints of messages exchanged between components,
often used in real-time systems.

• Usage:
Used to model time-sensitive interactions and constraints.

• Example:
A timing diagram for network communication, showing time delays between
data packets.
2.8. Interaction Overview Diagram

• Purpose:
A high-level overview of interactions, combining elements from activity
diagrams and sequence diagrams to model a flow of control.

• Usage:
Used to model complex interactions or high-level workflows involving several
scenarios.

• Example:
An interaction overview for the E-commerce checkout process showing the
interaction between User, Cart, Payment, and Shipping.