22CS392-SOFTWARE ENGINEERING DESIGN

UNIT-1 SOFTWARE PROCESS AND AGILE DEVELOPMENT

DESIGN:

1. Purpose: Defines the structure and interaction of software modules.

2. Focus: Specifies classes, functions, and their implementation.
3. Blueprint: Guides developers in building the system.
4. Phase: Key activity in the early stages of the Software Development Life Cycle (SDLC)

ARCHITECTURE OF ENGINEERING:

1. Purpose: Defines the high-level structure of the entire system.

2. Focus: Ensures technical and operational requirements are met.
3. Framework: Guides system quality, scalability, and maintainability.
4. Alignment: Aligns system design with organizational goals and objectives.
5. Role: Provides a foundation for long-term system sustainability.

UML (unified modelling language):

1. Definition: A standardized modelling language with integrated diagrams.

2. Purpose:

3. Specify, visualize, construct, and document software artifacts.

4. Support business modelling and non-software systems.

5. Importance: Essential in developing object-oriented software and streamlining the software

development process.
6. Notation: Primarily uses graphical representations for design clarity and communication.

IMPORTANT UML DIAGRAM:

• Use case diagram

• Class diagram
• Sequence diagram
• State transition diagram
• Collaboration diagram
• Activity diagram
• Deployment diagram
• Component diagram
1. SOFTWARE PROCESS MODEL REPERSENTATION :
2. Definition: A standardized framework or structured approach for software projects.
3. Purpose:

->Plan, develop, and maintain software effectively.

->Ensure high-quality software production.

4. Components: Defines the sequence of activities, methods, and practices.

5. Guidance: Helps organize and manage software development activities efficiently..
 22CS392-SOFTWARE ENGINEERING DESIGN

LIST THE MODEL:

• Waterfall model
• V-model (Validation and Verification Model)
• Incremental model
• RAD model (Rapid Application Development)
• Agile model
• Iterative model
• Prototype model
• Spiral model

WATERFALL MODEL:

The Waterfall Model is one of the earliest and most straightforward software development
methodologies. It is a linear and sequential approach, where each phase of the development process
flows downward like a waterfall.

Features of Waterfall Model:

1. Sequential Approach: The waterfall model involves a sequential approach to software

development, where each phase of the project is completed before moving on to the next
one.

2. Document-Driven: The waterfall model depended on documentation to ensure that the

project is well-defined and the project team is working towards a clear set of goals.

3. Quality Control: The waterfall model places a high emphasis on quality control and testing at
each phase of the project, to ensure that the final product meets the requirements and
expectations of the stakeholders.

4. Rigorous Planning: The waterfall model involves a careful planning process, where the
project scope, timelines, and deliverables are carefully defined and monitored throughout
the project lifecycle.

Phases of Waterfall Model:

1. Requirements: The first phase involves gathering requirements from stakeholders and
analyzing them to understand the scope and objectives of the project.

2. Design: Once the requirements are understood, the design phase begins. This involves
creating a detailed design document that outlines the software architecture, user interface,
and system components.

3. Development: The Development phase include implementation involves coding the

software based on the design specifications. This phase also includes unit testing to ensure
that each component of the software is working as expected.

4. Testing: In the testing phase, the software is tested as a whole to ensure that it meets the
requirements and is free from defects.

5. Deployment: Once the software has been tested and approved, it is deployed to the
production environment.
 22CS392-SOFTWARE ENGINEERING DESIGN

6. Maintenance: The final phase of the Waterfall Model is maintenance, which involves fixing
any issues that arise after the software has been deployed and ensuring that it continues to
meet the requirements over time.

Advantages of the Waterfall Model:

1. Simplicity: Easy to understand and manage due to its structured approach.

2. Clear Phases: Well-defined stages with specific deliverables at each step.

3. Documentation: Comprehensive documentation at every phase ensures clarity.

4. Works for Stable Requirements: Ideal for projects with well-defined, unchanging
requirements.

Disadvantages of the Waterfall Model

1. Inflexibility: Difficult to make changes once a phase is completed.

2. Risk-Prone: High risk of failure for complex and dynamic projects.

3. Delayed Feedback: Testing happens only after the implementation phase, potentially
leading to late discovery of critical issues.

4. Not Suitable for Iterative Work: It does not accommodate ongoing feedback or iterative
improvements.

V-MODEL (Validation and Verification Model):

The V-Model is an extension of the Waterfall Model, emphasizing verification (building the product
correctly) and validation (building the correct product). In this model, every development phase is
paired with a corresponding testing phase, forming a "V" shape when visualized.
 22CS392-SOFTWARE ENGINEERING DESIGN

Design Phase:

• Requirement Analysis: This phase contains detailed communication with the customer to
understand their requirements and expectations. This stage is known as Requirement
Gathering.

• System Design: This phase contains the system design and the complete hardware and
communication setup for developing the product.

• Architectural Design: System design is broken down further into modules taking up different
functionalities. The data transfer and communication between the internal modules and
with the outside world (other systems) is clearly understood.

• Module Design: In this phase, the system breaks down into small modules. The detailed
design of modules is specified, also known as Low-Level Design (LLD).

Testing Phases:

• Unit Testing: Unit Test Plans are developed during the module design phase. These Unit Test
Plans are executed to eliminate bugs at the code or unit level.

• Integration testing: After completion of unit testing Integration testing is performed. In

integration testing, the modules are integrated, and the system is tested. Integration testing
is performed in the Architecture design phase. This test verifies the communication of
modules among themselves.

• System Testing: System testing tests the complete application with its functionality,
interdependency, and communication. It tests the functional and non-functional
requirements of the developed application.

• User Acceptance Testing (UAT): UAT is performed in a user environment that resembles the
production environment. UAT verifies that the delivered system meets the user’s
requirement and the system is ready for use in the real world.

Industrial Challenge: As the industry has evolved, the technologies have become more complex,
increasingly faster, and forever changing, however, there remains a set of basic principles and
concepts that are as applicable today as when IT was in its infancy.

• Accurately define and refine user requirements.

• Design and build an application according to the authorized user requirements.

• Validate that the application they had built adhered to the authorized business
requirements.

Advantages of the V-Model:

1. Early Defect Detection: Testing begins in the early stages, reducing cost and effort for fixing
defects later.

2. Clear Structure: Well-defined stages and deliverables for both development and testing.

3. Improved Quality: Rigorous testing ensures a high-quality product.

4. Suitable for Critical Projects: Ideal for projects where failure is unacceptable, such as
medical or aerospace software.
 22CS392-SOFTWARE ENGINEERING DESIGN

Disadvantages of the V-Model:

1. Inflexibility: Like the Waterfall Model, it is difficult to accommodate changes once a phase is
completed.

2. High Dependency on Documentation: Relies heavily on clear, detailed documentation.

3. Not Suitable for Dynamic Requirements: Performs poorly in projects with frequently
changing requirements.

4. Time-Consuming: Testing each phase thoroughly adds to the overall project duration.

INCREMENTAL MODEL:

The Incremental Model is a software development approach where the system is developed and
delivered in small, manageable increments or modules. Each increment builds upon the previous
one until the complete system is developed. This model combines elements of both iterative and
linear development.

Phases of the Incremental Model:

1. Requirements Gathering: Identify the requirements for the increment being developed.

Only a subset of the overall system requirements is considered for each increment.

2. Design: Design the system architecture for the current increment, ensuring it integrates with
the existing increments.

3. Implementation: Develop the code for the current increment. Each increment delivers a
functional module of the software.

4. Testing: Test the increment individually and integrate it with the previous increments.
Ensures both individual module functionality and system integration.

5. Deployment: Deploy the completed increment for user feedback or production use.

6. Maintenance: Address any issues or improvements for the deployed increments.

Requirement Process Model:

Characteristics of the Incremental Model:

• Development and delivery are divided into small increments.

• Early increments provide core functionalities, with subsequent increments adding

enhancements.
 22CS392-SOFTWARE ENGINEERING DESIGN

• Testing and feedback occur after every increment.

Advantages of the Incremental Model:

1. Early Delivery: The user gets functional parts of the system early in the process.

2. Flexible: Easier to incorporate changes based on feedback during development.

3. Risk Reduction: Early increments can identify and address critical issues.

4. Cost-Effective: Only essential features are developed initially, allowing staged investment.

5. Customer Involvement: Frequent deliveries promote continuous feedback and user

engagement.

Disadvantages of the Incremental Model:

1. Requires Good Planning: Dividing requirements and prioritizing features can be challenging.

2. Integration Challenges: Combining increments may introduce integration issues.

3. Inconsistent Quality: Some increments might be more polished than others if not managed
well.

4. Time and Resource Demands: Testing and revising after each increment can extend
timelines and demand additional resources.

Example

An online shopping application might:

1. Deliver a basic shopping cart and payment system in the first increment.

2. Add features like product reviews and recommendations in subsequent increments.

3. Introduce advanced search and personalization in later increments.

RAD MODEL:

The Rapid Application Development (RAD) Model is a software development methodology that
emphasizes rapid prototyping and quick feedback over lengthy planning and development cycles. It
focuses on delivering high-quality systems in a short time frame.

Phases of the RAD Model:

 22CS392-SOFTWARE ENGINEERING DESIGN

1. Business Modelling: Understand the business objectives and identify critical information.
Define the flow of information between business processes.

2. Data Modelling: Define the data required to support the business model. The structure of
the data to ensure integrity and accessibility.

3. Process Modelling: Identify and define the processes needed to manipulate and use the
data. Define process workflows based on business rules.

4. Application Generation: Use tools and techniques (like CASE tools) to rapidly build
prototypes and functional modules. Focus on reusability and automation to accelerate
development.

5. Testing and Integration: Conduct iterative testing of prototypes and increments to identify
and resolve issues. Integrate modules into the final system for delivery.

Characteristics of the RAD Model:

• Iterative Prototyping: Involves continuous creation and refinement of prototypes.

• User Involvement: Heavy interaction with end-users to gather feedback and refine the
system.

• Rapid Development: Focus on speed through automation and reusable components.

Advantages of the RAD Model:

1. Fast Delivery: Speeds up development by focusing on prototypes and automation.

2. High User Satisfaction: Frequent user feedback ensures the final system meets user needs.

3. Flexible and Adaptable: Accommodates changes during the development process.

4. Reusable Components: Saves time by leveraging existing modules and tools.

5. Reduced Risk: Early testing and continuous feedback help identify issues early.

Disadvantages of the RAD Model:

1. Requires Skilled Teams: Success depends on experienced developers and designers.

2. High Dependency on User Involvement: Active and consistent user participation is critical.

3. Not Suitable for Large, Complex Systems: Limited to systems that can be modularized.

4. Cost of Automation Tools: Requires investment in specialized tools and technologies.

5. Time Pressure: Focus on speed can sometimes compromise quality.

Example: Developing a mobile banking application:

1. Business Modelling: Define user activities like checking account balance, transferring funds,
and paying bills.

2. Data Modelling: Identify data structures for account details, transactions, and user profiles.

3. Prototyping: Create a prototype with basic functionalities like login and view balance.
 22CS392-SOFTWARE ENGINEERING DESIGN

4. Feedback & Refinement: Incorporate user feedback for enhancements, such as adding bill
payments or investment tracking.

ITERATIVE MODEL:

The Iterative Model is a software development approach where the system is developed
incrementally, through repeated cycles (iterations). Each iteration involves planning, design,
implementation, and testing and results in a more refined version of the software until the final
product is complete.

Phases of the Iterative Model:

1. Requirement gathering & analysis: In this phase, requirements are gathered from customers and
check by an analyst whether requirements will fulfil or not. Analyst checks that need will achieve
within budget or not. After all of this, the software team skips to the next phase.

2. Design: In the design phase, team design the software by the different diagrams like Data Flow
diagram, activity diagram, class diagram, state transition diagram, etc.

3. Implementation: In the implementation, requirements are written in the coding language and
transformed into computer programmes which are called Software.

4. Testing: After completing the coding phase, software testing starts using different test methods.
There are many test methods, but the most common are white box, black box, and grey box test
methods.

5. Deployment: After completing all the phases, software is deployed to its work environment.

6. Review: In this phase, after the product deployment, review phase is performed to check the
behaviour and validity of the developed product. And if there are any error found then the process
starts again from the requirement gathering.

7. Maintenance: In the maintenance phase, after deployment of the software in the working
environment there may be some bugs, some errors or new updates are required. Maintenance
involves debugging and new addition options.

Characteristics of the Iterative Model:

• Cyclic Process: Software evolves through repeated cycles.

• Partial Deployment: Deliverables from each iteration may be functional and deployable.

• Refinement Through Feedback: Early versions improve based on user and stakeholder
feedback.
 22CS392-SOFTWARE ENGINEERING DESIGN

Advantages of the Iterative Model:

1. Early Feedback: Users and stakeholders can provide input early, improving satisfaction.

2. Risk Reduction: Issues are identified and resolved in earlier stages.

3. Flexibility: Accommodates changes in requirements throughout the development.

4. Continuous Progress: Working software is available at the end of each iteration.

5. Better Resource Management: Allows phased allocation of resources and effort.

Disadvantages of the Iterative Model:

1. Complex Planning: Requires careful iteration planning and management.

2. High Resource Demand: Needs frequent testing and review after each iteration.

3. Uncertain End Date: If iterations are not well-controlled, projects may extend indefinitely.

4. Cumulative Errors: Flaws in earlier iterations may propagate if not identified and corrected.

Example: Developing an e-commerce website:

1. Iteration 1: Implement user registration and login functionality.

2. Iteration 2: Add product catalog and search features.

3. Iteration 3: Integrate shopping cart and payment gateway.

4. Iteration 4: Introduce order tracking and user reviews.

PROTOTYPE MODEL:

The Prototype Model is a software development approach where a working prototype of the
system is built early in the development cycle. This prototype demonstrates key features and
functionality, enabling users to provide feedback before the final system is developed.

Phases of the Prototype Model:

1. Requirements Gathering and Analysis: Gather high-level and unclear requirements from
stakeholders. Focus on features critical to the prototype.
 22CS392-SOFTWARE ENGINEERING DESIGN

2. Quick Design: Create a basic design to represent the overall system structure and
functionality. Emphasis is on speed, not perfection.

3. Build Prototype: Develop a working model of the system with limited functionality. Use it to
represent the look, feel, and behave of the final product.

4. User Evaluation: Present the prototype to stakeholders for review and feedback. Collect
input on system functionality, usability, and design.

5. Refinement: Incorporate feedback into the next iteration of the prototype. Repeat the cycle
until the prototype is refined to meet user expectations.

6. System Development: Discard the prototype (or use it as a basis) and develop the final
system using the gathered requirements.

7. Testing and Maintenance: Test the final product thoroughly and provide ongoing
maintenance post-deployment.

How does a spiral model represent a process suitable to represent a real-time problem? A software
project which is considered to be very simple and the customer is positioned of keeping all the
requirements of the initial state, what process could you prefer development software project?
Explain the concept of prospective process models and specialized process models. Provide
examples of each and discuss scenarios where they are most effectively used.

Advantages of the Prototype Model:

1. Improved Requirements Clarity: Helps stakeholders visualize the system and refine unclear
requirements.

2. Early User Feedback: Incorporates user input during the development process, ensuring
satisfaction.

3. Reduced Risk: Identifies potential design or usability issues early.

4. Flexibility: Adapts to changing requirements throughout development.

5. Cost-Effective for Requirement Refinement: Saves cost by addressing issues in the early
stages.

Disadvantages of the Prototype Model:

1. Increased Cost and Time for Prototyping: Building and refining prototypes can be time-
consuming and costly.

2. Inadequate Documentation: Focus on prototyping may lead to insufficient documentation.

3. User Misunderstanding: Stakeholders might mistake the prototype for the final product.

4. Quality Issues: Prototypes are often developed quickly, which may introduce technical debt
if reused in the final system.

SPRIAL MODEL:

The Spiral Model is a software development process that combines elements of both the Iterative
Model and Risk-Driven Approach. It focuses on risk analysis and is particularly useful for large,
 22CS392-SOFTWARE ENGINEERING DESIGN

complex, and high-risk projects. The process is represented as a spiral with multiple loops, where
each loop corresponds to a development phase.

Phases of the Spiral Model:

Each loop in the spiral consists of four key phases:

1. Determine Objectives (Planning): Define the objectives, constraints, and system

requirements for the current phase. Identify alternative approaches to meet these
objectives.

2. Identify and Resolve Risks (Risk Analysis): Assess risks related to cost, time, technical
feasibility, and user satisfaction. Develop strategies to mitigate these risks, including
prototypes or simulations.

3. Development and Testing (Engineering): Build and test the system incrementally based on
the identified requirements. Develop prototypes or functional modules as needed.

4. Review and Plan the Next Iteration (Evaluation): Evaluate the results of the current phase
with stakeholders. Decide whether to proceed to the next iteration, refine the existing
system, or terminate the project.

Advantages of the Spiral Model:

1. Risk Management: Identifies and addresses risks early, reducing the likelihood of project
failure.

2. Flexibility: Adapts to evolving requirements and user feedback.

3. Improved Quality: Early risk analysis ensures a more robust final product.

4. Early Prototyping: Stakeholders can visualize and interact with the system early in the
process.

5. Customizable Approach: Each iteration can be tailored to the project's needs.

Disadvantages of the Spiral Model:

1. Complexity: Requires careful planning, management, and expertise in risk assessment.

2. High Cost: Iterative development and risk analysis can be expensive.

 22CS392-SOFTWARE ENGINEERING DESIGN

3. Not Suitable for Small Projects: The overhead may not justify the benefits for small, simple
projects.

4. Uncertain Timeline: The iterative nature makes it challenging to predict the exact
completion date.

Example: Developing a Defense system:

1. First Loop (Concept Development): Assess requirements, identify risks like technical
feasibility, and build a proof-of-concept prototype.

2. Second Loop (System Design): Develop a more detailed system design while mitigating
identified risks.

3. Third Loop (Subsystem Development): Create and test individual components.

4. Fourth Loop (System Integration): Integrate and test the complete system.

AGILE MODEL:

The Agile Model is a flexible and iterative approach to software development that focuses on
collaboration, customer feedback, and rapid delivery of small, functional increments. Agile
emphasizes adaptability to changing requirements and continuous improvement throughout the
development process.

• Scrum: serves as a framework for tackling complex projects and ensuring their successful
completion. It is led by a Scrum Master, who oversees the process, and a Product Owner,
who establishes the priorities. The Development Team, accountable for delivering the
software, is another key player.

• Extreme Programming (XP): uses specific practices like pair programming, continuous
integration, and test-driven development to achieve these goals. Extreme programming is
ideal for projects that have high levels of uncertainty and require frequent changes, as it
allows for quick adaptation to new requirements and feedback.

• Lean Development: is rooted in the principles of lean manufacturing and aims to streamline
the process by identifying and removing unnecessary steps and activities. This is achieved
through practices such as continuous improvement, visual management, and value stream
mapping, which helps in identifying areas of improvement and implementing changes
accordingly.

Steps in the Agile Model:

The agile model is a combination of iterative and incremental process models. The steps involve in
agile SDLC models are:
 22CS392-SOFTWARE ENGINEERING DESIGN

1. Requirement Gathering: In this step, the development team must gather the requirements,
by interaction with the customer. development team should plan the time and effort
needed to build the project. Based on this information you can evaluate technical and
economic feasibility.

2. Design the Requirements:- In this step, the development team will use user-flow-diagram or
high-level UML diagrams to show the working of the new features and show how they will
apply to the existing software. Wireframing and designing user interfaces are done in this
phase.

3. Construction / Iteration: In this step, development team members start working on their
project, which aims to deploy a working product.

4. Testing / Quality Assurance:- Testing involves Unit Testing, Integration Testing, and System
Testing. A brief introduction of these three tests is as follows:

• Unit Testing: Unit testing is the process of checking small pieces of code to ensure
that the individual parts of a program work properly on their own. Unit testing is
used to test individual blocks (units) of code.

• Integration Testing: Integration testing is used to identify and resolve any issues
that may arise when different units of the software are combined.

• System Testing: Goal is to ensure that the software meets the requirements of the
users and that it works correctly in all possible scenarios.

5. Deployment: In this step, the development team will deploy the working project to users.

6. Feedback: This is the last step of the Agile Model. In this, the team receives feedback about
the product and works on correcting bugs based on feedback provided by the customer.

Characteristics of the Agile Model:

Iterative and Incremental: Small, functional increments are delivered throughout the project.

User-Centric: Heavy focus on customer collaboration and feedback.

Adaptable to Change: Easily accommodates evolving requirements.

Cross-Functional Teams: Encourages teamwork and collaboration across disciplines.

Advantages of the Agile Model:

1. Faster Delivery: Early and frequent delivery of functional software.

 22CS392-SOFTWARE ENGINEERING DESIGN

2. Improved Quality: Continuous testing and feedback ensure high-quality outputs.

3. Customer Satisfaction: Close collaboration and regular updates keep stakeholders engaged.

4. Flexibility: Accommodates changing requirements at any stage of development.

5. Risk Reduction: Issues are identified and addressed early.

Disadvantages of the Agile Model:

1. Requires Active Participation: Continuous stakeholder involvement is critical.

2. Difficult to Predict: Estimating costs and timelines can be challenging.

3. Not Suitable for All Projects: Works best for projects that can be delivered incrementally.

4. Team Dependency: Success depends heavily on the skills and collaboration of the team.

5. Documentation May Be Lacking: Focus on working software often reduces documentation.

QUESTION BANK: 2mark

[Link] is the Waterfall model in software development?

[Link] the phases of the Waterfall model.

[Link] Extreme Program and Extreme process

[Link] is architecture design?

[Link] the goal of software engineering

[Link] the purpose of SDLC

[Link] an evolutionary prototype

[Link] is the Agile model?

9. Name any two Agile methodologies.

10. What is the Spiral Model in software development?

13mark

[Link] and contrast the Waterfall model with the Agile model. How do they differ in terms of
flexibility and customer involvement?

[Link] the main practice of the agile proccess .How do the process ensure the successful delivery
of the software project provide example

[Link] the key element of extreme programming (XP). How does XP ensure the quality and
success of software project .provide a detailed case study example.

4. How does a spiral model represent a process suitable to represent a real-time problem? A
software project which is considered to be very simple and the customer is position of giving all the
requirements at the initial state, what process could you prefer development software project?

[Link] the concept of prospective process models and specialized process models. Provide
examples of each and discuss scenarios where they are most effectively used
 22CS392-SOFTWARE ENGINEERING DESIGN

UNIT-2 REQUIREMENT ANALYSIS AND SPECIFICATION

REQUIREMENT:

1. Definition: A standardized framework or structured approach for software projects.

2. Purpose:

->Plan, develop, and maintain software effectively.

->Ensure high-quality software production.

3. Components: Defines the sequence of activities, methods, and practices.

4. Guidance: Helps organize and manage software development activities efficiently.

TYPES OF REQUIREMENTS:

1. Functional Requirements:

• These define the specific behavior or functions the software must perform. They describe
what the system should do.
• Example: The system must allow users to log in using their email and password.

2. Non-Functional Requirements:

• These describe the qualities or attributes the system must have, such as performance,
security, and scalability.

. Example: The system should handle 500 concurrent users without crashing.

REQUIREMENT GATHERING AND ANALYSIS:

Definition: A critical SDLC phase for collecting, analyzing, and documenting stakeholders' needs
and expectations.

2. Objectives:

• Identify and understand user and business needs.

• Ensure requirements are clear, feasible, and aligned with goals.

 22CS392-SOFTWARE ENGINEERING DESIGN

3. Process Includes:

• Requirement Collection: Engaging stakeholders to gather detailed inputs.

• Analysis: Evaluating requirements for clarity, feasibility, and prioritization.

• Documentation: Recording requirements for design and development reference.

4. Significance:

• Ensures the software meets user needs.

• Minimizes risks of rework and misaligned deliverables

Steps in Requirement Gathering and Analysis:

1. Planning the Requirement Gathering Process:

• Identify the stakeholders (customers, users, developers, business analysts, etc.).

• Define the scope of the project (which features are to be included).

• Decide on the techniques to be used for gathering the requirements (e.g., interviews,
surveys, workshops, etc.).

2. Requirement Elicitation (Gathering):

This step focuses on collecting the needs, expectations, and constraints from all stakeholders. Some
common techniques for elicitation include:

• Interviews: One-on-one discussions with stakeholders to gather detailed insights.

• Surveys/Questionnaires: Written forms used to collect responses from a large group of

users.

• Workshops: Collaborative sessions where stakeholders discuss their needs and brainstorm
ideas.

• Focus Groups: Small groups of users provide feedback on a prototype or idea.

• Observation: Observing users performing tasks to identify pain points or requirements.

• Document Analysis: Reviewing existing documentation or legacy systems to gather

requirements.

3. Requirement Documentation:

After gathering the requirements, they need to be documented in a clear, structured format.
Documentation can include:

• Functional Requirements Document (FRD): Describes the specific functionalities the system
must support.

• Non-Functional Requirements Document (NFRD): Describes performance, security, and

other quality attributes.

• Use Cases/Use Case Diagrams: Describes how the system should interact with users or
other systems.
 22CS392-SOFTWARE ENGINEERING DESIGN

• User Stories: Short, simple descriptions of how a user will interact with the system, often
used in Agile methodologies.

4. Requirement Analysis:

This phase involves reviewing the gathered requirements to:

• Ensure Consistency: Identify contradictions or ambiguities in the requirements.

• Clarify Requirements: Resolve unclear or vague requirements through discussions with

stakeholders.

• Prioritize Requirements: Determine the most critical features or constraints for the system
based on business goals.

• Feasibility Study: Assess the technical, financial, and operational feasibility of meeting the
requirements.

• Risk Analysis: Identify any potential risks that could arise in meeting the requirements and
suggest mitigation strategies.

Tools like SWOT analysis (Strengths, Weaknesses, Opportunities, Threats) or MoSCoW prioritization
(Must have, Should have, Could have, Won't have) can be helpful.

5. Requirement Validation:

Once the requirements are analyzed, it's important to validate them with the stakeholders to ensure
they are:

• Correct: They accurately reflect the needs of the users.

• Complete: All necessary requirements have been captured.

• Feasible: They can be realistically implemented.

• Traceable: It is clear where each requirement came from and how it will be tested.

• Testable: The requirements should be framed in a way that they can be tested to verify their
fullfillment.

6. Requirement Specification:

The finalized and validated requirements are documented in the Software Requirements
Specification (SRS) document. The SRS serves as a blueprint for the design and development phases
and may include:

• Introduction and purpose of the system.

• System context and scope.

• Functional and non-functional requirements.

• User interface and user experience requirements.

• External interfaces (with other systems).

• Constraints and assumptions.

 22CS392-SOFTWARE ENGINEERING DESIGN

• Acceptance criteria.

6. Requirement Review and Approval:

i. Purpose: To validate that the requirements align with stakeholder expectations and project
goals before proceeding to the next phase.
ii. Process:

Stakeholder Involvement: Engage clients, product owners, developers, and other

stakeholders for review.

Feedback Collection: Gather feedback to identify gaps, ambiguities, or inconsistencies.

Change Management: Capture, analyze, and incorporate necessary changes to refine

requirements.

iii. Outcome: Approval from all stakeholders ensures a shared understanding. A finalized and
agreed-upon requirements document, serving as the foundation for design and
development.
iv. Importance: Prevents costly changes during later stages. Aligns the development process
with stakeholder expectations.

SOFTWARE REQUIREMENT AND SPECIFICTION:

• Definition: SRS is a document that outlines both functional and non-functional

requirements for the software system.
• Components:
✓ Functional Requirements: Describes the system’s features and tasks.
✓ Non-Functional Requirements: Covers attributes like performance, security, and
scalability.
✓ System Features: Detailed list of necessary features for the system.
✓ External Interface Requirements: Specifies interactions with external systems and
components.
• Purpose:
✓ Acts as a communication bridge between customers and developers.
✓ Ensures that both functional and non-functional requirements are met.
✓ Helps avoid misunderstandings by clearly defining system behaviors.
• Importance:
✓ Serves as the formal contract between clients and developers.
✓ Basis for design, testing, and verification to ensure alignment with needs.
✓ Helps mitigate risks by identifying ambiguities early.
✓ Stakeholder Interaction: Ensures mutual understanding between developers and
clients for creating a well-defined product.

The important parts of the Software Requirements Specification (SRS) document are:

1. Functional requirements of the system

2. Non-functional requirements of the system

3. Domain requirement.

Functional Requirements:
 22CS392-SOFTWARE ENGINEERING DESIGN

The purposeful requirement part discusses the functionalities needed from the system.

❖ The system is taken into account to perform a group of high-level functions Fi. The functional
view of the system is shown in the below diagram

❖ Each function Fi of the system can be considered as a transformation of a set of input data Ii to
the corresponding set of output knowledge Oi.

The user will get some purposeful piece of labour done employing a high-level operation.

Non-functional Requirements:

Non-functional necessities accommodate the characteristics of the system which may not be
expressed as functions – like the maintainability of the system, mobility of the system, the usability
of the system, etc. Non-functional requirements may include:

1. Reliability issues

2. Accuracy of results

3. Human-computer interface issues

4. Constraints on the system implementation, etc.

Domain Requirements

Definition: Domain requirements are specific to the domain or industry in which the software
operates. They include terminology, rules, and standards relevant to that particular domain.

Examples:

• Healthcare: The software must comply with HIPAA regulations for handling patient data.

• Finance: The system should adhere to GAAP standards for financial reporting.

• E-commerce: The software should support various payment gateways like PayPal, Stripe,
and credit cards.

Components of an SRS Document:

A well-structured SRS document typically includes the following sections:

1. Introduction
 22CS392-SOFTWARE ENGINEERING DESIGN

• Purpose: States the purpose of the SRS document, the intended audience, and the system’s
intended use.

• Scope: Defines the scope of the system, including what the software will and will not do.

• Definitions, Acronyms, and Abbreviations: Provides definitions of technical terms and

abbreviations used in the document.

• References: Lists any relevant documents, standards, or other resources.

2. Overall Description

• Product Perspective: Describes the relationship of the product to other systems or products.
It provides context and explains where the software fits into the broader ecosystem.

• Product Features: High-level description of the major features of the system, broken down
into functional categories.

• User Characteristics: Describes the target users of the system, including their needs, skills,
and background.

• Assumptions and Dependencies: States any assumptions made during the requirement
gathering and design process, and external dependencies (e.g., third-party systems or
software).

3. System Features

Detailed descriptions of each system feature, typically broken down into:

• Feature Name: The name of the feature or functionality.

• Description: A brief overview of what the feature will do.

• Functional Requirements: A detailed explanation of the specific functionality, often in the

form of use cases or user stories.

• Input/Output: Defines the inputs required for the feature and the expected outputs.

• Error Handling: Describes how the system will respond to various errors related to the
feature.

• User Interface Requirements: If applicable, describes how the feature should appear to
users, such as UI design or layout.

4. External Interface Requirements

Describes how the system will interact with external systems, hardware, and users.

• User Interfaces: Describes the user interface, including screen layouts, navigation, and
controls.

• Hardware Interfaces: Describes how the system will interface with hardware, including
devices, sensors, or other equipment.

• Software Interfaces: Describes interfaces with other software systems or APIs.

• Communication Interfaces: Specifies network protocols, communication methods, or APIs

for external communication.
 22CS392-SOFTWARE ENGINEERING DESIGN

5. System Attributes

Describes the system’s non-functional requirements, which are critical to ensure the system
performs efficiently and securely.

• Performance Requirements: Specifies response times, throughput, and other performance-

related criteria.

• Security Requirements: Details the security measures, such as encryption, authentication,

and authorization.

• Reliability: Defines the system’s expected reliability, including uptime and fault tolerance.

• Maintainability: Describes how easily the system can be maintained, including updates and
bug fixes.

• Scalability: Describes how well the system can grow to accommodate future expansion or
increased load.

6. Other Requirements

• Legal and Regulatory Requirements: Specifies any legal or regulatory constraints, such as
data privacy laws (e.g., GDPR, HIPAA).

• Environmental Requirements: Describes the environmental conditions under which the

software must operate (e.g., operating systems, hardware requirements).

• Data Requirements: Specifies how the software will manage data, including storage, backup,
and retrieval mechanisms.

Advantages:

1. Clear Communication: Provides a shared understanding of the system’s functionality and

objectives among all stakeholders, reducing misunderstandings.

2. Reduces Scope Creep: Defines project boundaries, preventing unnecessary feature additions
and changes during development.

3. Foundation for Design and Development: Acts as a blueprint for developers, guiding design
and ensuring the system meets specified requirements.

4. Facilitates Quality Assurance: Serves as the basis for creating test cases and acceptance
criteria, ensuring the system meets all requirements.

5. Aids in Change Management: Tracks and manages changes to requirements, allowing the
impact of changes to be assessed and managed effectively.

Disadvantages:

1. Time-Consuming: Writing a comprehensive SRS can be time-intensive, delaying the start of

actual development work.

2. Inflexibility: Traditional SRS documents can be rigid, making it difficult to accommodate

rapid changes in dynamic environments (e.g., Agile).

3. Complexity: For large systems, the SRS can become overly detailed, difficult to review, and
overwhelming for stakeholders.
 22CS392-SOFTWARE ENGINEERING DESIGN

4. Potential Ambiguity: Misunderstandings may arise if the requirements are not written
clearly or are too vague.

5. Overemphasis on Documentation: Teams may focus too much on documentation, slowing

down development or hindering progress on actual system delivery.

FORMAL SYSTEM SPECIFICATION:

Definition: Formal System Specification is a mathematical and precise approach to defining the
behaviour, requirements, and structure of a software system.

Purpose:

• Ensures the system's design and functionality align with intended goals.

• Verifies and validates the system against requirements without ambiguity.

Components:

• Behaviour Specification: Defines how the system behaves under various conditions.

• Relationship Specification: Details interactions and relationships between system

components.

• Constraint Definition: Specifies constraints and conditions that the system must adhere to.

Key Aspects of Formal System Specification

1. Mathematical Foundation: Formal specifications are grounded in mathematical logic and

formal languages, which allow for precise and unambiguous definitions of system behavior.
This includes techniques such as algebraic specifications, finite state machines, and formal
logic.

2. Precise Definition: Unlike natural language requirements, which can be vague or ambiguous,
formal specifications are highly precise. They provide exact definitions of inputs, outputs,
state changes, and system behaviour under different conditions.

3. Verification and Validation: One of the primary benefits of formal specifications is that they
can be verified mathematically to ensure that the system's design meets the specified
requirements. Additionally, formal methods can be used to validate that the system will
function correctly under all specified conditions, reducing errors early in the design phase.

4. System Behavior Representation: Formal specifications are used to represent how the
system behaves, how different parts of the system interact, and how the system will
respond to various inputs or stimuli. This is often done using mathematical models such as
state machines, process algebra, or set theory.

5. Tool Support: Tools like theorem provers, model checkers, and formal specification
languages (e.g., Z, VDM, B-Method) support the development and analysis of formal
specifications, enabling automated checking and error detection.

Types of Formal Specification Techniques

1. Z-Notation: A widely used formal specification language based on set theory and first-order
logic. Z is used to specify data types, operations, and system behavior formally.
 22CS392-SOFTWARE ENGINEERING DESIGN

o Example: Specifying a system where a bank account maintains balance and allows
deposits and withdrawals, defined in terms of sets, relations, and functions.

2. VDM (Vienna Development Method): A formal method that uses a combination of set
theory and algebra to specify both the data and the operations of the system.

o Example: Defining the operations on a stack data structure, including push and pop
operations.

3. B-Method: A formal method used for system modeling and refinement. It allows a system to
be specified abstractly and then refined incrementally through a series of steps.

o Example: Modeling a railway control system and refining it step by step to ensure
correctness.

4. Process Algebras: Used to specify concurrent and parallel systems, providing a formal way to
represent and reason about system processes and their interactions.

o Example: Specifying how multiple processes in a multi-threaded application should

synchronize and communicate.

5. Temporal Logic: A formal specification technique used to reason about the behavior of
systems over time, often used for reactive or real-time systems.

o Example: Specifying that a system should always respond to a user request within a
specific time frame.

Advantages:

1. Unambiguous Requirements: Formal specifications eliminate vagueness by providing a

clear, mathematical representation of system requirements, ensuring precise
understanding.

2. Early Error Detection: Formal methods allow for early detection of design flaws or
inconsistencies, reducing the likelihood of defects in later stages of development.

3. Verification and Validation: Systems can be verified to ensure that the design meets the
requirements and validated to ensure correct behavior under all conditions, increasing
confidence in the system's reliability.

4. Automated Tool Support: Formal specification languages are often supported by automated
tools that assist in model checking, theorem proving, and generating code, making the
development process more efficient.

5. Improved Design Quality: The rigor and discipline of using formal methods lead to higher-
quality designs, as the system is analyzed from multiple perspectives, including safety,
performance, and reliability.

Disadvantages:

1. Complexity: Developing formal specifications requires expertise in mathematics and formal

methods, which can be challenging and time-consuming.

2. High Initial Cost: The time and effort required to create formal specifications can result in
higher upfront costs. It may not always be justified for small or less critical systems.
 22CS392-SOFTWARE ENGINEERING DESIGN

3. Limited Industry Adoption: While formal methods are beneficial in certain domains (e.g.,
critical systems), they are not widely adopted in mainstream software engineering,
particularly for non-critical applications.

4. Difficulty in Expressing Some Requirements: Some aspects of software systems, particularly

user interfaces and non-functional requirements (like usability or user experience), are
difficult to specify formally.

5. Tool Limitations: While there are powerful tools available, they can be difficult to use and
may have limitations in handling large and complex systems.

PETRINETS:

A Petri Net is a mathematical modeling language used to describe and analyze the flow of
information, processes, and systems, especially those exhibiting concurrent or parallel behavior.

Key Features:

• Concurrency: Models systems with concurrent or parallel processes.

• Flow Representation: Represents the flow of information or control between components in

a system.

• Graphical Notation: Uses places, transitions, and arcs to visually represent system behavior.

Components of a Petri Net

A Petri Net consists of the following components:

1. Places: Represent conditions or states within the system. These are typically depicted as
circles. A place can hold tokens, which indicate the state of the system.

2. Transitions: Represent events or actions that cause changes in the system's state. These are
depicted as rectangles. A transition may fire (trigger) if the necessary conditions are met.

3. Tokens: Represent the dynamic state of the system. Tokens are placed in the places and
move between them when transitions fire. The presence of tokens indicates the system's
state or the availability of resources.

4. Arcs: Arcs are directed edges that connect places to transitions and transitions to places.
They represent the flow of control or resources in the system. Arcs are depicted as arrows.

5. Marking:A marking is the distribution of tokens across the places in the Petri net,
representing the current state of the system. The marking is dynamically updated as
transitions fire.

Types of Petri Nets:

1. Basic Petri Net (Place/Transition Net): This is the simplest form of a Petri Net, consisting of
places, transitions, and arcs. It is used for basic modelling of systems where there are no
additional complexities such as priorities or time constraints.

2. Timed Petri Nets: These are Petri Nets in which transitions are associated with time delays.
Timed Petri Nets are used to model systems where the timing of events is crucial (e.g., real-
time systems).
 22CS392-SOFTWARE ENGINEERING DESIGN

3. Coloured Petri Nets: In Coloured Petri Nets, places can hold tokens of different types or
"colours". This allows Petri Nets to represent more complex systems with different data
types, adding flexibility and power to the modelling.

4. Hierarchical Petri Nets: These are used for large, complex systems by nesting Petri Nets
inside each other. They allow for modular representation of system behavior, making them
easier to manage and understand.

5. Stochastic Petri Nets: Stochastic Petri Nets incorporate probabilities and randomness in the
firing of transitions. These are particularly useful for modelling and analyzing the systems
with uncertain or variable behavior, such as queuing systems and reliability analysis.

Advantages of Petri Nets:

1. Clear Visualization: Provides an intuitive graphical representation of system behavior.

2. Concurrency Handling: Effectively models concurrent and parallel processes.

3. Formal Analysis: Allows for formal verification of system properties, such as deadlocks and
reachability.

4. Flexibility: Can be extended with time, stochastic elements, and hierarchical structures.

5. Tool Support: Availability of tools for design and automated analysis.

Disadvantages of Petri Nets:

1. Complexity in Large Systems: Can become difficult to manage and analyze for large-scale
systems.

2. Limited Expressiveness: Not ideal for systems with continuous behaviors or complex data.

3. Scalability Issues: State space can grow exponentially, leading to performance challenges.

4. Learning Curve: Requires expertise for advanced usage and formal analysis.

5. Not Always Intuitive for Non-Experts: While graphical, advanced features may be hard for
beginners to grasp.

UML (UNIFIED MODELING LANGUAGE):

The UML is a language for specifying, constructing, visualizing, and documenting the software
system and its components. The UML is a graphical language with sets of rules and semantics. The
rules and semantics of a model are expressed in English in a form known as OCL (Object Constraint
Language). OCL uses simple logic for specifying the properties of a system.

1. class diagram:
 22CS392-SOFTWARE ENGINEERING DESIGN

The UML class diagram is also known as object modeling. It is a static analysis diagram. These
diagrams show the static structure of the model. A class diagram is a connection of static model
elements, such as classes and their relationships, connected as a graph to each other and to their
contents.

Class: A class represents a blueprint for objects. It consists of three main parts:

• Name: The name of the class.

• Attributes: The data elements or properties that the class objects will have.
• Operations/Methods: The functions or behaviors that can be performed by the class or its
objects.

Attributes:

• These are the properties or fields within a class that store data. Each attribute has a visibility
(public, private, protected), a name, and a type.

• Example: age: int, name: string.

Methods/Operations:

• These represent the actions or behaviors the class can perform. Methods are represented
with their names, parameters, and return types.

• Example: getAge(): int, setName(name: string): void.

Visibility Modifiers:

• Public (+): Visible to all classes.

• Private (-): Visible only within the class.

• Protected (#): Visible within the class and subclasses.

• Package (~): Visible within the package.

Associations:

• These represent relationships between classes, often shown as a line connecting two
classes.

• Multiplicity: Indicates how many instances of one class can be associated with instances of
another class (e.g., 1,* for one-to-many).

[Link]-case diagram:
 22CS392-SOFTWARE ENGINEERING DESIGN

The functionality of a system can be described in a number of different use-cases, each of which
represents a specific flow of events in a system. It is a graph of actors, a set of use-cases enclosed in
a boundary, communication, associations between the actors and the use-cases, and generalization
among the use-cases.

[Link] diagram:

It is a dynamic model unlike all the others mentioned before. The objects of an object oriented
system are not static and are not easily understood by static diagrams. The behavior of the class’s
instance (an object) is represented in this diagram. Every use-case of the system has an associated
behavior diagram that indicates the behavior of the object. In conjunction with the use-case diagram
we may provide a script or interaction diagram to show a time line of events. It consists of sequence
and collaboration diagrams.

[Link] diagram:

It is the combination of sequence and collaboration diagram. It is used to depict the flow of events in
the system over a timeline. The interaction diagram is a dynamic model which shows how the
system behaves during dynamic execution.

[Link] chart diagram:

 22CS392-SOFTWARE ENGINEERING DESIGN

It consists of state, events and activities. State diagrams are a familiar technique to describe the
behavior of a system. They describe all of the possible states that a particular object can get into and
how the object's state changes as a result of events that reach the object. In most OO techniques,
state diagrams are drawn for a single class to show the lifetime behavior of a single object

[Link] diagram:

It shows organization and their dependence among the set of components. These diagrams are
particularly useful in connection with workflow and in describing behavior that has a lot of parallel
processing. An activity is a state of doing something: either a real-world process, or the execution of
a software routine.

[Link] diagram:

It shows the implementation phase of the systems development, such as the source code structure
and the run-time implementation structure. These are relatively simple high level diagrams
compared to the others seen so far. They are of two sub-diagrams, the component diagram and the
deployment diagram.

[Link] diagram:
 22CS392-SOFTWARE ENGINEERING DESIGN

These are organizational parts of a UML model. These are boxes to which a model can be
decomposed. They show the structure of the code itself. They model the physical components such
as source code, user interface in a design. It is similar to the concept of packages.

[Link] diagram:

The deployment diagram shows the structure of the runtime system. It shows the configuration of
runtime processing elements and the software components that live in them. They are usually used
in conjunction with deployment diagrams to show how physical modules of code are distributed on
the system.

[Link] diagram

Package Diagrams to depict how packages and their elements have been organized. A package
diagram simply shows us the dependencies between different packages and internal composition of
packages.

• Packages help us to organise UML diagrams into meaningful groups and make the diagram
easy to understand.

• They are primarily used to organise class and use case diagrams.
 22CS392-SOFTWARE ENGINEERING DESIGN

Object diagram:

An Object Diagram can be referred to as a screenshot of the instances in a system and the
relationship that exists between them. Since object diagrams depict behaviour when objects have
been instantiated, we are able to study the behaviour of the system at a particular instant.

• An object diagram is similar to a class diagram except it shows the instances of classes in the
system.

• We depict actual classifiers and their relationships making the use of class diagrams.

• On the other hand, an Object Diagram represents specific instances of classes and
relationships between them at a point of time.

QUESTION BANK:

2mark:

[Link] between dataflow and state chart diagram.

[Link] are the various type of UML diagram.

[Link] are case tool?

[Link] the application of Petri nets.

[Link] distinct steps for requirements engineering process.

[Link] SRS.

[Link] between functional and non-functional requirements.

[Link] requirements.

9. Explain what a multiplicity constraint is in a class diagram.

10. What is the purpose of an association in a class diagram?

13mark:

1. Discuss the key principles of software engineering. How do these principles guide the software
engineering development process?

[Link] the use case and class diagram. Draw use case diagram and class diagram for airline
reservation.

3. Explain activity diagram and interaction diagram and draw activity and interaction diagram for
ATM reservation.

[Link] how petri net can be used model and analysed the behaviour of concurrent system with
suitable example.

5. Explain the functional and nonfunctional requirement with the suitable case studies and create
SRS for password automation system it should be triple template.

[Link] SRS (software requirements system) with suitable scenario

based example
 22CS392-SOFTWARE ENGINEERING DESIGN

UNIT-3 SOFTWARE DESIGN

Software design:

Software design is the process of envisioning and planning the architecture, components, and
interactions of a software system. It involves creating a detailed blueprint or model of the software's
structure, behavior, and user interface.

Key Aspects of Software Design:

1. Architecture: Defines the overall structure and organization of the software system.

2. Components: Identifies the individual parts or modules that make up the software system.

3. Interfaces: Specifies how components interact with each other and with users.

4. Data Structures: Defines how data is organized, stored, and manipulated.

5. Algorithms: Specifies the step-by-step procedures for solving problems or performing tasks.

Objectives of Software Design

1. Maintainability: Design software that is easy to modify, update, and repair.

2. Scalability: Create software that can adapt to growing demands and changing requirements.

3. Usability: Design software that is intuitive, user-friendly, and provides a positive user experience.

4. Performance: Optimize software for efficient use of resources, fast execution, and reliable
operation.

5. Security: Design software that protects against unauthorized access, data breaches, and other
security threats.

6. Flexibility: Create software that can accommodate changing requirements, new features, and
evolving technologies.

7. Reusability: Design software components that can be reused in other applications, reducing
development time and costs.

8. Testability: Create software that is easy to test, debug, and validate, ensuring reliability and quality.

Software Design Concepts:

Abstraction

❖ Definition: Representing complex systems in a simplified way, exposing essential features while
hiding implementation details.
❖ Goals:

Reduce complexity

- Improve modularity

- Enhance reusability

- Facilitate communication
 22CS392-SOFTWARE ENGINEERING DESIGN

❖ Techniques:

- Data Abstraction

- Object-Oriented Abstraction

Encapsulation:

❖ Definition: Bundling data and methods that operate on that data within a single unit, controlling
access and modifications.
❖ Goals:

- Hide implementation details

- Protect data from external interference

- Improve code organization and structure

- Enhance security

❖ Techniques:

- Data Hiding

- Access Modifiers (public, private, protected)

- Encapsulating Data and Behavior

Refactoring

❖ Definition: The process of restructuring existing code without changing its external behavior.
❖ Goals: Improve code readability, reduce complexity, and enhance maintainability.
❖ Techniques: Rename variables/methods, extract methods, consolidate duplicate code, and
simplify conditional statements.

Information Hiding

❖ Definition: The principle of hiding internal implementation details of a module or class from the
outside world.
❖ Goals: Reduce coupling, increase encapsulation, and improve code modularity.
❖ Techniques: Use access modifiers (public, private, protected), encapsulate data, and avoid
exposing internal implementation details.

Refinement

❖ Definition: The process of transforming a high-level design into a more detailed and specific
implementation.
❖ Goals: Gradually add more detail and precision to the design, ensuring it meets the requirements.
❖ Techniques: Decompose high-level components into smaller ones, define interfaces, and specify
data structures.
Architecture
❖ Definition: The high-level structure and organization of a software system.
❖ Goals: Provide a framework for understanding the system's components, interactions, and overall
behavior.
❖ Techniques: Define the system's overall structure, identify key components, and specify how they
interact.
 22CS392-SOFTWARE ENGINEERING DESIGN

Patterns

➢ Definition: Reusable solutions to common design problems.

➢ Goals: Provide proven and tested solutions to recurring design challenges.
➢ Types: Creational, structural, and behavioral patterns

Software Design Process:

1. Requirement Analysis

Gathering and documenting software requirements through stakeholder interviews, surveys, and
observations to understand the problem, goals, and constraints.

2. System Architecture Design

Defining the overall structure and organization of the software system, including components,
interactions, and data flow.

3. Detailed Design

Creating a detailed, formal specification of the software's components, interfaces, and data
structures, including algorithms and data types.

4. Interface Design

Designing user interfaces, APIs, and other interfaces to ensure usability, accessibility, and seamless
interactions between components.

5. Database Design

Defining the structure and organization of the database, including schema, tables, relationships, and
data normalization.

6. Algorithm Design

Developing efficient, effective, and scalable algorithms to solve specific problems or perform complex
tasks.

7. Prototyping

Creating a preliminary version of the software to test assumptions, validate requirements, and gather
feedback from stakeholders.

[Link] Strategy Design:

Developing a comprehensive testing plan, including test cases, test data, and test environments, to
ensure the software meets requirements and works correctly.

[Link] Review and Iteration:

Reviewing and refining software documentation, including requirements, design documents, and user
manuals, to ensure accuracy, completeness, and clarity.

Coupling:

Coupling refers to the degree of interdependence or connection between two or more modules,
classes, or components in a software system. It measures how closely these modules rely on each
other's functionality, data or behaviour.
 22CS392-SOFTWARE ENGINEERING DESIGN

Cohesion:

Cohesion refers to the degree of unity, coherence, and logical consistency within a single module,
class, or component in a software system. It measures how well the elements within a module work
together to achieve a single, well-defined goal or responsibility.

Pattern Format

A pattern is a reusable solution to a common problem that follows a specific structure. This structure
consists of three essential elements:

❖ Context:

- Description of the situation or environment in which the problem arises.

- Provides background information and sets the stage for the problem.

- Helps readers understand when and where the pattern is applicable.

❖ Problem:

- Statement of the problem or challenge that needs to be addressed.

- Clearly articulates the issue, its consequences, and the need for a solution.

- Provides a clear understanding of what the pattern aims to solve.

❖ Solution

- Description of the solution or approach that resolves the problem.

- Presents a proven and tested solution that addresses the problem.

- Provides guidance on how to implement the solution, including any trade-offs or considerations.

Layer Pattern:

❖ Context

A complex system requires organization and separation of concerns to ensure maintainability,

scalability, and reusability.

❖ Solution

Divide the system into distinct layers, each with a specific responsibility and interface. Each layer
communicates only with adjacent layers, ensuring separation of concerns and reducing complexity.

❖ Benefits

- Improved maintainability and scalability

- Enhanced reusability and modularity

- Simplified communication and data exchange between components

Common Layers:

- Presentation Layer (User Interface)

- Application Layer (Business Logic)

 22CS392-SOFTWARE ENGINEERING DESIGN

- Data Access Layer (Database Interaction)

-Infrastructure Layer (Networking, Security)

Broker Pattern:

❖ Context

A system requires communication and data exchange between multiple components or services, but
direct communication is impractical or inefficient.

❖ Problem
How to enable communication and data exchange between multiple components or services
without requiring direct connections between them.
❖ Solution:

Introduce a Broker component that acts as an intermediary between the components or

services. The Broker receives requests from components, performs any necessary processing or
routing, and sends responses back to the requesting components.

- Decouples components from each other

- Improves scalability and flexibility

- Simplifies communication and data exchange

Broker Responsibilities

- Receive and process requests

- Route requests to appropriate components

- Manage component registration and lookup

- Handle errors and exceptions

 22CS392-SOFTWARE ENGINEERING DESIGN

Model-View-Controller:

Context:

A software application requires a clear separation of concerns between its data, user interface, and
business logic to ensure maintainability, scalability, and reusability.

Problem:

How to separate the application's data, user interface, and business logic into distinct components,
while ensuring they work together seamlessly

Solution:

Divide the application into three interconnected components:

- Model: Represents the application's data and business logic.

- View: Handles the user interface and presentation layer.

- Controller: Acts as an intermediary between the Model and View, receiving input, updating the
Model, and updating the View.

Benefits:

- Separation of concerns

- Improved maintainability and scalability

- Enhanced reusability and flexibility

Responsibilities:

- Model: Manages data, performs calculations, and enforces business rules.

- View: Renders the user interface, displays data, and handles user input.

- Controller: Receives input, updates the Model, and updates the View.
 22CS392-SOFTWARE ENGINEERING DESIGN

Publisher-Subscriber pattern:

Context:

A system requires notification of events or changes to multiple components or services, without

having a direct dependency between them.

Problem:

How to notify multiple components or services of events or changes without tight coupling and
without the publisher needing to know about the subscribers.

Solution:

- Publisher: Publishes events or notifications without knowing who the subscribers are.

- Subscriber: Subscribes to receive events or notifications from the publisher without knowing about
other subscribers.

- Event/Notification: The message or data being published.

Benefits:

- Decouples publishers from subscribers

- Allows for dynamic subscription and unsubscription

- Scalable and flexible

Responsibilities:

- Publisher: Publishes events or notifications

- Subscriber: Subscribes to receive events or notifications

- Event/Notification: Carries the message or data being published

 22CS392-SOFTWARE ENGINEERING DESIGN

Pipe and Filter:

❖ Context:

A system requires processing of data through a series of transformations or operations, where each
operation depends on the output of the previous one.

❖ Problem

How to structure the processing of data through multiple transformations or operations, while
allowing for flexibility, reusability, and scalability

❖ Solution
▪ Pipe and Filter architecture:

- Filters: Perform specific transformations or operations on the data.

- Pipes: Connect filters together, allowing data to flow from one filter to the next.

❖ Flexible and reusable processing architecture:

- Scalable and modular design

- Easy to add or remove filters

❖ Responsibilities:

- Filters: Perform specific transformations or operations on the data.

- Pipes: Connect filters together, managing data flow.

 22CS392-SOFTWARE ENGINEERING DESIGN

Peer-to-Peer (P2P) pattern:

❖ Context:

A distributed system requires equal participants to share resources, communicate, and cooperate
without relying on a centralized authority.

❖ Problem:
How to design a system where equal participants can interact, share resources, and provide
services to each other without a central controller

Solution:

Implement a Peer-to-Peer architecture where:

- Peers: Equal participants that act as both clients and servers.

- Overlay Network: A logical network connecting peers, enabling communication and resource sharing.

❖ Benefits

- Decentralized and autonomous operation

- Improved scalability and fault tolerance

- Enhanced resource utilization and sharing

❖ Responsibilities:

- Peers: Provide and consume services, share resources, and participate in the overlay network.

- Overlay Network: Manages peer connections, enables communication, and facilitates resource
discovery.

Service-Oriented-Architecture:

❖ Context:

A complex system requires integration of multiple services, applications, and data sources to provide
a unified and flexible solution.

❖ Problem:

How to design a system that integrates multiple services, applications, and data sources in a flexible,
scalable, and maintainable way

❖ Solution:

Implement a Service-Oriented Architecture (SOA) where:

- Services: Loosely coupled, reusable, and autonomous components that provide specific business
functionalities.

- Service Interfaces: Well-defined contracts that specify how services interact with each other.

- Service Bus: An infrastructure that enables service communication, mediation, and management.
 22CS392-SOFTWARE ENGINEERING DESIGN

Benefits:

- Improved flexibility and scalability

- Enhanced reusability and maintainability

- Simplified integration and interoperability

Responsibilities:

- Services: Provide specific business functionalities and interact with other services through interfaces.

- Service Interfaces: Define the contracts for service interactions.

- Service Bus: Enables service communication, mediation, and management.

Client-Server pattern :

❖ Context

A system requires separation of concerns between the user interface and data processing, with
multiple users accessing shared resources.

❖ Problem

How to design a system that separates the user interface and data processing, allowing multiple users
to access shared resources efficiently?

❖ Solution:

Implement a Client-Server architecture where:

- Client: Requests services or resources from the server, handling user input and displaying results.

- Server: Provides services or resources to clients, managing data storage, processing, and security.

Benefits

- Scalable and efficient resource sharing

- Improved security and data management

 22CS392-SOFTWARE ENGINEERING DESIGN

- Enhanced user experience and flexibility

Responsibilities

- Client: Sends requests to the server, receives responses, and handles user interactions.

- Server: Receives requests, processes data, and sends responses back to clients.

Shared Data pattern :

❖ Context:

Multiple components or processes require access to common data, but maintaining multiple copies
of the data is inefficient or impractical.

❖ Problem:

How to provide multiple components or processes with access to common data, ensuring consistency
and efficiency?

❖ Solution:

Implement a Shared Data architecture where:

- Shared Data Repository: A centralized store holding the shared data.

- Access Mechanism: A controlled interface for components or processes to access and update the
shared data.

Benefits

- Improved data consistency and integrity

- Reduced data duplication and storage needs

- Enhanced collaboration and communication between components

Responsibilities

- Shared Data Repository: Stores and manages the shared data.

- Access Mechanism: Regulates access to the shared data, ensuring consistency and integrity.
 22CS392-SOFTWARE ENGINEERING DESIGN

Map Reduce pattern:

Context:

Large-scale data processing requires efficient and scalable methods to handle vast amounts of data.

Problem:

How to process and analyze large datasets efficiently, handling tasks such as data filtering,
aggregation, and transformation?

Solution:

Implement a MapReduce architecture where:

- Map Phase: Breaks down the data into smaller chunks, processing each chunk in parallel to produce
intermediate results.

- Reduce Phase: Aggregates and combines the intermediate results from the map phase, producing
the final output.

Benefits

- Scalable and efficient processing of large datasets

- Flexible and adaptable to various data processing tasks

- Fault-tolerant and resilient to node failures

Responsibilities

- Map Phase: Processes data chunks in parallel, producing intermediate results.

- Reduce Phase: Aggregates and combines intermediate results, producing the final output.
 22CS392-SOFTWARE ENGINEERING DESIGN

Multi-Tier pattern :

Context:

Complex applications require separation of concerns, scalability, and maintainability to handle

multiple user requests and data processing.

Problem:

How to design an application that separates presentation, application logic, and data storage, while
ensuring scalability, maintainability, and reusability?

Solution:

Implement a Multi-Tier architecture where:

- Presentation Tier: Handles user interface and user experience.

- Application Tier: Manages business logic, rules, and processes.

- Data Tier: Stores and manages data, ensuring data integrity and security.

Benefits

- Scalable and maintainable architecture

- Separation of concerns for easier development and updates

- Improved security and data integrity

Responsibilities

- Presentation Tier: Handles user input, displays output, and manages user sessions.

- Application Tier: Executes business logic, validates data, and manages transactions.

- Data Tier: Stores, retrieves, and manages data, ensuring data consistency and security.
 22CS392-SOFTWARE ENGINEERING DESIGN

Difference between Patterns and Tactics

Patterns

Patterns are general, reusable solutions to common design problems. They provide a high-level
description of a design structure, including the components, their relationships, and the forces that
shape the design.

Tactics

Tactics, on the other hand, are smaller, more focused design decisions that address specific concerns
or forces in a design. Tactics are often used to implement patterns or to address specific issues within
a pattern.

Relationship between Tactics and Patterns

The relationship between tactics and patterns can be summarized as follows:

1. Patterns provide context for tactics: Patterns define the overall design structure, and tactics are
used to implement specific aspects of that structure.

2. Tactics implement patterns: Tactics are used to flesh out the details of a pattern, addressing specific
concerns or forces in the design.

3. Tactics can be combined to form patterns: Multiple tactics can be combined to create a pattern,
providing a more comprehensive solution to a design problem.

4. Patterns can be refined using tactics: As a design evolves, tactics can be used to refine and improve
the pattern, addressing new concerns or forces that arise.

Example: To illustrate the relationship between tactics and patterns, consider the example of a web
application that uses the Model-View-Controller (MVC) pattern.

- The MVC pattern provides the overall design structure, separating the application logic into three
interconnected components.

- Tactics, such as using dependency injection to manage dependencies between components, can be
used to implement specific aspects of the MVC pattern.
 22CS392-SOFTWARE ENGINEERING DESIGN

- Another tactic, such as using a templating engine to separate presentation logic from application
logic, can be used to refine the MVC pattern and improve the separation of concerns.

QUESTION BANK:

2marks:

1. What is the primary goal of software design?

2. Which software design pattern is used to separate an object's abstraction from its implementation?

3. What is the purpose of encapsulation in software design?

4. Which software design principle emphasizes separating concerns to reduce coupling?

5. What is the difference between a class and an object in software design?

6. Which software design pattern is used to manage dependencies between objects?

7. What is the purpose of abstraction in software design?

8. Which software design principle emphasizes making software entities open for extension but closed
for modification?

9. What is the difference between inheritance and composition in software design?

10. Which software design pattern is used to create a single instance of a class?

13marks:

1. Describe the Model-View-Controller (MVC) architecture pattern. Explain its components,

interactions, and benefits. How does it separate concerns and improve maintainability?

2. Compare and contrast the Monolithic Architecture and Microservices Architecture patterns. Discuss
their advantages, disadvantages, and suitability for different types of applications.

3. Explain the concept of Separation of Concerns (SoC) in software design. Describe how SoC is
achieved through modularization, encapsulation, and abstraction. Provide examples of SoC in real-
world applications.

4. Describe the Singleton design pattern. Explain its purpose, structure, and benefits. Discuss potential
drawbacks and alternatives to the Singleton pattern. Provide an example of using the Singleton
pattern in a real-world application.

[Link] a client-server architecture for the online banking system, including the following:

- Describe the roles and responsibilities of the client and server.

- Explain how the client and server will communicate with each other.

- Discuss the security measures that will be implemented to protect customer data.

- Describe how the system will handle scalability and performance issues.

6. Explain the concept of loose coupling in software design. Describe how loose coupling is achieved
through interfaces, abstraction, and dependency injection. Provide examples of loose coupling in real-
world applications, including the use of architecture patterns such as Service-Oriented Architecture
(SOA).
 22CS392-SOFTWARE ENGINEERING DESIGN

Unit-4 SOFTWARE TESTING AND MAINTENANCE

Quality

• Definition: Degree of excellence of a product, service, or process.

• Focus: Meeting customer expectations and specifications.

• Key Aspects: Functionality, performance, reliability, security.

Some aspects of software quality:

[Link] quality:

how well software meets its functional requirements and specification.

[Link] quality:

how well the software meets its structural/non-functional requirements such as row worthness and
maintainability.

[Link]:

it is the quality term which says how consistent, how available, for tolerant, for requirable.

It relates the 3 quality dimensions characteristics

Consistency
Availability
For tolerant
Requirable

Quality Assurance (QA):

• Definition: Proactive process to prevent defects.

• Deals with “or we doing the right thing”.

• Focus: Ensuring processes are followed to improve product quality.

• Goal: Prevent defects before they occur.

• Activities: Process audits, standards implementation, training.

Quality Control (QC):

• Definition: Reactive process to identify defects in the finished product.

• Deals with ”did wedoing the right thing”.

• Focus: Finding and fixing defects after development.

• Goal: Detect and correct issues in the product.

• Activities: Testing, inspection, bug fixing.

 22CS392-SOFTWARE ENGINEERING DESIGN

QUALITY IN SOFTWARE DEFECT:

Software defect is a flaw, error on failure in the computer program that causes it to produce an
incorrect (or) unexpected way.

SOME OF THE TESTING TYPES:

1. Unit Testing:

• Definition: Testing individual components or functions of a software application in isolation.

• Purpose: Ensures that each unit of the software performs as expected.

• Focus: Inputs and outputs of a single module.

• Example: Testing a function that calculates the sum of two numbers.

2. Integration Testing:

• Definition: Testing the interaction between integrated modules or components. In other

words, Integration testing tests the quality of the module.

• Purpose: Ensures that combined modules work together correctly.

• Focus: Data flow and interaction between components.

• Example: Verifying if a login module communicates properly with a user database.

3. System Testing:

• Definition: Testing the entire system as a whole in an end-to-end environment. It checks both
functional and non-functional requirements.

• Purpose: Ensures that the complete system meets specified requirements.

• Focus: Overall system functionality and behavior.

• Example: Testing an e-commerce website's workflow, from product selection to checkout.

4. Regression Testing:

• Definition: Re-testing the software after modifications to ensure that new changes have not
introduced errors.

• Purpose: Maintains software stability after updates or bug fixes.

• Focus: Previously tested functionality and new updates.

• Example: Re-running test cases after fixing a payment gateway bug to ensure all other
functionalities remain unaffected.
 22CS392-SOFTWARE ENGINEERING DESIGN

AN EXAMPLE TO EXPLAIN ALL THE 4 TESTING:

Example Scenario: E-Commerce Website Development

Unit Testing Example

• Scenario: Testing the "Add to Cart" function.

• Explanation:
The "Add to Cart" function should correctly add a product to the cart when the user clicks the
button. During unit testing:

o Input: Product ID (e.g., P123) and quantity (2).

o Expected Output: The cart reflects the product P123 with a quantity of 2.
Unit testing ensures this function works in isolation without involving the rest of the
system.

Integration Testing Example

• Scenario: Testing the interaction between the "Add to Cart" module and the "Cart Database."

• Explanation:
After adding an item to the cart, the system must store the updated cart details in the
database. Integration testing ensures:

o The "Add to Cart" module sends the correct data to the database.

o The database updates accurately and retrieves the cart details when requested.
This test checks the interaction between these two components.

System Testing Example:

• Scenario: Testing the complete checkout process.

• Explanation:
The entire workflow, from adding items to the cart to placing an order, is tested. Steps include:

o Adding products to the cart.

o Logging in or registering a new user.

o Choosing a delivery address.

o Making a payment via a payment gateway.

System testing ensures the entire e-commerce system works as intended in an
integrated environment.
 22CS392-SOFTWARE ENGINEERING DESIGN

Regression Testing Example:

• Scenario: A bug in the payment gateway is fixed, and regression testing is performed.

• Explanation:
After fixing the payment bug, regression testing is conducted to ensure:

o The bug fix works as expected.

o Other features like "Add to Cart," "Product Search," and "Checkout" are unaffected
by the changes.
Test cases for previously tested functionalities are re-executed to ensure system
stability.

DIFFERENCE BETWEEN TESTING AND DEBUGGING:

Aspect Testing Debugging

The process of identifying defects The process of diagnosing, locating, and fixing
Definition
or issues in software. defects.

To detect errors or bugs in To analyze and resolve the cause of detected

Objective
the application. errors.

When Done during the verification phase

Done after testing when defects are identified.
Performed to ensure correctness.

Focus Focuses on finding bugs. Focuses on fixing bugs.

Responsibility Often performed by testers. Primarily performed by developers.

Testing tools like Selenium, Debugging tools like GDB, Chrome DevTools, or
Tools Used
JUnit, or Postman. IDE debuggers.

Test reports highlighting defects Fixed software where the identified bugs are
Outcome
or bugs. resolved.

Running a test case to find if Analyzing code to resolve why the login feature
Example
a login feature fails. fails.

SYMBOLIC EXECUTION:
 22CS392-SOFTWARE ENGINEERING DESIGN

Symbiotic execution is a software testing technique that generates test data to improve software
quality.

Steps Involved:

• Path Selection: Identify paths exercised by a specific set of data values.

• Program Execution: Execute the program with actual data and analyze the output.
• Symbolic Data Replacement: Replace actual data with symbolic values (expressions), one for
each output variable.

Example:

• Applications like processing personal location data or string operations, e.g., processing
names of three individuals.

Results:

• Generates program data and control flow (inputs).

• Identifies decision points, assignments, and loops from the entry point to all assignments and
branches.

Applications:

• Useful in decision-making programs, string processing, and complex control flow testing.
[Link] data generation
[Link] Analysis
[Link] Domain checking
[Link] debugging.

PROGRAM ANALYSIS:

• Definition: Examination of program code to understand behavior, detect issues, and ensure it
meets requirements.
• Types:
o Static Analysis: Examines code without running it (e.g., syntax errors, unused code).
o Dynamic Analysis: Examines code during execution (e.g., memory usage,
performance).
o Control Flow Analysis: Analyzes the flow of program execution.
o Data Flow Analysis: Examines how data moves through the program.
o Symbolic Execution: Uses symbolic values to explore execution paths.
• Purpose:
o Detect bugs, improve performance, enhance security, and ensure correctness.

MODEL CHECKING IN SOFTWARE TESTING:

Definition:

A formal verification method to ensure a system's design meets its specifications by exhaustively
exploring all possible states.

Key Steps:

1. Model Creation:

✓ Represent the system using finite-state models (e.g., state machines).

 22CS392-SOFTWARE ENGINEERING DESIGN

✓ A Mathematical representation of system behaviour of graphical picture.

✓ Example: Dell Laptop company.

2. Specification:

✓ Define properties in temporal logic (e.g., safety, liveness).

✓ A High-level prescription of system’s desired property.
✓ Example:Mobile(frontside:soft side,backside:hardside with cameras).

3. Verification: Use tools (e.g., SPIN, NuSMV) to check if the model satisfies specifications.

4. Counter example (or) exception case: Generate error traces if a property fails.

Goals:

• Safety: Ensure no bad states.

✓ e.g., "The door doesn't open while moving".

• Liveness: Guarantee good events occur.

✓ e.g., "All floor requests are serviced".

Advantages:

• Exhaustive verification.

• Automated error detection.

• Generates counterexamples for debugging.

Challenges:

• State explosion problem.

• Scalability for large systems.

Case Study: Elevator Control System

1. Model: States like Door Open, Door Closed, Moving Up/Down.

2. Specifications:

o Safety: "Door stays closed while moving."

o Liveness: "Every floor request is serviced."

3. Results:

o Detect issues like deadlocks or safety violations.

o Use counterexamples to fix and improve system logic.

BLACK BOX TESTING vs WHITE BOX TESTING:

Black Box Testing:

• Blackbox testing is also called as closed box testing and consumes less time.
 22CS392-SOFTWARE ENGINEERING DESIGN

• Focuses on testing system functionality without knowledge of internal code.

• Black Box Testing is a type of software testing where the tester focuses on the functionality of
the application without considering its internal workings, code structure, or implementation
details.

• Purpose:

✓ Implementation testing
✓ Specification testing
✓ Requirement testing
✓ Functionality testing

• Based on input-output behaviour and system requirements.

• The tester focuses on the input and output of the software.

• The categories of black box testing are

✓ System testing
✓ Acceptance testing
✓ Regression testing

• Techniques:

o Equivalence Partitioning

o Boundary Value Analysis

o Decision Table Testing

• Performed by testers or end-users.

• The scope for the testing is at functional level.

• The implementation of code is not needed.

• Blackbox does not checks the algorithms, patterns , other infos.

• Need to familiar with error testing.

• Done based on SRS.

• Tools: Selenium, QTP, Postman.

• Example: Testing login by entering valid/invalid credentials, searching in google.

• Advantages:

o No coding knowledge required.

o Effective for user perspective testing.

• Disadvantages:

o Limited code coverage.

o May miss logical bugs.

 22CS392-SOFTWARE ENGINEERING DESIGN

White Box Testing:

• Whitebox testing is also known as glass box testing or sphere box testing or structural testing.

• It is also referred as transparent testing or open-box testing.

• Whitebox testing is a type of testing in which it is aimed to analys e the internal structure
[array, queue] such as data structures, design and design patterns and code structure [for
loop, while, if].

• Purpose:

✓ Unit testing
✓ Integration testing
✓ regression testing

• Involves testing the internal structure, logic, and code paths.

• The scope of the testingis at the unit level, intergration level and system level.

• Requires understanding of code implementation.

• Done based on the detailed design document.

• Knowledge of programming is required.

• Whitebox checks the algorithms,patterns,other infos.

• Need to be familiar with data domain,inner and internal boundaries,

• Need sql and query language.

• Techniques:

o Statement Coverage

o Branch Coverage

o Path Coverage

• Performed by developers or software engineers.

• Tools: JUnit, NUnit, Code Coverage tools like Cobertura.

• Example: Verifying login code logic for input validation.

• Advantages:

o Ensures high code quality.

o Finds logical and structural bugs.

• Disadvantages:

o Time-consuming.

o Requires access to code and technical expertise.

Summary:
 22CS392-SOFTWARE ENGINEERING DESIGN

• Black Box Testing: Focus on what the system does.

• White Box Testing: Focus on how the system works.

Both are essential for robust software testing.

PART-A UNIT-IV QUESTIONS

[Link] is software testing?

Answer: Software testing is the process of evaluating a software application to ensure it meets
specified requirements and is free of defects. It involves executing the software in controlled
conditions to identify errors and gaps.

[Link] is unit testing?

Answer: Unit testing is a type of testing where individual components or functions of the software are
tested in isolation to ensure that they work correctly. It is usually done by developers.

[Link] is unit testing important?

Answer: Unit testing helps detect issues early in the development process, ensuring that each
component functions correctly before integration with other parts of the system. It improves code
quality and simplifies debugging.

[Link] is black box testing?

Answer: Black box testing is a testing technique where the tester does not need knowledge of the
internal structure or code. The focus is on verifying that the software meets functional requirements
by providing inputs and checking outputs.

[Link] is white box testing?

Answer: White box testing, also known as clear-box testing, involves testing the internal structures or
workings of an application. The tester has knowledge of the code and uses it to design test cases that
explore code paths and conditions.

[Link] is the key difference between black box and white box testing?

Answer: Black box testing focuses on functional behavior without considering internal code structure,
while white box testing involves testing based on knowledge of the code’s internal logic and structure.

[Link] is integration testing?

Answer: Integration testing is the process of testing the interfaces between individual modules or
components to ensure that they work together as expected when integrated into a larger system.

[Link] is system testing?

Answer: System testing involves testing the entire system as a whole to verify that all components
work together as expected and that the system meets its overall requirements.

[Link] is system testing necessary?

Answer: System testing ensures that all modules and components work together as intended and that
the system meets both functional and non-functional requirements, like performance and security.

[Link] is regression testing?

 22CS392-SOFTWARE ENGINEERING DESIGN

Answer: Regression testing involves retesting a system after changes, such as bug fixes or
enhancements, to ensure that existing functionalities are not broken and the system continues to
work correctly.

[Link] is regression testing important?

Answer: Regression testing is important to ensure that new changes or additions to the software do
not introduce new bugs or break existing functionality, maintaining system stability.

[Link] is debugging?

Answer: Debugging is the process of identifying, isolating, and fixing bugs or defects in software. It is
typically performed after testing has detected a failure or incorrect behavior in the system.

[Link] is program analysis in the context of software testing?

Answer: Program analysis refers to the process of automatically analyzing the behavior of a software
program to detect potential errors, optimize code, or ensure correctness, often done statically
(without execution).

[Link] is static program analysis?

Answer: Static program analysis involves examining the code without executing it, using tools to
detect potential errors, security vulnerabilities, or code inefficiencies based on source code structure.

[Link] is symbolic execution?

Answer: Symbolic execution is a testing technique where program paths are explored using symbolic
inputs rather than actual data, allowing for the identification of bugs by considering multiple execution
scenarios at once.

[Link] are the benefits of symbolic execution?

Answer: Symbolic execution allows the discovery of a wide range of potential bugs by exploring
different paths in a program without manually providing inputs, improving test coverage and fault
detection.

[Link] is model checking in software testing?

Answer: Model checking is a formal verification technique that systematically explores the state space
of a system model to verify that certain properties hold, such as safety or liveness, helping in detecting
errors in design.

[Link] is model checking used?

Answer: Model checking is used to verify that a system meets certain specifications or properties, like
deadlock-freedom or correctness, by systematically exploring all possible states and transitions in the
system.

20. What is the difference between static testing and dynamic testing?

Answer: Static testing involves examining the software code or documentation without executing it
(e.g., code reviews), while dynamic testing involves executing the software and observing its behavior
during runtime.

[Link] is automated testing?

 22CS392-SOFTWARE ENGINEERING DESIGN

Answer: Automated testing uses specialized tools or scripts to execute tests on software
automatically, comparing actual outcomes with expected ones, which speeds up the testing process
and improves test coverage.

PART-B UNIT-IV QUESTIONS

[Link] are working on a financial application where different modules, such as the payment gateway,
user authentication, and account management systems, need to be integrated. You must ensure these
modules work together without failures. What type of testing will you use, and what will be your focus
in testing?

2.A web-based e-commerce application recently underwent a major update to include a new payment
method. However, you need to ensure that this new feature did not introduce bugs into the existing
checkout process. What type of testing would you conduct, and why?

[Link] the testing phase of a mobile application, users report that the app crashes under specific
conditions when accessing the profile section. As a developer, what would be your approach to resolve
this issue, and which technique will you use?

[Link] are testing a security-critical application that handles encrypted communications. Manually
testing all possible inputs to ensure every possible security vulnerability is time-consuming. What
advanced technique could you apply to thoroughly test the application's logic?

[Link] a mission-critical aviation software system, where ensuring that the system never enters an
unsafe state is essential, how would you verify that the software adheres to safety requirements?
Which formal method would you use, and why?

[Link] are tasked with testing the login functionality of a web-based e-learning platform. The login
form requires users to enter their username and password, and provides the following behaviors:

* A successful login redirects the user to their dashboard.

* Incorrect username or password triggers an error message.

* After 3 failed login attempts, the account is locked for 30 minutes.

* The "Forgot Password" link should redirect the user to the password recovery page.

* The system must handle both valid and invalid inputs securely (e.g., SQL injection prevention).

Question:

Design a set of test cases to validate the login functionality of this platform. Consider valid, invalid,
and edge case inputs in your design.

POSSIBLE ANSWER FOR TEST CASE DESIGN QUESTION **Above

Test Case

ID

Test Scenario
 22CS392-SOFTWARE ENGINEERING DESIGN

Test Steps

Expected Result

TC_001

Valid login with correct credentials

1. Navigate to login page

2. Enter valid username and password

3. Click "Login"

User is successfully redirected to their dashboard

TC_002

Invalid login with incorrect password

1. Navigate to login page

2. Enter valid username and incorrect

password

3. Click "Login"

Error message "Invalid username or password" is displayed

TC_003

Invalid login with incorrect username

1. Navigate to login page

2. Enter invalid username and any password

3. Click "Login"

Error message "Invalid username or password" is displayed

TC_004

Account lockout after 3 failed attempts

1. Enter invalid credentials

2. Repeat twice more

3. Try logging in again

Error message "Account locked for 30 minutes" is displayed

TC_005

Login with empty username

1. Leave username field blank

2. Enter any password

 22CS392-SOFTWARE ENGINEERING DESIGN

3. Click "Login"

Error message "Username is required" is displayed

TC_006

Login with empty password

1. Enter valid username

2. Leave password field blank

3. Click "Login"

Error message "Password is required" is displayed

TC_007

Login with special characters (SQL

injection prevention)

1. Enter SQL injection strings in username or

password

2. Click "Login"

System prevents SQL injection and displays "Invalid username

or password" message

TC_008

Forgot Password link

1. Click on "Forgot Password" link on login

page

User is redirected to the password recovery page

TC_009

Validate case-sensitivity of password

1. Enter valid username

2. Enter incorrect case for the password

3. Click "Login"

Error message "Invalid username or password" is displayed

TC_010

Valid login with trimmed spaces

1. Enter valid username and password with

spaces before/after
 22CS392-SOFTWARE ENGINEERING DESIGN

2. Click "Login"

Spaces are ignored, and the user is successfully logged in

Unit- 5 PROJECT MANAGEMENT

Process, Project, Product, and Project Management
1. Process:
 22CS392-SOFTWARE ENGINEERING DESIGN

o A process is a set of activities or tasks performed in a structured sequence to achieve

a specific outcome or result.

o Example: Software development process includes requirement gathering, design,

coding, testing, and deployment.

2. Project:

o A project is a temporary endeavor undertaken to create a unique product, service, or

result with defined start and end points.

o Example: Developing a customer relationship management (CRM) system for a

company.

3. Product:

o A product is the output of a project or process, intended to meet a specific user need
or market demand.

o Example: A mobile app, a website, or a software tool.

4. Project Management:

o Project management is the practice of applying knowledge, skills, tools, and

techniques to project activities to meet project requirements and achieve project
goals, within the defined scope, time, and cost constraints.

o It involves planning, organizing, leading, and controlling resources to achieve project

goals.

Types of Project Management Techniques:

1. Waterfall Methodology:

o A linear, sequential approach where each phase of the project is completed before
moving to the next.

o Suitable for well-defined projects.

2. Agile Methodology:

o An iterative approach that breaks the project into smaller chunks called sprints and
delivers progress in short, manageable iterations.

o Focuses on flexibility and customer collaboration.

3. Scrum:

o A type of Agile method, uses roles such as Scrum Master and Product Owner, and is
focused on delivering working software in short cycles.

4. Kanban:

o A visual approach to manage work in progress with continuous delivery, focusing on

task flow efficiency.

5. Critical Path Method (CPM):

 22CS392-SOFTWARE ENGINEERING DESIGN

o A project management technique used to determine the longest sequence of tasks

(critical path) to complete a project on time.

Project Management vs. Process Management:

• Project Management focuses on temporary projects, with specific goals and deadlines,
ensuring that the project is completed within scope, on time, and within budget.

o Example: Launching a new product.

• Process Management focuses on managing and improving ongoing, repetitive processes that
drive continuous performance and efficiency within an organization.

o Example: Managing the software development life cycle (SDLC).

Roles and Responsibilities of Software Project Manager in IT Industries:

• Responsibilities:

o Project Planning: Define scope, timeline, budget, and resources.

o Team Management: Assign roles, monitor performance, and manage communication.

o Risk Management: Identify risks, develop mitigation plans.

o Stakeholder Communication: Communicate with clients, executives, and team

members.

o Quality Assurance: Ensure product meets quality standards.

o Tracking and Reporting: Track progress, handle changes, and report to stakeholders.

• Skills Required:

o Strong communication, leadership, and negotiation skills.

o Knowledge of project management tools like Jira, Trello, MS Project.

o Familiarity with project methodologies (Waterfall, Agile, Scrum).

Example/Role Plays

• Example 1:

o Role Play: A project manager leads a team to develop a new e-commerce platform.
The manager defines the project scope, creates a timeline, assigns tasks, and ensures
communication between developers, designers, and testers.

• Example 2:

o Role Play: A software project manager in an Agile environment facilitates daily

standups, prioritizes backlog items, and ensures the team delivers functional software
in 2-week sprints.

Traditional Project Management vs. Agile Project Management

 22CS392-SOFTWARE ENGINEERING DESIGN

Traditional Project Management Agile Project Management

Uses Waterfall method (sequential phases). Uses iterative methods (e.g., Scrum, Kanban).

Fixed scope, timeline, and budget. Flexible scope and iterative progress.

Detailed planning upfront. Continuous planning and adjustment.

Focus on documentation and processes. Focus on collaboration and feedback.

Examples: Construction projects, Examples: Software development, product

manufacturing. innovation.

Product Management:

• Definition: The process of overseeing the development and lifecycle of a product from
ideation to delivery and beyond.

• Key Aspects:

o Strategy: Defining the product vision, market research, and roadmap.

o Planning: Creating timelines, feature prioritization, and resource allocation.

o Execution: Ensuring product development meets customer needs and market

demands.

o Monitoring: Tracking product performance and user feedback for future

improvements.

• Goal: Deliver products that meet market demands and create value for customers.

Project Management:

• Definition: The process of planning, executing, and overseeing the successful completion of a
project within scope, time, and cost constraints.

• Key Aspects:

o Scope: Defining the project's objectives and deliverables.

o Timeline: Creating a detailed schedule and ensuring deadlines are met.

o Resources: Allocating and managing human, financial, and material resources.

o Risk Management: Identifying and mitigating potential risks during the project
lifecycle.

o Monitoring & Control: Tracking project progress and making adjustments as

necessary.

• Goal: Successfully deliver the project within the specified time, budget, and quality.

Software Project Management:

 22CS392-SOFTWARE ENGINEERING DESIGN

• Definition: The process of planning, executing, and monitoring software development

projects to ensure the successful delivery of software products.

• Key Aspects:

1. Scope Management:

▪ Clearly define the project scope, deliverables, and goals.

2. Time Management:

▪ Develop a project schedule, including milestones and deadlines.

▪ Ensure timely delivery of each phase (e.g., design, coding, testing).

3. Cost Management:

▪ Budgeting resources and tracking expenses to stay within the allocated

budget.

4. Quality Management:

▪ Ensuring software quality through testing, reviews, and continuous

improvement.

5. Risk Management:

▪ Identifying risks early and preparing strategies to mitigate them.

6. Communication Management:

▪ Ensuring clear communication among stakeholders, including clients,

developers, and team members.

7. Human Resource Management:

▪ Assigning and managing team roles based on skill sets and project
requirements.

8. Procurement Management:

▪ Handling external resources, tools, or third-party vendors required for the

project.

9. Stakeholder Management:

▪ Engaging with stakeholders and keeping them informed about the project's
progress.

Tools for Software Project Management:

o Project Tracking: Jira, Trello, Asana.

o Collaboration: Slack, Microsoft Teams.

o Version Control: Git, SVN.

o Time Management: Microsoft Project, [Link].

 22CS392-SOFTWARE ENGINEERING DESIGN

o Risk Management: Risk Watch, Monte Carlo simulations.

Steps in Software Project Management:

1. Initiation: Define the project's goals, scope, and stakeholders.

2. Planning: Develop a detailed project plan, including timelines, resources, and budgets.

3. Execution: Implement the plan by developing the software, managing the team, and
monitoring progress.

4. Monitoring and Controlling: Track the project's performance, making adjustments as needed.

5. Closure: Ensure all deliverables are completed, and the project is formally closed.

Example:

A company starts a software project to develop a customer management system. The project manager
defines the scope (what features the system should have), creates a timeline (how long it will take to
develop each feature), and assigns resources (team members for development, testing, and
deployment). Throughout the project, they track progress using tools like Jira and adjust timelines and
resources if necessary. After successful delivery, the project is closed with a final review of all
outcomes.

Software Project Management (SPM)

Definition:
SPM is the process of planning, organizing, and overseeing the execution of a software project to
achieve its goals within time, cost, and scope constraints.

Key Aspects:

o Scope Management:

▪ Clearly define the project scope, deliverables, and goals.

o Time Management:

▪ Develop a project schedule, including milestones and deadlines.

▪ Ensure timely delivery of each phase (e.g., design, coding, testing).

o Cost Management:

▪ Budgeting resources and tracking expenses to stay within the allocated

budget.

o Quality Management:

▪ Ensuring software quality through testing, reviews, and continuous

improvement.

o Risk Management:

▪ Identifying risks early and preparing strategies to mitigate them.

o Communication Management:
 22CS392-SOFTWARE ENGINEERING DESIGN

▪ Ensuring clear communication among stakeholders, including clients,

developers, and team members.

o Human Resource Management:

▪ Assigning and managing team roles based on skill sets and project
requirements.

o Procurement Management:

▪ Handling external resources, tools, or third-party vendors required for the

project.

o Stakeholder Management:

▪ Engaging with stakeholders and keeping them informed about the project's
progress.

• Tools for Software Project Management:

o Project Tracking: Jira, Trello, Asana.

o Collaboration: Slack, Microsoft Teams.

o Version Control: Git, SVN.

o Time Management: Microsoft Project, [Link].

o Risk Management: RiskWatch, Monte Carlo simulations.

Phases of Software Project Management:

1. Initiation:

o Define project goals, scope, and feasibility.

o Appoint project manager and team.

2. Planning:

o Create a detailed project plan (timeline, cost, resources).

o Define deliverables, risks, and quality standards.

3. Execution:

o Build and develop the product.

o Assign resources and manage tasks.

4. Monitoring & Controlling:

o Track project progress.

o Identify issues, manage risks, and make corrective actions.

5. Closure:

o Deliver the final product.

 22CS392-SOFTWARE ENGINEERING DESIGN

o Obtain client approval, release resources, and review project performance.

Scope-Based Explanation

• Initiation: High-level scope definition (what and why).

• Planning: Detailed scope breakdown (deliverables, tasks, resources).

• Execution: Implement scope through development and testing.

• Monitoring & Controlling: Ensure project scope stays on track.

• Closure: Confirm scope completion and client satisfaction.

Advantages:

1. Clear Objectives: Defined goals and deliverables.

2. Resource Optimization: Efficient allocation of time, budget, and personnel.

3. Risk Management: Early identification and mitigation of risks.

4. Improved Communication: Structured interaction among stakeholders.

5. Quality Assurance: Ensures software meets required quality standards.

6. Timely Delivery: Helps meet project deadlines.

7. Budget Control: Keeps the project within the budget.

8. Stakeholder Satisfaction: Regular progress assessment meets expectations.

Disadvantages:

1. Complexity: Large projects can be overwhelming to manage.

2. Time-Consuming: Requires continuous tracking and adjustments.

3. Rigidity: Structured processes can hinder flexibility.

4. Resource-Intensive: Needs skilled managers and tools.

 22CS392-SOFTWARE ENGINEERING DESIGN

5. Process Overload: Focus on processes may stifle creativity.

6. Scope Creep: Uncontrolled changes can lead to delays and cost overruns.

7. Skilled Personnel Dependency: Success depends on team expertise.

Software Configuration Management (SCM)

Definition:
SCM is a process to manage, track, and control changes to software and its components throughout
the software development lifecycle.

Key Components:

1. Version Control: Tracks changes in code.

2. Configuration Identification: Defines software components.

3. Change Control: Manages software modifications.

4. Build Management: Automates software building.

5. Release Management: Ensures proper deployment.

SCM (Software Configuration Management):

• Goal: Ensure control over software components, track changes, and maintain consistency
throughout the software lifecycle.

• Types of Maintenance in SCM:

o Corrective: Fix defects.

o Adaptive: Update software for new environments.

o Perfective: Enhance features.

o Preventive: Refactor for future stability.

• Software Configuration Items (SCI): Source code, documentation, configuration files, libraries,
executables.

• Baselines: Reference points representing approved versions of the software at a specific stage.

Configuration Management Tasks:

1. Identification: Track and manage components.

2. Control: Approve and manage changes.

3. Status Accounting: Track changes and versions.

4. Auditing: Verify that the software matches its baseline.

 22CS392-SOFTWARE ENGINEERING DESIGN

• Version Control: Manages and tracks changes in software. Examples: Git, SVN. It supports
collaboration, history, and branching.

Advantages:

• Consistency: Ensures all team members work on the latest version.

• Traceability: Tracks changes and their reasons.

• Collaboration: Minimizes conflicts during development.

• Quality Control: Helps in consistent and reliable releases.

Disadvantages:

• Complex Setup: Initial configuration can be time-consuming.

• Overhead: Requires constant monitoring and maintenance.

• Learning Curve: Developers may need time to adapt to SCM tools.

PROJECT SCHEDULING:

• Definition: The process of planning and allocating resources, tasks, and timelines to ensure
the successful completion of a project.

• Purpose:

o To define the timeline for completing project tasks.

o To ensure efficient resource utilization and avoid delays.

o To monitor progress and track the project's development.

• Key Components:

1. Tasks/Activities: Breakdown of the project into smaller, manageable tasks.

2. Resources: Allocation of necessary resources (team, tools, equipment).

3. Timeline: Specific start and end dates for each task and the overall project.

4. Dependencies: Understanding the relationship between tasks (which task depends on others).

5. Milestones: Key points in the project where significant progress is achieved.

• Techniques:

o Gantt Charts: Visual representation of tasks and timelines.

o Critical Path Method (CPM): Determines the longest sequence of tasks that must be
completed on time for the entire project to be completed on schedule.

o Program Evaluation and Review Technique (PERT): Uses statistical analysis to estimate
the time required to complete each task and the project as a whole.

• Tools: Microsoft Project, Primavera, Jira, Trello, Asana.

Advantages:
 22CS392-SOFTWARE ENGINEERING DESIGN

o Helps in clear resource planning.

o Allows tracking and ensures deadlines are met.

o Minimizes the risk of overlapping tasks and conflicts.

Disadvantages:

o Can be time-consuming to update and maintain.

o Complex projects may require frequent adjustments.

DEVOPS:

What is DevOps?

• DevOps is a set of practices combining software development and IT operations to shorten

development cycles, improve deployment frequency, and ensure high-quality software.

Principles:

1. Collaboration between development and operations teams.

2. Automation of repetitive tasks (testing, deployment).

3. Continuous Integration (CI) for frequent code integration.

4. Continuous Delivery (CD) for automated deployment.

5. Infrastructure as Code (IaC) for managing infrastructure through code.

Process:

1. Plan: Define project scope and requirements.

 22CS392-SOFTWARE ENGINEERING DESIGN

2. Develop: Write and integrate code.

3. Build: Compile and test automatically.

4. Test: Automated verification of code.

5. Release: Automated deployment to production.

6. Deploy: Continuous delivery to production.

7. Operate: Monitor system performance.

8. Monitor: Collect feedback for improvements.

Advantages:

1. Faster time-to-market.

2. Better collaboration.

3. Increased efficiency via automation.

4. Improved software quality.

5. Higher reliability.

6. Scalability and flexibility.

7. Cost-effective.

Disadvantages:

1. Requires cultural shift.

2. Complex tool setup.

3. High skill demands.

4. Time-consuming initial setup.

5. Risk of over-automation.

6. Integration challenges.

DevOps aims to make development faster, more efficient, and reliable through collaboration and
automation.

CLOUD AND CLOUD COMPUTING:

What is Cloud Computing?

• Cloud computing is the delivery of computing services (servers, storage, databases,

networking, software) over the internet ("the cloud"), enabling on-demand access to
resources without the need for physical infrastructure.

Types of Cloud:

1. Public Cloud: Services are provided over the public internet and are available to anyone. (e.g.,
AWS, Azure)
 22CS392-SOFTWARE ENGINEERING DESIGN

2. Private Cloud: Cloud infrastructure is used exclusively by one organization, offering more
control and security.

3. Hybrid Cloud: A mix of public and private clouds, enabling data and applications to be shared
between them.

Cloud Service Models:

1. Infrastructure as a Service (IaaS): Provides virtualized computing resources over the internet
(e.g., AWS EC2).

2. Platform as a Service (PaaS): Provides hardware and software tools over the internet, usually
for application development (e.g., Google App Engine).

3. Software as a Service (SaaS): Provides fully managed software applications over the internet
(e.g., Google Workspace, Microsoft Office 365).

Advantages of Cloud:

1. Cost-Effective: Pay-as-you-go model reduces infrastructure costs.

2. Scalability: Easily scale resources up or down as needed.

3. Accessibility: Access services from anywhere with an internet connection.

4. Reliability: Data is often replicated across multiple locations, ensuring high availability.

5. Security: Cloud providers invest heavily in security measures.

Disadvantages of Cloud:

1. Downtime: Dependent on internet connection and cloud provider’s uptime.

 22CS392-SOFTWARE ENGINEERING DESIGN

2. Security Concerns: Storing sensitive data off-site can be risky.

3. Limited Control: Less control over infrastructure and updates.

4. Data Privacy Issues: Concerns over how data is handled and stored by providers.

Cloud computing allows businesses and individuals to leverage advanced technology without
managing physical infrastructure, offering flexibility, scalability, and efficiency.

DEPLOYMENT PIPELINE:

Definition:

A Deployment Pipeline is an automated set of processes for continuously building, testing, and
deploying software to various environments.

Main Stages of Deployment Pipeline:

1. Source Stage:

o Purpose: Retrieves the latest version of the code from the version control system (e.g.,
Git).

o Key Feature: Continuous integration starts here, ensuring the latest code is always
tested and ready for deployment.

2. Build Stage:

o Purpose: Compiles the code into executable artifacts (e.g., .jar, .war files).

o Key Feature: Ensures that the code is error-free and ready for testing.

3. Test Stage:

o Purpose: Runs automated tests (unit tests, integration tests) to verify the correctness
of the code.

o Key Feature: Prevents faulty code from reaching production by catching bugs early.

4. Deploy to Staging Stage:

o Purpose: Deploys the build to a staging environment that closely mirrors production.

o Key Feature: Allows testing in an environment that replicates the real world before
deploying to production.

5. Production Deployment Stage:

o Purpose: Deploys the validated build to the live production environment.

o Key Feature: Once the build passes all tests and staging checks, it is deployed to
customers.

Key Features of Deployment Pipeline:

1. Automation: Reduces manual intervention and speeds up the development-to-production

process.
 22CS392-SOFTWARE ENGINEERING DESIGN

2. Continuous Integration (CI): Ensures that changes are continuously integrated and tested,
reducing integration issues.

3. Continuous Delivery (CD): Ensures that the software is always ready to be deployed at any
time, with minimal risk.

4. Quality Checks: Automated tests at each stage help catch bugs early and improve software
quality.

5. Rapid Feedback: Developers get immediate feedback on their code’s health, facilitating quick
corrections.

6. Consistency: Ensures that the codebase is consistent across environments (development,

staging, production).

7. Scalability: The pipeline can handle multiple deployments and releases efficiently.

Benefits of Deployment Pipeline:

• Faster release cycles

• Higher quality software with automated testing

• Reduced manual errors

• Better collaboration between development and operations teams

Overall Architecture Building, Testing, and Deployment:

1. Architecture Building:

• Definition: Designing the structure of software, including components, data flow, and
interactions.

• Key Features:

o Scalable: Can handle increased load.

o Resilient: Capable of recovering from failures.

o Modular: Allows independent development and testing of components.

o Maintainable: Easy to update and fix.

o Secure: Protects data and operations.

2. Testing:

• Definition: Verifying the functionality and reliability of the software through various tests.

• Types:

o Unit Testing: Tests individual components.

o Integration Testing: Tests interactions between components.

o System Testing: Tests the entire system in a staging environment.

o Regression Testing: Ensures that new changes do not break existing features.
 22CS392-SOFTWARE ENGINEERING DESIGN

o User Acceptance Testing (UAT): Validates the software with end-users.

3. Deployment:

• Definition: The process of releasing the software to production or staging environments.

• Stages:

o Pre-Deployment: Preparing the environment (e.g., configuration).

o Deployment: Moving the code to production.

o Post-Deployment: Monitoring the deployment for issues.

4. Tools:

• Version Control: Git, SVN for managing code changes.

• CI/CD Tools: Jenkins, GitLab CI, CircleCI for automation.

• Testing Tools: Selenium, JUnit, Postman for functional testing.

• Deployment Tools: Docker, Kubernetes for containerization and orchestration.

• Monitoring Tools: Prometheus, Grafana for system monitoring.

5. Case Study:

• Scenario: A cloud-based e-commerce application.

o Architecture: Microservices architecture for scalability and independence.

o Testing: Automated unit and integration tests with CI/CD pipelines.

o Deployment: Deployed using Kubernetes and Docker containers, ensuring easy

scaling and management.

o Tools:

▪ CI/CD: Jenkins pipeline to automate builds, tests, and deployments.

▪ Monitoring: Grafana and Prometheus for real-time monitoring of system

health and performance.

Part-A Questions:
1. What is Software Project Management?
It involves planning, organizing, leading, and controlling software projects to ensure timely
delivery, staying within budget, and meeting requirements.
2. What is Software Configuration Management (SCM)?
A process for tracking and controlling software changes to ensure consistency, integrity, and
traceability throughout its lifecycle.
 22CS392-SOFTWARE ENGINEERING DESIGN

3. What is project scheduling in software development?

Defining tasks, setting timelines, and allocating resources to ensure software development
meets milestones on time.
4. What is the primary motivation for adopting DevOps?
To streamline development and operations for faster delivery, better collaboration, and
improved software quality.
5. What role does the cloud play as a platform in DevOps?
It provides scalable, on-demand resources for development, testing, and deployment,
enabling automation, monitoring, and continuous integration.
6. What is a deployment pipeline in DevOps?
An automated process moving code from version control to production through stages like
build, test, and deployment.
7. What is the purpose of Continuous Integration (CI) in DevOps?
Automatically tests and integrates developers' changes into the shared repository, ensuring
faster feedback and avoiding integration issues.
8. Define Continuous Deployment (CD) in DevOps.
Automated code release to production after passing all tests, ensuring updates are
continuously delivered to users.
9. What is the importance of SCM tools like Git?
SCM tools track changes, enable collaboration, ensure version control, and prevent errors
caused by conflicting changes.

PART-B QUESTIONS:

1. Explain the importance of Software Configuration Management (SCM) and describe how SCM
practices improve the software development lifecycle.

Introduction:

SCM manages and controls software changes, ensuring consistency, accountability, and traceability
throughout the lifecycle of software artifacts like code, documentation, and test scripts.

Importance of SCM:

• Version Control: Maintains a history of changes, enabling teams to track versions and revert
if needed.

• Collaboration: Facilitates teamwork by managing concurrent modifications, preventing

overwrites.

• Traceability: Tracks the origin of changes, ensuring accountability and simplifying debugging.

• Configuration Auditing: Ensures configurations meet standards and compliance.

• Automation and CI/CD Integration: Streamlines tasks like builds, testing, and deployment.

SCM Tools:

Tools like Git, SVN, and Mercurial enable effective SCM practices, including distributed version control
and seamless merging.

Conclusion:
 22CS392-SOFTWARE ENGINEERING DESIGN

SCM enhances project efficiency, minimizes errors, and improves collaboration, making it integral to
successful software development.

2. Describe the process of project scheduling in software project management, its key challenges, and
how effective scheduling impacts project success.

Introduction:

Project scheduling involves allocating tasks, resources, and timelines. Effective scheduling aligns
project activities with goals, ensuring timely completion.

Scheduling Process:

1. Task Breakdown: Divide the project into manageable tasks (WBS).

2. Resource Allocation: Assign manpower, tools, and other resources.

3. Timeline Estimation: Use tools like PERT or Gantt charts for realistic timelines.

4. Milestones: Set checkpoints to monitor progress and adjust plans.

Key Challenges:

• Time and Resource Estimation: Misestimates cause delays.

• Unforeseen Issues: Unexpected problems derail timelines.

• Resource Conflicts: Allocation conflicts slow progress.

Impact of Effective Scheduling:

• Improved Productivity: Clear timelines enhance focus.

• Risk Management: Critical task scheduling mitigates risks.

• Client Satisfaction: Timely delivery builds trust.

Conclusion:

Effective scheduling ensures resource optimization, risk reduction, and project success.

3. Discuss the motivation for adopting DevOps in modern software development and explain how
DevOps principles enhance the software development lifecycle.

Introduction:

DevOps bridges software development and IT operations, promoting collaboration and improving
delivery speed, quality, and reliability.

Motivation for DevOps:

• Faster Delivery: Automates processes, accelerating releases.

• Improved Collaboration: Breaks silos between teams, enhancing workflows.

• Scalability: Automation and cloud infrastructure meet growing demands.

 22CS392-SOFTWARE ENGINEERING DESIGN

DevOps Principles:

• Continuous Integration (CI): Integrates code frequently for early defect detection.

• Continuous Delivery (CD): Automates updates, ensuring quick and reliable deployments.

• Automation: Reduces manual effort and errors.

• Monitoring: Identifies and resolves issues proactively.

Impact on the SDLC:

• Reduced Cycle Time: Faster feedback for quicker iterations.

• Higher Quality: Automated testing ensures robust code.

• Customer Satisfaction: Frequent updates improve user experience.

Conclusion:

DevOps enhances software delivery speed, quality, and collaboration, making it indispensable for
modern development.

4. Explain the architecture of a deployment pipeline in DevOps. How does it improve software delivery,
and what are the key stages involved?

Introduction:

A deployment pipeline automates the workflow from version control to production deployment,
ensuring quality and efficiency.

Key Stages of the Deployment Pipeline:

1. Source Code Management: Changes are pushed to repositories (e.g., Git).

2. Build: Compiles code into executables using tools like Jenkins.

3. Automated Testing: Runs unit, integration, and system tests.

4. Staging: Validates code in a staging environment.

5. Production Deployment: Deploys tested code to production.

Benefits:

• Faster Delivery: Automation reduces lead time.

• Consistency: Standardized processes ensure reliability.

• Feedback Loop: Continuous testing provides quick issue detection.

Conclusion:

Deployment pipelines automate delivery, improving speed, safety, and reliability.

 22CS392-SOFTWARE ENGINEERING DESIGN

5. Discuss how cloud platforms support DevOps practices and explain the role of Infrastructure as
Code (IAC) in cloud-based DevOps environments.

Introduction:

Cloud platforms provide scalable, on-demand infrastructure, while IAC automates cloud resource
management in DevOps.

Cloud Platforms and DevOps:

• Scalability: Dynamically adjusts resources to meet demand.

• Automation: Simplifies deployment and testing.

• Collaboration: Centralized environments improve teamwork.

Role of IAC:

• Automation: Automates resource provisioning and configuration.

• Consistency: Ensures identical environments for development and production.

• Version Control: Manages infrastructure changes like code.

Conclusion:

Cloud platforms and IAC enable efficient, scalable, and automated DevOps workflows, enhancing
software delivery.