Compressed Text from Presentation
Software
Engineering
Week 06 Lecture 01
REQUIREMENT ANALYSIS
After the requirement engineering the next step is to analyze the gathered requirements. It
is done by modeling the requirements.
Flow-oriented modeling
Scenario-based modeling
Class-based modeling
Behavioral modeling
WHY ANALYSIS MODELING?
Representation of the system
Easy to easy and maintain
Use graphics to plan before implementation
Helps in tracking and evaluation of components
Class-based modeling
Defines objects, attributes and relationships
It closely associated with object-oriented programming (OOP) and is used to create
software systems that are modular, flexible, and easy to maintain.
E.g., Class Diagram
Class-based modeling [contd..]
Representation of a class
Class-based modeling [contd..]
Dependency: If a class is dependent on another class, you represent it is dashed arrow
Class-based modeling [contd..]
Generalization:a relationship between two classes that represents an "is-
a" relationship, shown by simple arrow
Class-based modeling [contd..]
Association: the type of relationship between classes.
Exactly one (1)
Zero to Many (0 … *)
Zero or one (0 … 1)
One to Many (1 … *)
Many to Many (* … *)
Association is a has-a relationship
Class-based modeling [contd..]
Association Aggregation Composition
Class-based modeling [contd..]
Aggregation: a weak relationship between two classes, shown by
hollow diamond. It is an owns-a relationship
Class-based modeling [contd..]
Composition: a strong relationship between two classes, shown by filled diamond.
Class-based modeling [contd..]
Association
Example:
Online Shopping
Scenario-based modeling
Represents the system from the user’s point of view
By focusing on real-world scenarios and user tasks, the methodology helps to ensure that
the system meets the needs of its users and stakeholders.
E.g., Activity diagram
Scenario-based modeling [contd..]
Components of an activity flow diagram: Start
Activity Parallel Activity
yes Condition
End
Scenario-based modeling [contd..]
Example:
Behavioral modeling
Depicts the states of classes and the impact of events on these states.
Involves creating models that describe how the system should
behave in different scenarios or use cases.
E.g., Sequence Diagram
Behavioral modeling [contd..]
Components of a sequence diagram
object actor
activation box lifeline
Behavioral modeling [contd..]
Components of a sequence diagram
Synchronous message
Asynchronous message Reply message symbol
Behavioral modeling [contd..]
Components of a sequence diagram
Flow-oriented Modeling
Provides an indication of how data objects are transformed
by a set of processing information.
The software system is decomposed into smaller subsystems or modules that can be
independently analyzed and designed.
E.g., Component diagram
Flow-oriented Modeling [contd..]
Component
Provided Interface
Required Interface
port
Flow-oriented Modeling [contd..]
Required Interface
Provided Interface
Flow-oriented Modeling [contd..]
Quiz
A library has a catalog of books, which are available to borrow by its members. The system
allows users to search for books, borrow books, return book...
Draw class diagram, sequence diagram, and activity diagram of the given scenario
Software
Engineering
Week 13 Lecture 01
TEST AUTOMATION
It is a software testing approach that involves using specialized tools to automate the
execution of test cases and compare the actual results with ex...
It aims to streamline the testing process, improve efficiency, and increase test coverage by
reducing the manual effort required for repetitive and ti...
TEST AUTOMATION [contd..]
The automation testing software can
Enter test data into the System Under Test
Compare expected and actual results
Generate detailed test reports.
Which Test cases to Automate?
High Risk – Business Critical test cases
Test cases that are repeatedly executed
Test Cases that are tedious or difficult to perform manually
Test Cases which are time-consuming
Automated Testing Process
Test Planning and Tool Selection
Scope Definition
Setup and Development of Tests Scripts
Test Execution
Analysis
Maintenance
Automated Testing Process [contd..]
Test Planning and Tool Selection
Define the scope, objectives, and test coverage for automation testing. Identify all the
possible test cases.
Choose the appropriate automation testing tools that align with your requirements,
technology, and budget.
The goal is to try to automate 50 to 60 percent of manual test cases
Automated Testing Process [contd..]
Scope Definition
Scope is the area of your Application Under Test which will be automated. It can cover:
Important and common features across applications
Scenarios which have a large amount of data
The extent to which business components are reused
The complexity of test cases
Ability to use the same test cases for cross-browser testing
Automated Testing Process [contd..]
Setup and Development of Tests Scripts
Set up the necessary infrastructure, including test environments, test
data, and any required configurations.
Create test scripts or test scenarios using the chosen automation
tool, or languages such as Java, Python, or C#.
Automated Testing Process [contd..]
Test Execution
Execute the automated test scripts against the application or system being tested.
The automation tool interacts with the application's user interface, or APIs to perform
actions and validate responses.
Automated Testing Process [contd..]
Analysis:
Analyze the test results generated by the tool and identify if the test case fails in any case.
Maintenance:
Update the test cases if any new functionality is added.
TEST AUTOMATION
Working example of Automation Tool:
Benefits of Automated Testing
Faster than Manual Testing
Reliable results
Wider test coverage
Saves Time and Cost
More efficient
Better Speed
Reusable and Frequent Testing
Assignment
Discuss following types of testing:
Alpha Testing
Beta Testing
Black Box Testing
White Box Testing
Gray Box Testing
Acceptance Testing
Try to understand working of any Test automation tool
Software
Engineering
Week 05 Lecture 02
TYPES OF REQUIREMENTS
We can divide requirements into five types
Functional requirements
Non-functional requirements
External interfaces
Physical product Requirements
Development constraints
FUNCTIONAL REQUIREMENTS
Functional requirements are those behaviors that the developed product
should do or support.
These are usually expressed as inputs into the product,
outputs of the product, or a description of the behavior itself.
FUNCTIONAL REQUIREMENTS[contd..]
For example, input might be data related to a user’s online purchase, including name,
address, item purchased, and payment information.
The output in this scenario might be a notification email after the transaction is performed.
FUNCTIONAL REQUIREMENTS[contd..]
Information flow diagrams are a graphical technique commonly
used to show how data flows within a system.
FUNCTIONAL REQUIREMENTS[contd..]
The following is an example of an information flow diagram
A customer uses a credit card with a product
The credit cardinformation is verified before a receipt is generated for the user.
FUNCTIONAL REQUIREMENTS[contd..]
FUNCTIONAL REQUIREMENTS[contd..]
Functional Requirements include
Business requirements
Business rules
User requirements
Business requirements
Those requirements that involve the purpose of the project.
For Example, The client needs to reduce errors in orders made to their company by 25% by
the end of next year to raise their yearly revenue by $10,000
Business requirements [contd..]
Business requirements should not be confused with business rules, although they are often
associated.
Business requirements deal with why the project was pursued, while business rules are
constraints on how the product will function.
Business requirements [contd..]
Business rules are sometimes necessary to make a project appropriate or successful.
They are often budgets, policies, guidelines, or regulations
Business requirements [contd..]
Examples of business rules include:
Government or legal regulations
Privacy policies
Brand uniformity requirements
Student shall be struck off from role if GPA is Less than 2.0 is two continuous semester
User Requirements
Users or end-users are the people who will use the software once it has been created.
User requirements are the tasks that these users can accomplish with the product, or what
the product can do for the user.
User Requirements [contd..]
They are part of the core functionality of the product.
For this reason, determining user requirements is usually very time consuming
User Requirements [contd..]
Many methods for expressing user requirements, including:
Use cases.
User stories.
Storyboards.
Scenarios.
Types of Requirements
We can divide requirements into five types
Functional requirements
Non-functional requirements
External interfaces
Physical product Requirements
Development constraints
Non-Functional requirements
Non-Functional requirements describe how well a product must perform.
Also known as quality requirements for this reason.
Address product issues including accuracy, dependability, security, usability, efficiency,
performance, and maintainability.
Non-Functional requirements [contd..]
Drawing on the online purchasing example used in functional requirements, a non-
functional requirement in the same scenario would be that emails shoul...
Non-functional requirements are usually complementary to functional requirements.
Types of Requirements
We can divide requirements into five types
Functional requirements
Non-functional requirements
External interfaces
Physical product Requirements
Development constraints
External Interfaces
Requirements related to how the product is situated within a larger system.
No concern with the physical environment of the product
Concerned with the relationship of the product to other entities outside the product.
External Interfaces [contd..]
For example, a software application that retrieves information from a remote database to
display to users sits between the entities of the database an...
An external interface is used between each one.
Types of Requirements
We can divide requirements into five types
Functional requirements
Non-functional requirements
External interfaces
Physical product Requirements
Development constraints
Physical Requirements
How the product needs to be designed in order to function in its physical environment.
For example, if a product was being developed for
underwater exploration, it would need to be waterproof.
Types of Requirements
We can divide requirements into five types
Functional requirements
Non-functional requirements
External interfaces
Physical product Requirements
Development constraints
Development Constraints
Development constraints affect everything from implementation technology, conventions,
documentation, and the process used to develop the product.
Development Constraints [contd..]
Refer to constraints related to creating the product, such as which devices or platforms will
be supported, or how much memory, bandwidth, or processi...
Similarly, if the product was designed for use in the desert, or in Antarctica, it would need to
withstand and function in those environments.
Software
Engineering
Week 14 Lecture 01
SOFTWARE DEPLOYMENT
Software deployment includes all the steps, processes, and activities that are required to
make a software system or update available to its intended ...
SOFTWARE DEPLOYMENT
Planning Building
Monitoring
Testing
Packaging
Planning
Define the deployment goals, requirements, and objectives.
Identify the target environment, including hardware, operating systems,
and software dependencies.
Plan for any necessary infrastructure setup, such as servers, databases, and network
configurations.
Prepare deployment documentation and instructions.
Building
Build the software application or package the required files and components.
Perform any necessary compilation, configuration, or build processes.
Include all the necessary dependencies and ensure version compatibility.
Testing
Conduct thorough testing of the software in a staging or testing environment.
Execute various test cases, including functional, performance, security, and compatibility
testing.
Address any identified issues, bugs, or performance bottlenecks.
Validate that the software meets the predefined quality standards.
Packaging
It is the process of bundling the necessary files, components, and dependencies of a
software application into a distributable format that can be easi...
The packaging process involves the software's files and resources, including executable
code, libraries, configuration files, data files, and any othe...
It also includes a user manual.
Deployment and Monitoring
Schedule a deployment window to minimize disruption to users.
Prepare the production environment, including servers, databases,
and configurations.
Follow a defined deployment plan or workflow, ensuring proper sequencing and
coordination.
Monitor the deployment process and address any issues or errors promptly.
Deployment and Monitoring [contd..]
Here are some key areas to monitor during software deployment:
System Performance: Monitor the system's CPU usage, memory utilization, disk I/O, and
network performance. This helps identify resource bottlenecks, p...
Deployment and Monitoring [contd..]
Here are some key areas to monitor during software deployment:
Error and Exception Tracking: Monitor and log application errors, exceptions, and other
abnormal behaviors. This helps identify and diagnose issues qu...
Deployment and Monitoring [contd..]
Here are some key areas to monitor during software deployment:
Log Monitoring: Monitor application logs to track system events, user activities, and error
messages
Resource Utilization: Monitor the usage of system resources, such as CPU, memory, disk
space, and network bandwidth.
Deployment Team
Deployment teams include people from different teams working on the project. It consists
of following:
Project Manager: Oversees the entire deployment process, coordinates the team's activities,
manages timelines, and ensures adherence to project object...
Deployment Manager: Plans, coordinates, and executes the deployment process, ensuring
that software is properly packaged, configured, and deployed to ...
Deployment Team [contd..]
Deployment teams include people from different teams working on the project. It consists
of following:
Quality Assurance/Testers: Conduct testing and validation activities to ensure the software
meets the desired quality standards and works as intended ...
Release Manager: Coordinates and manages the release process, including version control,
release notes, and communication with stakeholders.
Deployment Team [contd..]
Deployment teams include people from different teams working on the project. It consists
of following:
Developers: Supports the deployment process by automating various aspects of software
delivery
Technical Support: Provides ongoing support to end-users and addresses any issues or
questions that arise after the software is deployed.
Deployment Team [contd..]
Deployment teams include people from different teams working on the project. It consists
of following:
Documentation Specialist: Creates and maintains documentation related to the software
deployment process, including user guides, installation instruct...
Software
Engineering
Week 10 Lecture 01
CODING STYLES
The coding is the process of transforming the design of a system into a computer language
format.
In software development, coding phase is the conversion of gathered requirements into
realization.
Goal of Coding
The goal is not to reduce the effort and cost of the coding phase, but to cut to the cost of a
later stage.
The cost of testing and maintenance can be significantly reduced with efficient coding.
Goal of Coding [contd..]
To translate the design of system into a computer language format:
Goal of Coding [contd..]
To reduce the cost of later phases:
Reduce the cost of testing and maintenance.
Example:
Goal of Coding [contd..]
int main() { int num;
cout << "Enter a number: "; cin >> num;
// Check if the number is prime
bool isPrime = true;
for (int i = 2; i < num; i++) { if (num % i == 0) {
isPrime = false; break;
// Display the result if (isPrime) {
cout << num << " is a prime number." << endl;
} else {
cout << num << " is not a prime number." << endl;
return 0;
Goal of Coding [contd..]
Issues with the code:
Single function: As the code grows, it will become difficult to manage and maintain all the
logic.
No error handling: Code doesn’t handle invalid input scenarios, e.g., if user enters non-
numeric values.
Goal of Coding [contd..]
bool isPrime(int num) { if (num <= 1) {
return false;
}
for (int i = 2; i * i <= num; i++) {
if (num % i == 0) { return false;
return true;
int main() { int num;
cout << "Enter a number: "; cin >> num;
if (isPrime(num)) {
cout << num << " is a prime number." << endl;
} else {
cout << num << " is not a prime number." << endl;
return 0;
Goal of Coding [contd..]
Improvements in the code:
Separate function: This modification makes the code more manageable and allows specific
functionalities to be tested independently.
Error Handling: The code checks that the user provides a positive number before
performing the prime number check.
Goal of Coding [contd..]
Making the program more readable: a clear coding activity can itself help in producing more
maintainable software.
Example:
Goal of Coding [contd..]
#include<iostream>
using namespace std; int main(){int a=10;int b=5;int s=a+b;cout<<“The sum
is:"<<s<<endl;return 0;}
#include <iostream> using namespace std; int main() {
int num1 = 10; int num2 = 5;
int sum = num1 + num2;
cout << "The sum of " << num1 << " and "
<< num2 << " is: " << sum << endl; return 0;
Characteristics of Programming Language
Readability: Allow programs to be written in way that are self descriptive (in English
language)
Portability: Allow code to run on different platforms without significant changes.
Error checking: Invoke error handling to check and handle runtime errors and exceptions.
Characteristics of Programming Language [contd..]
Modularity: Allow breaking down code into reusable modules or functions, enabling
organization and code reuse.
Abstraction: Provide mechanisms hiding complex implementation details and simplify
programming tasks.
Efficiency: Authorize the creation of an efficient object code.
Characteristics of Programming Language [contd..]
Coding Standards
General coding standards refers to how the developer writes code, so here we will discuss
some essential standards regardless of the programming langu...
Coding Standards [contd..]
Indentation: (the practice of adding spaces or tabs at the beginning of a line of code to
visually represent the hierarchical structure)
To make program readable and maintainable, proper indentation in necessary.
Example:
Coding Standards [contd..]
Inline comments: To analyze the working of functions and highlight key aspects of code.
Don’t use GOTO statement: Difficult to follow and maintain code and lead to unstructured
and spaghetti-like code.
Naming conventions: global variable names always begin with a capital letter, local variable
names are made of small letters, and constant names are a...
Coding Standards [contd..]
Error return conventions and exception handling system: Code should contain error
handling mechanisms.
Example: If a user doesn’t enter the data of required datatype, the program should through
and exception instead of being closed altogether.
Exception Handling code
#include <stdexcept> int main() {
try {
int num;
cout << "Enter an integer: ";
cin >> num;
if ([Link]())
// Rest of the code logic here...
cout << "Entered integer: " << num << endl;
catch (const exception& e) {
cout << "Exception occurred: " << [Link]() << endl;
return 0;
throw runtime_error("Invalid input. Expected an integer.");
}
Programming Style
Clarity and simplicity of Expression: The programs should be designed in such a manner so
that the objectives of the program is clear.
Example: int result = a + b * c / d - e;
Modified code: int result = (a + b) * (c / d) - e;
Programming Style [contd..]
Naming: Names of module should be clear.
Example: a = 3.14 * r * r
Modified Example: area of circle = 3.14*radius*radius;
Information hiding: The information secure in the data structures should be hidden from
the rest of the system where possible.
Programming Style [contd..]
Nesting: Deep nesting of loops and conditions greatly harm the static and dynamic behavior
of a program
User-defined types: Make heavy use of user-defined data types like enum, class, structure,
and union.
Software
Engineering
Week 12 Lecture 01
SOFTWARE TESTING STRATEGIES
A plan that outlines the testing objectives, methods, and activities to be followed for a
software project.
Provides a roadmap for the testing process, ensuring that the right types of tests are
performed at various stages of the SDLC.
Integration Testing
A type of software testing in which the different units, modules or components of a software
application are tested as a combined entity.
But if they all work individually, why do you doubt that they’ll work when we put them
together?
The problem, of course, is “putting them together”— interfacing.
Integration Testing [contd..]
Example: Application has 3 modules say, ‘Login Page’, ‘Items’ and ‘Item details’ and each of
them is integrated logically.
We will not concentrate on the individual page here (as it’s already done in unit testing),
instead we will check how they are linked to each other.
Integration Testing [contd..]
Integration Testing [contd..]
Types of Integration Testing:
Top-Down Integration
Bottom-Up Integration
Big Bang Integration
Integration Testing [contd..]
Top-Down Integration
Testing starts with the highest-level components/modules and progresses downwards.
Stub or dummy implementations are used for the lower- level components that are not yet
integrated.
Allows for early testing of higher-level functionalities and facilitates early bug detection.
Integration Testing [contd..]
Top-Down Integration
Integration Testing [contd..]
Top-Down Integration
Example: Consider a website with the following components:
Shopping Cart Module 4
Payment Gateway Module 5
User Authentication Module 2
User Interface (UI) 1
Product Catalog Module 3
Integration Testing [contd..]
Products Catalog Shopping Cart
Top-Down Integration
U-shop
Front page UI User authentication
Payment Gateway
Integration Testing [contd..]
Bottom-Up Integration
Testing starts with the lowest-level components/modules as clusters and progresses
upwards.
Drivers are used for the higher-level components that are not yet integrated.
Allows for early testing of lower-level functionalities and facilitates early bug detection.
Integration Testing [contd..]
Big Bang Integration
All the individual components of a system are combined and tested together
simultaneously.
In this approach, the integration testing phase occurs as a single event, usually towards the
end of the development process.
Integration Testing [contd..]
Big Bang Integration:
Consider an e-commerce website with the following components:
User Registration Module
Product Catalog Module
Shopping Cart Module
Payment Gateway Integration
Integration Testing [contd..]
Big Bang Integration:
With the Big Bang Integration approach, all these modules are developed independently
and tested individually.
Once all the modules are ready, they are integrated together in a single event, and the entire
system is tested.
Integration Testing [contd..]
Big Bang Integration:
System Testing
A type of software testing that evaluates the complete and integrated system.
Focuses on testing the system's behavior and functionality against the specified
requirements.
System Testing [contd..]
Types of system testing:
Recovery Testing
Security Testing
Stress Testing
Performance Testing
Deployment Testing
System Testing [contd..]
Recovery Testing is a system test that forces the software to fail in a variety of ways and
verifies that recovery is properly performed.
If recovery is not automatic and require human intervention, the time is measured to
determine if it is in acceptable limits.
System Testing [contd..]
Security Testing validates the system's security measures and identify potential
vulnerabilities or weaknesses.
This involves testing authentication, access controls, data encryption, and protection
against common security threats.
System Testing [contd..]
Stress Testing executes a system in a manner that demands resources in abnormal quantity,
frequency, or volume.
For example, input data rates may be increased by an order of magnitude to determine how
input functions will respond
System Testing [contd..]
Performance Testing evaluates the system's performance under expected workloads and
stress conditions.
This includes testing response times, throughput, resource utilization, and scalability.
System Testing [contd..]
Deployment Testingexercises the software in each environment in
which it is to operate.
Because the software must execute on a variety of platforms and under more than one
operating system environment.
Software
Engineering
Week 09 Lecture 01
SOFTWARE DESIGN PRINCIPLES
Software design principles are a set of guidelines that helps developers to make a good
system design.
The most important principle is SOLID principle.
These principles lead to better code for readability, maintainability,
design patterns, and testability.
SOFTWARE DESIGN PRINCIPLES [contd..]
SOLID is combination of five basic designing principles.
Single Responsibility Principle (SRP)
Open/Closed Principle (OCP)
Liscov Substitution Principle (LSP)
Interface Segregation Principle (ISP)
Dependency Inversion Principle (DIP)
Single Responsibility Principle
This principle states that you should design your classes in such a way that each class
should have a single purpose.
Example - Account class is responsible to manage current and saving account.
Single Responsibility Principle [contd..]
Open/Closed Principle (OCP)
This principle states that software entities (classes, modules, functions, etc.) should be open
for extension but closed for modification.
The "closed" part of the rule states that once a module has been developed and tested, the
code should only be changed to correct bugs.
The "open" part says that you should be able to extend existing code in order to introduce
new functionality.
Open/Closed Principle (OCP) [contd..]
Example: Payment class.
Contains all basic payment related properties and methods.
Can be extended by
different payment method classes
Liscov Substitution Principle (LSP)
This principle states that “objects of a superclass should be replaceable with objects of its
subclasses without affecting the correctness of the prog...
Subclasses are allowed to extend the behavior of the superclass but must not change or
weaken the behavior defined by the superclass.
Example: Shape Class
Liscov Substitution Principle (LSP) [contd..]
def print_area(shape):
area = [Link]()
print(f"The area of the shape is: {area}")
rectangle = Rectangle(4, 6) square = Square(5)
print_area(rectangle) # Output:
of the shape is: 24
The area
Square
+area()
print_area(square) # Output: The area of
the shape is: 25
Interface Segregation Principle (ISP)
This principle states that “Clients should not be forced to depend upon interfaces that they
don’t use”.
Create smaller, focused interfaces that are specific to the needs of the clients, rather than
having a large, monolithic interface that encompasses al...
Interface Segregation Principle (ISP) [contd..]
Example: Printer Class
4-Interface Segregation Principle (ISP) [contd..]
4-Interface Segregation Principle (ISP) [contd..]
Dependency Inversion Principle
(DIP)
This principle states that
High level modules should not depend upon low level modules. Both should depend upon
abstractions.
Abstractions should not depend upon details. Details should depend upon abstractions.
SOFTWARE DESIGN PRINCIPLES [contd..]
Other principles:
DRY (Don’t Repeat Yourself)
KISS (Keep it simple, Stupid!)
YAGNI (You ain't gonna need it)
DRY (Don’t Repeat Yourself)
This principle states that each small pieces of knowledge (code) may only occur exactly
once in the entire system. This helps us to write scalable, ma...
KISS (Keep it simple, Stupid!)
This principle states that try to keep each small piece of software simple and unnecessary
complexity should be avoided. This helps us to write easy m...
YAGNI (You ain't gonna need it)
This principle states that always implement things when you actually need them never
implements things before you need them.
Software
Engineering
Week 07 Lecture 01
RECAP
Class-based modeling
Association: the type of relationship between classes.
Exactly one (1)
Zero to Many (0 … *)
Zero or one (0 … 1)
One to Many (1 … *)
Many to Many (* … *)
Association is a has-a relationship
Class-based modeling [contd..]
Dependency:
Class-based modeling [contd..]
Generalization:
Class-based modeling [contd..]
Aggregation:
Class-based modeling [contd..]
Composition:
Class-based modeling [contd..]
Association
Example:
Online Shopping
Scenario-based modeling
Activity Diagram
Example:
Behavioral modeling [contd..]
Components of a sequence diagram
Flow-oriented Modeling
Data Flow Diagram (DFD)
Graphically shows the flow of data between different components
or modules.
The system or process is represented by a collection of interconnected modules, called
processes.
Data Flow Diagram (DFD) [contd..]
Source
Components of DFD:
External entity: an outside system that sends or receives
data, communicating with the system being diagrammed.
Process: any process that changes the data, producing an output
Data store: files or repositories that hold information for later use, such as a database table
Data Flow Diagram (DFD) [contd..]
Components of DFD:
Data flow: the route that data takes between the external entities, processes and data stores.
External Entity Process Data Store Data Flow
Data Flow Diagram (DFD) [contd..]
Rules of DFD:
Each process should have at least one input and an output.
Each data store should have at least one data flow in and one data flow out.
Data stored in a system must go through a process.
All processes in a DFD go to another process or a data store.
Data can’t flow from external entity to external entity or data store.
Data Flow Diagram (DFD) [contd..]
Levels of DFD:
A data flow diagram can have many levels depending on the details of the system.
DFD levels are numbered 0,1,2 and so on.
DFD level 0 (also called Context Diagram) is the basic high-level view of the whole system.
Data Flow Diagram (DFD) [contd..]
Levels of DFD:
Level 0 diagram of Hotel Reservation system.
Data Flow Diagram (DFD) [contd..]
Levels of DFD:
DFD level 1 is a more detailed view of Context Level Diagram, providing the functionalities
of processes.
Data Flow Diagram (DFD) [contd..]
Levels of DFD:
DFD level 2 is the more detailed view of processes of DFD
Entity-Relation Diagram
An Entity-Relationship Diagram (ERD) is a graphical representation of entities and their
relationships to each other in a system.
Entity-Relation Diagram
Steps for creating ERD
Identify the entities
Define the relationships
Assign attributes to the entities
Find Identifier
Draw the ERD
Entity-Relation Diagram [contd..]
Entity: object having physical existence
Attributes: properties
Identifier: unique attribute
Connectivity: association
Entity-Relation Diagram [contd..]
Entity-Relation Diagram [contd..]
A system for managing student course registration would need data about courses,
instructors, course sections, course seats, and students; these are e...
Entity-Relation Diagram [contd..]
Software
Engineering
Week 11 Lecture 01
SOFTWARE TESTING STRATEGIES
A plan that outlines the testing objectives, methods, and activities to be followed for a
software project.
Provides a roadmap for the testing process, ensuring that the right types of tests are
performed at various stages of the SDLC.
Component Testing
Component testing, also known as unit testing, is a type of software testing that focuses on
testing individual components or units of code in isolati...
Testing each component independently to ensure its functionality, correctness, and
compliance with the expected behavior.
Component Testing Consideration
Interface is tested: to ensure proper information flow.
Data structures are examined: to ensure integrity of data.
Control structures are exercised: to verify all paths.
Boundary conditions are tested: to ensure that the module operates properly at established
limit or restriction.
Error-handling paths are tested
Component Testing Consideration [contd..]
Interface is tested: to ensure proper information flow.
Example: there is an interface that allows users to upload files.
Component Testing Consideration [contd..]
Data structures are examined: to ensure integrity of data.
Example: there is a data structure that stores customer account information.
Component Testing Consideration [contd..]
Control structures are exercised: to verify all paths.
Example: there is a control
About
Contact
structure that determines the flow of
Home Menu Us Us
user navigation through different pages or sections.
Menu
About Us
Contact Us
Services
Items
Details
Vision
Mission
Scope
Email
Social Media
Phone No.
Component Testing Consideration [contd..]
Boundary conditions are tested: to ensure that the module operates properly at established
limit or restriction.
Example: there is a requirement that user inputs are within specific limits.
Component Testing Consideration [contd..]
Error-handling paths are tested
Example: there is a module that performs calculations based on user inputs.
Component Testing Procedures
These procedures are applied before coding begins and after source code has been
generated.
Multiple test cases are created and tested on the code to review the functionality and
behavior of code.
Component Testing Procedures [contd..]
As the components are not stand-alone programs, driver or stubs are created for testing.
Driver: a “main program” that accepts test-cases
Stub: replacement of modules that are (invoked by) the component to be tested.
Component Testing Procedures [contd..]
Example: we have a function called calculateTotalPrice()
that calculates the total price of items in a shopping cart.
This function relies on two external functions: getProductPrice() and getProductQuantity()
which are not yet implemented.
Component Testing Procedures [contd..]
Component Testing Procedures Example
Let us write test cases for a given scenario.
An online shopping system allows user to register their selves to enter the system and
already registered users can login by providing email and passw...
Name, Address to be shipped to, Phone number, Credit card number
Design the required interfaces and make testcases for each interface.
TESTING CONCEPTS FOR WEBAPPS
Dimensions of Quality:
Quality is incorporated into a Web application as a good design.
It is evaluated by applying a series of technical reviews that assess various elements of the
design model.
TESTING CONCEPTS FOR WEBAPPS [contd..]
Following dimensions of Quality are examined:
Content:
syntactic (spelling, punctuation, and grammar)
semantic level(correctness, consistency, no ambiguity)
Function: conformance to customer requirements.
TESTING CONCEPTS FOR WEBAPPS [contd..]
Following dimensions of Quality are examined:
Structure: proper delivery of function and content, and
extensibility.
Usability: user friendly.
Performance: system is responsive to user interaction.
Security: testing potential vulnerabilities and attempting to exploit each.
TESTING CONCEPTS FOR WEBAPPS [contd..]
Testing Strategy:
The content model for the WebApp is reviewed to uncover errors.
The interface model is reviewed to ensure that all use cases can be accommodated.
The design model for the WebApp is reviewed to
uncover navigation errors.
The user interface is tested to uncover errors in presentation and/or navigation mechanics.
Selected functional components are unit tested.
TESTING CONCEPTS FOR WEBAPPS [contd..]
2- Testing Strategy:
Navigation throughout the architecture is tested.
The WebApp is implemented in a variety of different environmental configurations and is
tested for compatibility with each configuration.
Security tests are conducted to exploit vulnerabilities in the WebApp or within its
environment.
Performance tests are conducted.