Contents

SOFTWARE ENGINEERING ............................................................................................................................................ 3

SOFTWARE DEVELOPMENT LIFE CYCLE ................................................................................................................. 3
WATERFALL MODEL ........................................................................................................................................................ 4
SPIRAL MODEL .................................................................................................................................................................. 6
PROTOTYPE MODEL ........................................................................................................................................................ 7
AGILE MODEL.................................................................................................................................................................... 8
TSP [TEAM SOFTWARE PROCESS] ............................................................................................................................. 10
EXTREME PROGRAMMING ......................................................................................................................................... 10
SCRUM ................................................................................................................................................................................ 11
REQUIREMENTS .............................................................................................................................................................. 12
SOFTWARE DESIGN: IDENTIFYING ACTORS, USE CASES AND ACTIONS ..................................................... 17
GENERALIZATION .......................................................................................................................................................... 18
SPECIALIZATION ............................................................................................................................................................ 19
AGGREGATION ................................................................................................................................................................ 20
RELATIONSHIPS .............................................................................................................................................................. 20
MODULAR DESIGN – COUPLING AND COHESION ................................................................................................ 22
COUPLING ......................................................................................................................................................................... 22
COHENSION ...................................................................................................................................................................... 23
STUPID Principles: ............................................................................................................................................................ 24
SOLID Principles: ............................................................................................................................................................... 25
GRASP Principles: .............................................................................................................................................................. 26
IMPORTANCE OF SOFTWARE QUALITY ASSURANCE ......................................................................................... 28
SOFTWARE REVIEWS .................................................................................................................................................... 29
TEST-DRIVEN DEVELOPMENT ................................................................................................................................... 30
UNIT TESTING .................................................................................................................................................................. 30
BLACK BOX TESTING .................................................................................................................................................... 31
WHITE BOX TESTING .................................................................................................................................................... 32
VERIFICATION AND VALIDATION ............................................................................................................................. 33
SOFTWARE ENGINEERING

• Software is a program or set of programs containing instructions that provide desired

functionality. And Engineering is the process of designing and building something that
serves a particular purpose and finds a cost-effective solution to problems.
• Software engineering is a discipline that involves the application of engineering principles to
the design, development, maintenance, testing, and evaluation of software and systems that
make use of software.
• It encompasses a systematic and structured approach to software development, with the goal
of creating high-quality, reliable, and maintainable software.
• Software engineering involves managing the entire lifecycle of a software product, from
conception and development to deployment, maintenance, and eventual retirement.
• Popular methodologies in software engineering include Agile, Scrum, Waterfall, and
DevOps, each with its own approach to organizing and executing the development process.

SOFTWARE DEVELOPMENT LIFE CYCLE

• The Software Development Life Cycle (SDLC) is a process used by software development
teams to design, develop, test, and deploy high-quality software.
• The taxonomy of SDLC can be organized into several phases, each serving a specific
purpose.
 1. Planning: Define project goals, scope, and timelines. Assess resources and conduct risk
analysis. Develop a comprehensive project plan outlining tasks and responsibilities.

2. Analysis: Gather and document user requirements through interviews and analysis.
Validate and prioritize requirements to ensure alignment with project goals. Create
detailed documentation to guide the development process.

3. Design: Develop a system architecture outlining key components and their interactions.
Create detailed design specifications for individual modules. Define data structures,
algorithms, and interfaces.

4. Implementation (Coding): Translate design specifications into executable code using

chosen programming languages. Follow coding standards and best practices to ensure
code readability and maintainability. Use version control systems to track changes.

5. Testing: Execute unit tests to validate individual components. Integrate modules and
perform integration testing to identify and rectify issues. Conduct system testing to
ensure the software meets specified requirements.

6. Deployment: Release software for use by installing and configuring it in the target
environment. Monitor deployment for any issues and provide necessary support. Ensure
compatibility and proper functioning.

7. Maintenance: Address and resolve reported bugs promptly. Implement updates and
enhancements based on changing requirements. Continuously monitor and optimize the
software for improved performance.

WATERFALL MODEL

• The Waterfall model is a linear and sequential approach to software development, where
progress is seen as flowing steadily through distinct phases.
• The waterfall model is useful in situations where the project requirements are well-defined
and the project goals are clear. It is often used for large-scale projects with long timelines.
• Here are the phases of the Waterfall model:
 1. Requirements: Define project goals and gather comprehensive requirements.
2. Design: Develop system architecture and detailed component designs.
3. Implementation: Translate designs into executable code using chosen programming
languages.
4. Testing: Validate software through sequential unit, integration, and system testing.
5. Deployment: Release and install fully developed software in the target environment.
6. Maintenance: Address bugs, implement updates, and provide ongoing support.
• Key Characteristics:
o Each phase must be completed before moving to the next, resembling a waterfall's
downward flow.
o The process is document-centric, with extensive documentation created at each phase.
o Changes are challenging to accommodate once the project moves beyond the
requirements phase.
o Well-suited for projects with well-defined and stable requirements.
• Advantages:
o Clear documentation and well-defined phases.
o Easy to understand and use.
• Disadvantages:
o Limited flexibility to accommodate changes.
o Client sees the product only after the final implementation phase.
o Risk of project delays if requirements are not accurately gathered initially.
SPIRAL MODEL

• The Spiral Model is a flexible and iterative approach to software development that combines
elements of both the waterfall model and prototyping.
• It is based on the idea of a spiral, with each iteration of the spiral representing a complete
software development cycle, from requirements gathering and analysis to design,
implementation, testing, and maintenance.
• It provides support for Risk Handling.
• Here are the phases of the Spiral Model:

o Planning: Identify project goals and risks; develop strategies.

o Risk Analysis: Evaluate and mitigate potential project risks.
o Engineering (Development): Implement planned features incrementally in iterative
cycles.
o Evaluation (Testing): Conduct testing and gather feedback; assess iteration viability.
o Review and Planning: Decide whether to proceed to the next iteration; review results
and plan accordingly.
• Key Characteristics:
o Iterative cycles resembling a spiral allow for continuous refinement.
o Emphasizes risk analysis and management throughout the development process.
o Flexibility to accommodate changes and improvements in subsequent iterations.
o Suitable for large and complex projects with evolving requirements.
• Advantages:
o Emphasizes risk management from the early stages.
o Allows for incremental development and frequent reassessment.
• Disadvantages:
o Can be time-consuming and costly due to multiple iterations.
o Requires a good understanding of the application domain and potential risks.

PROTOTYPE MODEL

• The Prototype Model is an iterative software development model that involves creating a
partial or complete working model of the system during the early stages of the project.
• In this model, a prototype of the end product is first developed, tested, and refined as per
customer feedback repeatedly till a final acceptable prototype is achieved which forms the
basis for developing the final product.
• Here are the phases of the Prototype Model:

1. Requirements Analysis: Gather initial user requirements through interviews and

feedback.
2. Quick Design: Create a basic model focusing on core functionalities.
3. Build Prototype: Implement a working model emphasizing functionality over
comprehensive features.
4. User Evaluation: Collect user feedback on the prototype for insights.
 5. Refinement: Modify and enhance the prototype based on user input in iterative
cycles.
• Key Characteristics:
o Early, tangible representation of the software aids in user feedback.
o Iterative cycles of refinement based on user evaluation.
o Suitable for projects with evolving or unclear requirements.
o Can be used as a basis for subsequent development methodologies.
• Advantages:
o Early user involvement and feedback.
o Supports the exploration of design alternatives.
• Disadvantages:
o May require additional effort in prototype construction.
o Potential for misunderstandings regarding the nature of a prototype.

AGILE MODEL

• The Agile Model is an iterative and flexible approach to software development that
prioritizes adaptability and customer satisfaction by rapid delivery of working software
product.
• The main aim of the Agile model is to facilitate quick project completion.
• Agile Methods break the product into small incremental builds. These builds are provided in
iterations.
• The Agile model consists of the following phases:
1. Requirements Gathering: Define project requirements, assess feasibility, and plan
resources.
2. Design the Requirements: Collaborate with stakeholders to detail requirements using
diagrams like user flow or high-level UML.
3. Development: Development begins based on defined requirements, aiming for a
working product with minimal functionality.
 4. Testing/Quality Assurance: Quality Assurance examines the product for performance
and identifies bugs.
5. Deployment: Release the product to the user environment.
6. Feedback: Gather and incorporate feedback from users to improve the product.

• Key Characteristics:
o Emphasizes incremental development with regular, short-term goals (sprints).
o Customer feedback is prioritized, allowing for quick adjustments to changing
requirements.
o Cross-functional teams collaborate closely throughout the development process.
o Adaptable to changes in project scope and requirements.
• Advantages:
o Customer involvement and feedback lead to customer satisfaction.
o Flexibility to accommodate changing requirements.
• Disadvantages:
o Requires active and consistent participation from all team members.
o Initial learning curve for teams new to the Agile methodology.
TSP [TEAM SOFTWARE PROCESS]

• TSP, or Team Software Process, is a framework for software process improvement that
focuses on enhancing the effectiveness of software development teams.
• TSP builds on the principles of the Personal Software Process (PSP) and extends them to the
team level.
• TSP is designed to help teams organize projects and produce software.
• It focuses on disciplined processes, measurement, and continuous improvement.
• The goal is to create a high-performance team that consistently delivers high-quality
software on time and within budget.
• Key features of TSP include:
1. Structured Process: TSP defines a structured process that teams follow for planning,
tracking, and managing their work.
2. Team Planning: Teams use TSP to plan their projects, considering resources,
schedules, and quality goals.
3. Incremental Development: Like other process improvement models, TSP promotes
incremental and iterative development.
4. Metrics and Measurement: TSP emphasizes the use of metrics to measure and track
the progress of the team and the quality of the software being developed.
5. Risk Management: TSP incorporates risk management practices, helping teams
identify and address potential issues early in the development process.
6. Formal Inspections: Formal inspections of work products are conducted to ensure
quality and identify defects.

EXTREME PROGRAMMING

• Extreme programming (XP) is defined as a software engineering paradigm that uses an

Agile-based software development framework to optimize the software development process
by creating good quality programs while considering constantly shifting end-user demands.
• The process focuses on shorter development cycles to enhance overall software productivity
and establishes crucial checkpoints while adapting to new customer requirements.
• The extreme programming framework follows a workflow that involves five iterative
development stages.
1. Planning: Define project goals and features collaboratively. Prioritize and estimate
effort.
2. Designing: Develop a simple and effective design. Create basic architecture and
structures.
3. Coding: Implement features using test-driven development. Write code
collaboratively and follow standards.
4. Testing: Validate features through rigorous testing. Execute unit and integration tests.
5. Listening: Gather feedback for continuous improvement. Engage in retrospectives
and review feedback.
• XP is based on five fundamental values:
1. Communication: Emphasizes constant and transparent collaboration among team
members and stakeholders.
2. Simplicity: Prioritizes straightforward and minimalistic design and implementation to
enhance clarity.
3. Feedback: Values regular input from users and team members to adapt and improve
continuously.
4. Courage: Encourages the team to take risks, address challenges, and experiment with
new ideas.
5. Respect: Promotes a supportive and inclusive environment, appreciating diverse
perspectives and contributions.

SCRUM

• Scrum is an Agile framework for managing and developing complex products. It emphasizes
collaboration, adaptability, and iterative progress.
• Scrum is based on incremental development, consisting of a series of sprints lasting from
two to four weeks in length. During each sprint, the goal is to focus on the highest-value
features, ideally ending up with a deliverable product. Between sprints, the development
 team meets with stakeholders and customers for feedback. This feedback is incorporated into
the planning process for the next sprint.
• Key Scrum roles and terms include:
1. Product Backlog: A dynamic list of features, enhancements, and fixes prioritized by
the product owner. It represents the work that needs to be done on a project.
2. Increment: The sum of all completed product backlog items at the end of a sprint. It
is a potentially shippable product version that adds value to the existing product.
3. ScrumMaster: A facilitator and servant-leader for the Scrum team. The ScrumMaster
helps the team understand and follow Scrum practices, removing obstacles to
maximize efficiency.
4. Sprint: A time-boxed iteration, typically two to four weeks long, during which the
Scrum team works on a set of prioritized product backlog items. It results in a
potentially shippable increment.
5. Velocity: A metric measuring the amount of work a Scrum team can complete in a
sprint. It helps in estimating future capacity and improving planning accuracy.
• Advantages of Scrum:
o Adaptability: Flexibility for changing requirements.
o Transparency: Clear communication and visibility.
o Customer Satisfaction: Continuous delivery aligns with customer expectations.
• Disadvantages of Scrum:
o Learning Curve: Initial challenges for teams new to Scrum.
o Overemphasis on Meetings: Potential time consumption.
o Not Suitable for All Projects: May not fit well with highly stable requirements.

REQUIREMENTS

• Understanding requirements involves analyzing and defining the needs, constraints, and
expectations of a system or product. It's a crucial phase to ensure that the developed solution
meets stakeholders' objectives.
o Functional and Non-Functional Requirements
o User and System Requirements
 o Requirements Elicitation
o Requirements Specification

Functional and Non-Functional Requirements:

• Functional Requirements: Specify what the system must do. For example, in an e-commerce
system, functional requirements might include user registration, product browsing, and
checkout functionalities.
• Non-Functional Requirements: Define the characteristics of the system, such as
performance, reliability, and security. These requirements focus on "how" the system should
behave.
Functional Requirements Non-Functional Requirements
A functional requirement defines a system or A non-functional requirement defines the
its component. quality attribute of a software system.
Functional requirement is specified by User. Non-functional requirement is specified by
technical peoples e.g., Architect, Technical
leaders and software developers.
It is mandatory. It is not mandatory.
It is captured in use case. It is captured as a quality attribute.
Defined at a component level. Applied to a system as a whole.
Helps you verify the functionality of the Helps you to verify the performance of the
software. software.
Functional Testing like System, Integration, Non-Functional Testing like Performance,
End to End, API testing, etc. are done. Stress, Usability, Security testing, etc. are
done.
They are easy to define. They are hard to define.
Examples of the functional requirements Examples of the non-functional
are - Authentication of a user on trying requirements are - The background
to log in to the system. color of the screens should be light blue.
Requirements Elicitation:

• Requirements elicitation is the process of engaging with stakeholders to uncover and

understand their needs for a software project.
• It involves effective communication through methods like interviews, surveys, and
workshops.
• Prototypes and models may be used to visualize requirements, while observation helps
reveal implicit needs.
• Document analysis and open-ended questioning ensure a comprehensive understanding, with
a focus on prioritization and a continuous feedback loop to refine and validate requirements.
• This process ensures that the resulting software aligns closely with user expectations and
business goals.

User vs System Requirements:

• User Requirements: Represent the needs of end-users and stakeholders. These requirements
focus on functionalities and experiences that will meet user expectations.
• System Requirements: Define the technical aspects and constraints that the system must
adhere to. These include performance metrics, security protocols, and integration
specifications.
 Aspects User Requirements System Requirements
Definition Express needs and expectations from an Specify functionalities, constraints, and
end-user perspective technical details
Focus Emphasizes user experience and high- Focuses on technical and system-level details
level functionalities
Level of Detail Relatively high-level, describing what More detailed, specifying how the system will
users want meet needs
Language Uses user-friendly and non-technical Involves technical terminology and
language specifications
Stability May evolve or change during the project More stable once established, with changes
requiring rigor
Change Control May be subject to more frequent changes Changes typically require careful
consideration and control
Acceptance Used to evaluate if the system meets user Used to assess if the system meets technical
Criteria expectations specifications
Example "The system should provide an intuitive "The system should process transactions at a
user interface." rate of 1000 per second."

Requirements Specification:

• Requirements specification involves formally documenting gathered requirements for clear

reference throughout the software development process.
• This phase includes detailing both functional and non-functional requirements, expressed
through documents, user stories, or use cases.
• Validation and verification criteria, traceability matrices, and version control mechanisms are
employed to ensure clarity, consistency, and alignment with the project scope.
• Regular communication with stakeholders helps in addressing changes or updates, ensuring
a shared understanding.
• Thorough requirements specification serves as a roadmap, reducing misunderstandings and
enhancing the likelihood of successful project delivery.
SOFTWARE DESIGN: IDENTIFYING ACTORS, USE CASES AND
ACTIONS

• Software design is a critical phase in the software development lifecycle where the
conceptualized system takes shape.
• In this phase, key elements such as actors, use cases, and actions are identified to lay the
foundation for the system's structure and behavior.
• Identifying actors, use cases, and actions is a fundamental step in software design, aligning
the system's functionalities with user needs and setting the stage for the subsequent design
and development activities.
• Actors:
o Definition: Actors are entities that interact with the system, typically external to it.
They can be users, other systems, or external components.
o Identification: Actors are identified by analyzing who or what interacts with the
system to achieve specific goals.
• Use Cases:
o Definition: Use cases represent specific functionalities or features the system must
provide to meet user or system goals.
o Identification: Use cases are identified by understanding the different ways in which
actors interact with the system to achieve specific outcomes.
• Actions:
o Definition: Actions represent the specific operations or tasks performed by actors or
the system within a use case.
o Identification: Actions are identified by breaking down each use case into discrete
steps or operations, defining how the system responds to actor interactions.
• Significance of Identifying Actors, Use Cases, and Actions:
o Clarity in Functionality: Identifying actors, use cases, and actions provides clarity
on the system's functionality by defining who interacts with it, what functionalities are
needed, and how these functionalities are executed.
 o User-Centric Design: By understanding actors and their goals, the design process
becomes user-centric, ensuring that the system is tailored to meet the needs and
expectations of its users.
o Basis for Interaction Design: The identification of actions within use cases becomes
the basis for designing the system's interactions, helping in creating intuitive and
efficient user interfaces.
o Foundation for System Architecture: Actors and use cases lay the foundation for the
system's architecture and help in defining the boundaries and responsibilities of
various components.

GENERALIZATION

• Generalization is a concept in software design and object-oriented programming (OOP) that

involves creating a more generalized or abstract form of a concept to facilitate code reuse
and design flexibility.
• Generalization is the process of abstracting common features from multiple classes to create
a more generalized superclass or interface.
• In OOP, generalization is often implemented through inheritance. A superclass (or base
class) contains common attributes and behaviors shared by multiple subclasses.
• The superclass is known as the base class, and the classes that inherit from it are called
derived classes. The derived classes inherit the attributes and behaviors of the base class and
can extend or override them.
• Generalization promotes code reusability by allowing developers to define common
functionality in a single place (the base class) and reuse it in multiple contexts (the derived
classes).
• Through generalization, polymorphism is achieved, allowing objects of different classes to
be treated as objects of a common base class. This simplifies code and enhances flexibility.
• For example, in a shape hierarchy, a base class "Shape" could have common attributes like
color and methods like calculateArea. Derived classes like "Circle" and "Square" would
inherit from "Shape" and provide specific implementations.
• Generalization supports abstraction by extracting essential features from specific instances
and creating a more generalized representation.
• Changes made to the common functionality in the base class automatically propagate to the
derived classes, enhancing maintainability and flexibility in the software design.

SPECIALIZATION

• Specialization is a concept in software design and object-oriented programming (OOP) that

involves creating more specific and specialized classes derived from a general or abstract
base class.
• Specialization is the process of creating more specific classes (derived or child classes) from
a general or abstract class (base or parent class).
• In OOP, specialization is often achieved through inheritance. The specialized classes inherit
attributes and behaviors from the more general base class but can also introduce new or
override existing features.
• The base class provides a common structure, and the derived classes extend or specialize it
to represent more specific entities or concepts.
• Specialization allows developers to reuse common functionality from the base class while
tailoring specific features in the derived classes. This enhances code reusability and
maintainability.
• Specialization contributes to polymorphism, where objects of the derived classes can be
treated as objects of the base class. This allows for more flexible and generalized coding.
• For example: building on the shape hierarchy example, if "Shape" is a base class,
specialization could involve creating derived classes like "Triangle" and "Rectangle" with
specific attributes and methods related to their unique characteristics.
• Specialization refines the abstraction provided by the base class by introducing details
specific to the derived classes. It allows for a more granular representation of concepts.
• Specialization enhances the flexibility of the software design, allowing for the creation of a
variety of specialized classes that can be added or modified independently. This contributes
to the scalability of the system.
AGGREGATION

• Aggregation is a form of association in which one class represents a collection or container,

and another class represents an entity or component. It denotes a "has-a" relationship.
• Aggregation is similar to composition, but with a key difference. In composition, the part (or
component) is an integral part of the whole, and the lifetimes are often linked. In
aggregation, the part can exist independently of the whole.
• Example: Consider a "Library" class that aggregates "Book" objects. Books can exist
independently, and the library can still exist even if some books are removed.
• In Unified Modeling Language (UML), aggregation is often represented by a hollow
diamond at the end of a line connecting two classes. The line points from the container class
to the contained class.
• Aggregation provides more flexibility compared to composition. The contained object can
be shared among multiple containers, and it can exist independently of any specific
container.
• Multiplicity in aggregation denotes the number of objects that can participate in the
aggregation relationship. It specifies how many instances of one class are associated with a
single instance of the other class.
• In aggregation, the lifecycle of the contained object is independent of the lifecycle of the
container. The contained object can exist, be created, or be destroyed without affecting the
container.
• Aggregation is suitable when one object is part of another but can exist independently. It is
commonly used to model relationships between classes in object-oriented systems.
• Aggregation is a useful modeling concept that allows developers to represent relationships
between objects in a way that reflects their real-world connections. It promotes code
organization, flexibility, and a clearer representation of the structure of complex systems.

RELATIONSHIPS

• In software engineering, relationships refer to the associations or connections between

different elements, such as classes, objects, or components, within a software system.
• These relationships are crucial for modeling the interactions and dependencies between
various parts of the system.
• Understanding and appropriately modeling these relationships is essential for designing
effective, maintainable, and scalable software systems.
• Here are common types of relationships:
• Association:
o Definition: Describes a bi-directional relationship between two classes, indicating that
instances of one class are connected to instances of another class.
o Example: A "Teacher" class and a "Student" class associated in a school system.
• Aggregation:
o Definition: Represents a "has-a" relationship where one class contains another class as
a part. The part can exist independently of the whole.
o Example: A "Library" class aggregating "Book" objects.
• Composition:
o Definition: Similar to aggregation but with a stronger connection. The part is an
integral component of the whole, and their lifetimes are often linked.
o Example: A "Car" class composed of "Engine" and "Wheel" classes.
• Inheritance:
o Definition: Describes an "is-a" relationship where a subclass inherits attributes and
behaviors from a superclass. It represents an "is a kind of" connection.
o Example: A "Dog" class inheriting from an "Animal" class.
• Dependency:
o Definition: Represents a relationship where one class relies on another, but it doesn't
imply ownership or a permanent connection.
o Example: A "Report" class depending on a "Database" class for data retrieval.
• Realization:
o Definition: Describes the implementation of an interface by a class. It indicates that a
class provides a concrete implementation for the methods defined in an interface.
o Example: A "PaymentGateway" class realizing a "Payment" interface.
• Association Class:
o Definition: Represents an association between two classes with additional attributes or
behaviors. It's used when the association itself has characteristics.
o Example: An association class "Enrollment" between "Student" and "Course" classes,
with attributes like "Grade."
• Multiplicity:
o Definition: Specifies the number of instances one class can be associated with another.
It indicates the cardinality of the relationship.
o Example: A "Department" class having multiple "Employee" instances.

MODULAR DESIGN – COUPLING AND COHESION

• Modular design is an approach to software design that emphasizes breaking down a system
into smaller, independent, and interchangeable modules or components.
• Two key principles in modular design are coupling and cohesion, which are crucial for
creating maintainable, scalable, and flexible systems.

COUPLING

• Coupling is a measure of the degree of dependence or interconnectedness between software

modules or components.
• It reflects how much one module knows about the inner workings or details of another.
• The goal is to achieve low coupling, promoting modular, maintainable, and flexible
software.
• Types of Coupling:
1. Content Coupling: Modules directly access or modify each other's internal details,
creating a high level of interdependence. Changes in one module can strongly impact
another. Highest level of coupling and should be avoided.
2. Common Coupling: Modules share global data or state, introducing indirect
communication. Modifications to shared data can affect multiple modules, potentially
leading to unexpected behavior.
 3. External Coupling: Modules interact through public interfaces, passing parameters.
While less tightly bound than content coupling, it still implies a strong relationship
between modules.
4. Control Coupling: One module control another by passing control flags or
parameters, influencing its behavior. Excessive control coupling can lead to increased
complexity and reduced maintainability.
5. Stamp Coupling: Modules communicate by passing composite data structures, such
as records or objects. Changes to the structure may impact multiple modules,
introducing potential dependencies.
6. Data Coupling: Modules communicate by passing simple data types through
parameters. This form of coupling promotes modular design and makes modules more
independent.
7. Loose Coupling: The ideal scenario where modules are independent, communicating
through well-defined interfaces. Changes in one module have minimal impact on
others, fostering flexibility and maintainability.
• Benefits of Low Coupling:
o Easier to modify or replace individual modules.
o Modules can be developed, tested, and maintained independently.
o Promotes reusability and scalability.

COHENSION

• In software engineering, cohesion refers to the measure of how closely the responsibilities of
a module or component are related to each other.
• It's a fundamental concept used to assess the quality of software design.
• High cohesion is desirable because it indicates that a module or component is focused and
has a well-defined purpose, while low cohesion suggests that a module is trying to do too
many unrelated things.
• Cohesion is often categorized into different types based on the nature of relationships within
a module:
 1. Functional Cohesion: Elements within a module contribute to a single well-defined
task, promoting clarity and ease of maintenance.
2. Sequential Cohesion: Tasks in a module are arranged in a specific sequence, with the
output of one task serving as the input for the next, providing a logical order of
execution.
3. Communicational Cohesion: Elements within a module are grouped based on shared
data, even if their functions are not directly related, enhancing data integrity.
4. Procedural Cohesion: Modules are organized based on the order in which tasks are
executed, potentially indicating the need for better organization of responsibilities.
5. Temporal Cohesion: Elements within a module need to be executed at the same time,
reflecting a temporal relationship rather than a functional one.
6. Logical Cohesion: Elements within a module are grouped based on a logical
relationship, though the nature of that relationship may not be immediately clear.
7. Coincidental Cohesion: Elements within a module lack a logical relationship,
indicating haphazard development or the accumulation of unrelated functionality over
time.
• Benefits of High Cohesion:
o Easier to understand and maintain.
o Changes are localized within the module.
o Promotes reusability of modules.

STUPID Principles:
STUPID is an acronym that highlights anti-patterns and poor practices to avoid in software
design:

• Singleton Abuse:
o Avoid excessive use of singleton patterns, as it can lead to global state and make the
code difficult to test and maintain.
• Tight Coupling:
 o Avoid tight coupling between classes and components, as it makes the system less
flexible and harder to modify.
• Untestability:
o Code should be designed to be easily testable. Avoid practices that hinder the ability to
write unit tests for components.
• Premature Optimization:
o Avoid optimizing code prematurely. Focus on creating a clean, maintainable design
before worrying about performance.
• Indescriptive Naming:
o Use clear and descriptive names for classes, methods, and variables to enhance code
readability and understanding.
• Duplication:
o Avoid code duplication. Reuse code where possible to minimize maintenance efforts
and improve consistency.

SOLID Principles:

SOLID is a set of five design principles aimed at creating robust, scalable, and maintainable
software:

• Single Responsibility Principle (SRP):

o A class should have only one reason to change, meaning it should have only one
responsibility or job.
• Open/Closed Principle (OCP):
o Software entities (classes, modules, functions, etc.) should be open for extension but
closed for modification. You can add new features without changing existing code.
• Liskov Substitution Principle (LSP):
o Subtypes must be substitutable for their base types without altering the correctness of
the program. In other words, derived classes should be able to replace their base
classes without affecting the program's behavior.
• Interface Segregation Principle (ISP):
 o A class should not be forced to implement interfaces it does not use. Instead of having
large, general-purpose interfaces, use smaller, specific interfaces.
• Dependency Inversion Principle (DIP):
o High-level modules should not depend on low-level modules. Both should depend on
abstractions. Additionally, abstractions should not depend on details; details should
depend on abstractions.

GRASP Principles:
GRASP (General Responsibility Assignment Software Patterns) provides nine principles to
guide the assignment of responsibilities in object-oriented design:

• Information Expert:
o Assign a responsibility to the class with the required information to fulfill that
responsibility.
• Creator:
o Assign the responsibility for creating an instance of class A to class B if one or more
of the following is true: B creates A objects, B uses the information that is necessary
to initialize A, B holds the initializing data for A.
• Controller:
o Assign the responsibility for handling system events to a controller class.
• Low Coupling:
o Assign the responsibility to avoid tight coupling between two classes.
• High Cohesion:
o Assign the responsibility to achieve high cohesion within a class.
• Polymorphism:
o Assign the responsibility to handle variations in behavior to a polymorphic operation.
• Pure Fabrication:
o Assign a fictional or artificial responsibility to a class that does not represent a concept
in the problem domain.
• Indirection:
 o Assign the responsibility for achieving indirection and location transparency to an
intermediate object.
• Protected Variations:
o Assign the responsibility for preventing variations in other parts of the system from
having an impact on the protected variations.
IMPORTANCE OF SOFTWARE QUALITY ASSURANCE

• Software quality assurance (SQA) is a methodology to ensure that the quality of the software
product complies with a predetermined set of standards.
• It is a systematic and proactive way to ensure that software processes and products meet
specified requirements and are developed with a high level of quality.
• SQA works parallel to software development, an ongoing activity applied throughout the
software development life cycle.
• SQA helps organizations to minimize defects, improve customer satisfaction, and increase
the reliability and scalability of software products.
• The importance of SQA can be highlighted in various aspects:
o Defect prevention: It is always better to prevent defects and errors in the software
product than to correct them later. The first principle of SQA emphasizes the
importance of identifying and addressing potential issues early in the software
development lifecycle. Unlike quality control, SQA focuses on fixing the root cause of
defects and errors, and not just the symptoms.
o Continuous improvement: SQA is not a one-time thing. It is more like an ongoing
process you need to integrate into your software development lifecycle. Continuous
improvement underlines the need to consistently monitor and improve the quality of
the software product.
o Stakeholder involvement: SQA must involve all stakeholders in the software
development process, including customers, developers, testers, QA team leads, and
project managers. It involves the importance of collaboration and communication
between the involved parties to ensure a smooth software development process.
o Risk-based approach: SQA must focus on identifying and addressing the most
significant risks in the software product. This principle emphasizes the importance of
prioritizing risks based on their potential impact on the software product.
SOFTWARE REVIEWS

• Software reviews are systematic evaluations of software artifacts such as code, design
documents, or requirements to identify defects, improve quality, and ensure adherence to
standards.
• Reviews can include various types, such as code reviews, design reviews, and requirements
reviews, each targeting specific aspects of the software development process.
• The primary objectives of software reviews are defect identification, knowledge sharing, and
improvement of the overall software quality.
• Participants in software reviews typically include developers, testers, and other relevant
stakeholders who collaboratively examine and discuss the software artifacts.
• Reviews provide early defect detection, knowledge transfer among team members, improved
communication, and continuous process improvement.
• Code reviews focus on examining source code for correctness, maintainability, and
adherence to coding standards. They help catch errors before they impact the entire system.
• Design reviews assess the architecture and design of the software, ensuring it aligns with
requirements, is scalable, and follows best practices.
• Requirements reviews ensure that documented requirements are clear, complete, and
feasible, helping prevent misunderstandings and scope creep.
• Formal reviews follow a structured process with defined roles and checklists, while informal
reviews are more flexible and collaborative, emphasizing discussion.
• Roles in reviews include the author (developer or document creator) and reviewers (peers or
subject matter experts), fostering a collaborative and constructive environment.
• Various tools, such as code review tools or collaborative platforms, can facilitate and
automate the review process, enhancing efficiency and documentation.
• Challenges in software reviews include scheduling constraints, potential resistance from
team members, and the need for a balance between finding defects and maintaining a
positive team culture.
• Software reviews are integral to quality assurance, fostering collaboration, knowledge
sharing, and continuous improvement throughout the software development life cycle.
TEST-DRIVEN DEVELOPMENT

• TDD is a methodology that fosters a disciplined and iterative approach to software

development, aligning coding with test creation for enhanced code quality and
maintainability.
• TDD is a software development approach where tests are written before the actual code. It
follows a cycle of "Red-Green-Refactor."
• Red-Green-Refactor Cycle:
o Red: Write a failing test that defines a new function or improvement.
o Green: Write the minimum amount of code to pass the test.
o Refactor: Refine the code without changing its behavior.
• TDD emphasizes creating automated unit tests for small, isolated pieces of code.
• TDD promotes better code quality, early defect detection, and a more modular and
maintainable codebase.
• TDD provides continuous feedback during development.
• TDD can influence the design of the software. Writing tests first often leads to more modular
and loosely coupled architectures.

UNIT TESTING

• Unit testing is a software testing technique where individual components or functions of a

software application are tested in isolation to ensure they work correctly.
• It focuses on testing the smallest testable parts of an application, often individual functions
or methods within classes.
• Unit tests are typically automated, allowing for frequent and efficient execution as part of the
development and continuous integration processes.
• Each unit test is designed to be isolated, meaning it should not depend on external factors,
databases, or other components. This ensures a controlled and predictable environment.
• The primary purpose of unit testing is to validate that each unit of the software performs as
designed, identifying and fixing defects early in the development process.
• Unit testing aligns with the Test-Driven Development (TDD) approach, where tests are
written before code, and the cycle of "Red-Green-Refactor" is followed.
• Types of Unit Testing:
o Manual
o Automated
• Workflow of Unit Testing:

• Unit Testing Techniques:

o Black Box Testing: This testing technique is used in covering the unit tests for input,
user interface, and output parts.
o White Box Testing: This technique is used in testing the functional behavior of the
system by giving the input and checking the functionality output including the internal
design structure and code of the modules.
o Gray Box Testing: This technique is used in executing the relevant test cases, test
methods, and test functions, and analyzing the code performance for the modules.
• Various testing frameworks, such as JUnit for Java, pytest for Python, and NUnit for .NET,
provide structures and utilities for writing and executing unit tests.

BLACK BOX TESTING

• Black box testing is a software testing method where the internal workings, code structure,
and implementation details of a system are not known to the tester. The focus is on testing
the system's functionality.
• Testers approach black box testing from the end user's perspective, assessing whether the
software behaves according to specified requirements.
• Test cases are designed based on the system's expected behavior, and the tester evaluates the
output generated by the system for a given set of inputs.
• Tools Used for Black Box Testing: Appium, Selenium, Applitools, HP QTP, etc.
• Black Box testing techniques:
o Syntax-Driven Testing
o Equivalence partitioning
o Boundary value analysis
o Cause effect Graphing
o Requirement-based testing
o Compatibility testing
• Black Box Testing Types:
o Functional Testing
o Regression Testing
o Nonfunctional Testing (NFT)
• Advantages of Black Box Testing:
o Ensures unbiased validation of user requirements.
o Testers do not need knowledge of internal code, facilitating independence.
o Supports end-to-end testing, simulating real user interactions.
• Disadvantages of Black Box Testing:
o Limited coverage may miss certain code paths or scenarios.
o Testers may lack insight into internal code structures and potential issues.
o Dependency on accurate and comprehensive requirement specifications.

WHITE BOX TESTING

• White box testing, also known as clear box or glass box testing, is a testing method where
the internal structure, code, and logic of the software application are known to the tester.
• Testers approach white box testing with knowledge of the internal workings of the system,
allowing them to design test cases based on the internal code structure.
• White box testing aims to achieve high code coverage, ensuring that all paths through the
code are exercised during testing.
• Tools required for White box Testing: PyUnit, Sqlmap, Nmap, Bugzilla, etc.
• White Box testing types:
 o Statement coverage
o Branch coverage
o Condition coverage
o Basis path testing
o Loop testing
• Advantages of White Box Testing:
o Provides detailed coverage of internal code paths and logic.
o Enables early detection of code-related issues and structural errors.
o Facilitates thorough unit testing for individual components.
• Disadvantages of White Box Testing:
o May not cover all possible external behaviors or user scenarios.
o Requires knowledge of internal code, limiting tester independence.
o Focus on internal logic may overlook higher-level integration issues.

VERIFICATION AND VALIDATION

Verification:

• Ensures that the software system meets specified requirements by conducting activities like
inspections, reviews, and walkthroughs throughout the development process.
• Concentrates on the development phase, checking that each development stage aligns with
the defined requirements and standards.
• Examples: Code reviews, design inspections, requirements analysis, and testing during
development constitute verification activities.

Validation:

• Ensures that the software system satisfies the user's needs and expectations by evaluating the
final product against the specified requirements.
• Primarily directed at the end of the development process, validating that the completed
software fulfills the user's requirements.
• Examples: User acceptance testing (UAT), system testing, and beta testing are examples of
validation activities, ensuring that the software meets user needs.

Key Difference between Verification and Validation:

1. Timing:
o Verification occurs during the development phase, ensuring each step complies with
specifications. Validation takes place after development to confirm the product meets
user expectations.
2. Focus:
o Verification concentrates on the process of building the software correctly, while
validation is concerned with building the correct software.
3. Type:
o Verification is static testing while validation is the dynamic testing.
4. Activities:
o Verification activities include inspections, reviews, and testing during development.
Validation activities involve user testing, acceptance testing, and system testing.
5. Documentation:
o Verification often leads to extensive documentation, ensuring that each phase adheres
to predefined standards. Validation focuses on the user experience and may involve
less formal documentation.
6. Collaboration:
o Verification requires collaboration among development teams, ensuring that everyone
follows specified processes. Validation involves collaboration with end-users,
gathering feedback to refine the software.
7. Changes and Corrections:
o During verification, changes and corrections are made to align with requirements and
standards. In validation, adjustments are made based on user feedback and real-world
usage.
8. Error Detection:
 o Verification identifies errors and issues within the development process. Validation
uncovers errors related to user expectations, functionality, and usability.
9. Iterative Nature:
o Both verification and validation can be iterative processes, with continuous refinement
based on feedback from each phase of development.
[Link]:
o Verification ensures compliance with predefined standards and specifications.
Validation checks compliance with user needs, often outlined in functional
requirements.