UML Diagrams:

Structural Diagrams – Capture static aspects or structure of a system:

-Class Diagrams: depict the structure of a system by showing the system’s classes, their attributes,
operations (or methods), and the relationships among objects.

-Object Diagrams: show a complete or partial view of the structure of a modeled system at a specific
time.

-Component Diagrams: depict how components are wired together to form larger components or
software systems.

-Deployment Diagrams: model the physical deployment of artifacts on nodes.

-Behavioral Diagrams: capture dynamic aspects or behavior of the system:

Use Case Diagrams - represent the functionality provided by a system in terms of actors, their
goals (represented as use cases), and any dependencies between those use cases.
-State Diagrams: describe the behavior of a system by depicting its states and the events that cause the
system to change state.

-Activity Diagrams: represent workflows of stepwise activities and actions with support for choice,
iteration and concurrency.

-Interaction Diagrams: depict interactions between objects in terms of sequenced messages.

Test Techniques:
A list of some common types of software testing, organized by their purpose:

Verifying functionality:
- Unit testing: verifies the functionality of individual units or components of the software.

- Integration testing: verifies that different modules or services used by the software work well together.

- Functional testing: verifies that the software functions as intended and meets the specified
requirements.

- Acceptance testing: verifies that the software meets the acceptance criteria and is ready for release to
the customer.
- Smoke testing: verifies that the main features of the software work properly and exposes simple
failures severe enough to reject a prospective software release.

- Regression testing: verifies that changes to the software do not adversely affect existing functionality.

- System testing: a level of software testing where a complete and integrated software system is tested.
The purpose of this test is to evaluate the system’s compliance with the specified requirements.

- Component testing: once unit testing is done, component testing allows testers to test multiple units or
components in a single code.

Evaluating performance and reliability:

- Performance testing: measures how well the software performs under various conditions, such as high
load or stress.

- Load testing: measures the performance of the software under heavy load or high user traffic.

- Stress testing: measures the stability and reliability of the software under extreme conditions, such as
low memory or high CPU usage.

- Recovery testing: verifies that the software can recover from failures or errors and resume normal
operation.

- End-to-End testing: End-to-end testing helps in testing the functionality and performance of the
product – under live settings.

Ensuring usability and accessibility:

- Usability testing: evaluates how easy it is for users to use the software and accomplish their tasks.

- Accessibility testing: verifies that the software is accessible to users with disabilities and complies with
accessibility standards.

Verifying compatibility and installation:

- Compatibility testing: verifies that the software is compatible with different operating systems,
browsers, and devices.

- Installation testing: verifies that the software can be installed and uninstalled correctly on the target
system.
Exploring potential issues or areas for improvement:
- Exploratory testing: involves exploring the software to identify potential issues or areas for
improvement.

- Ad-hoc testing: involves randomly testing the software without any formal test plan or test cases.

Verifying security and compliance:

- Security testing: verifies that the software is secure and protects against unauthorized access or
attacks.

Designing Test Cases: Black Box Testing Techniques:

Equivalence Partitioning: This technique involves dividing the input domain of a program into classes of
data from which test cases should be designed. The concept behind this technique is that a test case of a
representative value of each class is equal to a test of any other value of the same class.

Boundary Value Analysis: This technique is based on testing at the boundaries between partitions. It
includes maximum, minimum, inside or outside boundaries, typical values and error values. The
behavior at the edge of each equivalence partition is more likely to be incorrect than the behavior within
the partition, so boundaries are an area where testing is likely to yield defects.

Decision Table: This technique is appropriate for functionalities which have logical relationships between
inputs (if-else logic). In the Decision table technique, combinations of inputs are dealt with. To identify
the test cases with the decision table, conditions and actions are considered. Conditions are taken as
inputs and actions as outputs.

State Transition: This technique involves picking test cases from an application where different system
transitions need to be tested. It can be applied when an application gives a different output for the same
input, depending on what has happened in the earlier state.

Error Guessing: This technique involves using experience and intuition to guess where errors might occur
in a program and then designing test cases to expose those errors.

Designing Test Cases: White Box Testing Techniques:

Control Flow Testing: This technique involves testing the execution order of statements or instructions in
a program to ensure that control structures (such as loops and conditionals) are working correctly.

Data Flow Testing: This technique involves testing the interactions between different data objects in a
program to ensure that data is being stored, accessed, and modified correctly.
Statement Coverage: This technique involves testing all executable statements in a program at least
once to ensure that all lines of code have been tested.

Branch Coverage: This technique involves testing all branches in a program at least once to ensure that
all possible execution paths have been tested.

Path Coverage: This technique involves testing all possible paths through a program at least once to
ensure that all possible combinations of execution paths have been tested.

Software Development Models:

Linear and Sequential Models – These models follow a linear and sequential approach where
each phase must be completed before the next one can begin:
- Waterfall Model: (A linear sequential approach where each phase must be completed before the next
one can begin) The Waterfall Model is a linear sequential approach to software development where each
phase must be completed before the next one can begin. This model is often used for projects with well-
defined requirements and a clear understanding of the final product. The stages of the Waterfall Model
include:

 Requirement Analysis: (gathering and documenting user requirements) This stage involves
gathering and documenting user requirements. The goal is to understand what the users need
and want from the system.
 System Design: (defining the overall system architecture) In this stage, the overall system
architecture is defined. This includes defining the hardware and software requirements, as well
as the overall structure of the system.
 Implementation: (coding and development) During this stage, the actual coding and
development of the system takes place. The goal is to translate the design into a working system.
 Testing: (verifying that the system meets the requirements) In this stage, the system is tested to
verify that it meets the requirements defined in the Requirement Analysis stage. This includes
both functional testing (to ensure that the system works as intended) and non-functional testing
(to ensure that the system meets performance, security, and other non-functional
requirements).
 Deployment: (delivering the system to the users) Once testing is complete, the system is
delivered to the users. This may involve installing the system on the user’s hardware or making it
available through a web or cloud-based interface.
 Maintenance: (providing ongoing support and updates) After deployment, ongoing support and
updates are provided to ensure that the system continues to meet user needs. This may include
fixing bugs, adding new features, or updating the system to work with new hardware or
software.
- V-Model: (An extension of the Waterfall model that emphasizes verification and validation) The V-
Model is an extension of the Waterfall Model that emphasizes verification and validation. Like the
Waterfall Model, it follows a linear and sequential approach where each phase must be completed
before the next one can begin. However, the V-Model also includes a corresponding testing phase for
each development phase, forming a “V” shape when visualized. The stages of the V-Model include:

 Requirement Analysis: (gathering and documenting user requirements) This stage involves
gathering and documenting user requirements. The goal is to understand what the users need
and want from the system.
 System Design: (defining the overall system architecture) In this stage, the overall system
architecture is defined. This includes defining the hardware and software requirements, as well
as the overall structure of the system.
 Architectural Design: (defining the high-level design) In this stage, the high-level design of the
system is defined. This includes defining the major components of the system and their
interactions.
 Module Design: (defining the low-level design) In this stage, the low-level design of the system is
defined. This includes defining the individual modules and their interfaces.
 Coding & Unit Testing: (coding and testing individual modules) During this stage, the actual
coding and development of the individual modules takes place. Each module is also tested to
ensure that it works correctly.
 Integration Testing: (testing the integration of modules) In this stage, the individual modules are
combined and tested together to ensure that they work correctly as a whole.
 System Testing: (testing the entire system) In this stage, the entire system is tested to verify that
it meets the requirements defined in the Requirement Analysis stage. This includes both
functional testing (to ensure that the system works as intended) and non-functional testing (to
ensure that the system meets performance, security, and other non-functional requirements).
 Acceptance Testing: (verifying that the system meets user requirements) In this final stage, the
system is tested by the users to verify that it meets their needs and expectations.

Iterative and Incremental Models – These models involve developing the software in small
chunks, with each chunk building upon the previous one:
- Iterative Model: (An approach that involves developing the software in small chunks, with each chunk
building upon the previous one) The Iterative Model is an approach to software development that
involves developing the software in small chunks, with each chunk building upon the previous one. This
model is often used for projects where the requirements are not well-defined or are likely to change
during the development process. The stages of the Iterative Model include:

 Planning: (defining the scope of the iteration) This stage involves defining the scope of the
iteration. The goal is to determine what will be developed during this iteration.
 Requirements Analysis & Design: (gathering and analyzing user requirements, designing the
system) In this stage, user requirements are gathered and analyzed, and the system is designed.
The goal is to understand what the users need and want from the system, and to create a design
that meets those needs.
  Implementation & Testing: (coding, testing, and integrating the system) During this stage, the
system is coded, tested, and integrated. The goal is to translate the design into a working system
and to verify that it meets the requirements.
 Evaluation: (evaluating the system and planning for the next iteration) In this final stage, the
system is evaluated, and plans are made for the next iteration. The goal is to assess how well the
system meets user needs and to identify any changes that need to be made in the next iteration.

- Incremental Model: (An approach that involves delivering the software in increments, with each
increment adding new functionality). The Iterative Model is an approach to software development that
involves developing the software in small chunks, with each chunk building upon the previous one. This
model is often used for projects where the requirements are not well-defined or are likely to change
during the development process. The stages of the Iterative Model include:

 Planning: (defining the scope of the increment, gathering, and analyzing user requirements) This
stage involves defining the scope of the iteration. The goal is to determine what will be
developed during this iteration.
 Requirements Analysis & Design: (designing, coding, testing, and integrating the increment) In
this stage, user requirements are gathered and analyzed, and the system is designed. The goal is
to understand what the users need and want from the system, and to create a design that meets
those needs.
 Implementation & Testing: (delivering and testing the increment) During this stage, the system is
coded, tested, and integrated. The goal is to translate the design into a working system and to
verify that it meets the requirements.
 Evaluation: In this final stage, the system is evaluated, and plans are made for the next iteration.
The goal is to assess how well the system meets user needs and to identify any changes that
need to be made in the next iteration.

The process then repeats, with each iteration building upon the previous one until the final product
is complete.

- Spiral Model: (A risk-driven approach that combines elements of the Waterfall and Agile models) The
Spiral Model is a risk-driven approach to software development that combines elements of the Waterfall
and Agile models. This model is often used for large and complex projects where risks need to be
carefully managed. The stages of the Spiral Model include:

 Planning & Requirements Analysis: (defining the scope of the iteration, gathering, and
analyzing user requirements) This stage involves defining the scope of the iteration and
gathering and analyzing user requirements. The goal is to determine what will be developed
during this iteration and to understand what the users need and want from the system.
 Risk Analysis & Prototyping: (identifying and mitigating risks, developing a prototype) In this
stage, risks are identified and mitigated, and a prototype of the system is developed. The goal is
to identify potential risks and to develop a prototype that can be used to gather feedback from
users.
 Development & Testing: (coding, testing, and integrating the system) During this stage, the
system is coded, tested, and integrated. The goal is to translate the design into a working system
and to verify that it meets the requirements.
  Evaluation: (evaluating the system and planning for the next iteration) In this final stage, the
system is evaluated, and plans are made for the next iteration. The goal is to assess how well the
system meets user needs, to identify any changes that need to be made in the next iteration,
and to plan for risk management in the next iteration.

The process then repeats, with each iteration building upon the previous one until the final product
is complete.

- Rational Unified Process (RUP): The Rational Unified Process (RUP) is an iterative approach to software
development that divides the process into four phases – inception, elaboration, construction, and
transition. Each phase includes several iterations of Business Modeling, Requirements Analysis & Design,
Implementation & Testing. The stages of the RUP model include:

 Inception: This phase involves defining the scope of the project and gathering initial
requirements. The goal is to determine the feasibility of the project and to establish a vision for
the final product.
o Business Modeling: In this stage, the business processes and workflows are modeled to
understand how the system will support the business.
o Requirements Analysis & Design: In this stage, initial user requirements are gathered
and analyzed.
o Implementation & Testing: No implementation or testing takes place during this phase.
 Elaboration: In this phase, the requirements are refined, and the system architecture is defined.
The goal is to develop a detailed understanding of the user requirements and to create a stable
architectural foundation for the system.
o Business Modeling: In this stage, the business model is refined based on feedback from
users and stakeholders.
o Requirements Analysis & Design: In this stage, user requirements are further refined
and analyzed, and the system architecture is designed.
o Implementation & Testing: No implementation or testing takes place during this phase.
 Construction: During this phase, the system is developed and tested. The goal is to build a
working system that meets the user requirements.
o Business Modeling: No business modeling takes place during this phase.
o Requirements Analysis & Design: In this stage, any remaining requirements are
finalized, and design work continues as needed.
o Implementation & Testing: In this stage, the system is coded, tested, and integrated.
 Transition: In this final phase, the system is deployed and transitioned to the users. The goal is to
ensure that the system is successfully integrated into the user’s environment and that any
necessary training or support is provided.
o Business Modeling: No business modeling takes place during this phase.
o Requirements Analysis & Design: No requirements analysis or design takes place during
this phase.
o Implementation & Testing: In this stage, any final testing or bug fixing takes place.

Short note on each phase:

o Business Modeling - (understanding and modeling business processes)
 o Requirements Analysis & Design - (gathering and analyzing user requirements, designing
the system)
o Implementation & Testing - (coding, testing, and integrating the system).

Agile Models – These models emphasize flexibility and customer satisfaction:

- Agile Model: (An iterative and incremental approach that emphasizes flexibility and customer
satisfaction) The Agile Model refers to a software development approach based on iterative and
incremental development. Agile methods break tasks into smaller iterations, or parts that do not directly
involve long-term planning. The project scope and requirements are laid down at the beginning of the
development process. The phases in the Agile model are as follows:

 Requirements gathering: Define the requirements and evaluate technical and economic
feasibility.
 Design the requirements: Work with stakeholders to define requirements.
 Construction/iteration: Designers and developers start working on their project, which aims to
deploy a working product.
 Testing/Quality assurance: The Quality Assurance team examines the product’s performance
and looks for bugs.
 Deployment: The team issues a product for the user’s work environment.
 Feedback: The team receives feedback about the product and works through the feedback.

It is important to note that these stages are not necessarily sequential, as in traditional software
development models. Instead, they are often performed concurrently and iteratively, with constant
feedback and adaptation.

- Dynamic Systems Development Method (DSDM): An agile approach that emphasizes delivering
business value within a fixed time and budget. The stages include:

 Feasibility Study & Business Study (evaluating feasibility, understanding business processes)
 Functional Model Iteration & Design & Build Iteration (in sprints) (developing functional
prototypes during sprints)
 Implementation (in sprints) (delivering during sprints)
 Post-Project.

- Feature Driven Development (FDD): An iterative approach that focuses on delivering working software
frequently. The stages include:

 Develop Overall Model & Build Feature List (in sprints) (developing an overall model of the
system during sprints)
 Plan By Feature (in sprints) (planning for feature development during sprints)
 Design By Feature (in sprints) (designing features during sprints)
 Build By Feature (coding features during sprints).
Lastly let’s go through the Agile Framework. The Agile framework is an umbrella for several different
variations. Here are a few of the most common Agile methodologies under the agile framework:

 Scrum: A product is built in a series of fixed-length iterations called sprints, giving agile teams a
framework for shipping software on a regular cadence.
 Kanban: A popular agile framework that requires real-time communication of team’s capacity
and full transparency of work.
 Extreme Programming (XP): Aims to produce higher quality software and higher quality of life
for the development team. It is the most specific of the agile frameworks regarding appropriate
engineering practices for software development.
 Lean Software Development: An adaptation of Lean manufacturing and Lean IT principles to the
software development domain.

Prototyping Models – These models involve creating a working prototype of the software
before developing the final product:
-Prototyping Model: (An approach that involves creating a working prototype of the software before
developing the final product) The Prototyping Model is a systems development method in which a
prototype is built, tested, and then reworked as necessary until an acceptable outcome is achieved from
which the complete system or product can be developed. This model works best in scenarios where not
all the project requirements are known in detail ahead of time. It is an iterative, trial-and-error process
that takes place between the developers and the users:

 Define system requirements: (gathering user requirements) The new system requirements are
defined in as much detail as possible. This usually involves interviewing several users
representing all the departments or aspects of the existing system.
 Create preliminary design: (creating a quick design) A preliminary, simple design is created for
the new system.
 Build first prototype: (developing a prototype in iterations) A first prototype of the new system is
constructed from the preliminary design. This is usually a scaled-down system and represents an
approximation of the characteristics of the final product.
 Evaluate first prototype: (getting feedback from users in iterations) The users thoroughly
evaluate the first prototype and note its strengths and weaknesses, what needs to be added and
what should be removed.
 Revise and enhance prototype: (refining the prototype based on user feedback in iterations) The
developer collects and analyzes the remarks from the users. The first prototype is modified,
based on the comments supplied by the users, and a second prototype of the new system is
constructed.
 Iterate: (repeat) The preceding steps are iterated as many times as necessary, until the users are
satisfied that the prototype represents the final product desired.
 Construct final system: The final system is constructed, based on the final prototype.
 Test and evaluate final system: The final system is thoroughly evaluated and tested.
 Routine maintenance: Routine maintenance is carried out on a continuing basis to prevent
large-scale failures and to minimize downtime.
-Rapid Application Development (RAD): (An adaptive approach that emphasizes rapid prototyping and
iterative delivery). The Rapid Application Development (RAD) Model is an adaptive software
development model based on prototyping and quick feedback with less emphasis on specific planning. In
general, the RAD approach prioritizes development and building a prototype, rather than planning. With
rapid application development, developers can quickly make multiple iterations and updates to the
software without starting from scratch:

 Business Modeling: (understanding and modeling business processes in iterations) In this stage,
the flow of information between various business functions is identified and represented.
 Data Modeling: (understanding and modeling data in iterations) The information collected from
the Business Modeling stage is used to define data objects and their relationships.
 Process Modeling: (modeling business processes in iterations) The data objects defined in the
Data Modeling stage are transformed to achieve the business information flow.
 Application Generation: (generating the application in iterations) Automated tools are used to
convert process models into code and the actual system.
 Testing and Turnover: The overall testing time is reduced in the RAD model as prototypes are
independently tested during every iteration.

Collaborative Models – These models involve collaboration between stakeholders and

developers to define requirements and design the system:
-Joint Application Development (JAD): (An approach that involves collaboration between stakeholders
and developers to define requirements and design the system) Joint Application Development (JAD) is a
process in which business information is gathered for the development of new information technology
systems or to improve user involvement or develop and improve quality in systems. In this technique, IT
specialists and business users collaborate in discussion, project management and learning groups, talking
about the new information system. With the participation of both parties, it is possible to develop and
solve the requirements of the new software system in an easier way. The JAD process typically involves
the following phases:

 Preparation: (planning for JAD sessions) The project sponsor, stakeholders, and facilitator are
identified and a JAD session is scheduled. The agenda and objectives of the session are defined,
and the participants are invited and prepared.
 Session: (collaborating with stakeholders and developers during workshops) The JAD session
itself is a structured workshop in which the experts participate in interactive discussions and
decision-making activities to define the requirements and design for the software application.
 Documentation: (document session) The outcome of the JAD session is documented, including
detailed notes, sketches, and other materials generated during the session. The documentation
is used to create a final specification for the software application.
 Implementation: (design & development) The software development team uses the specification
created during the JAD session to build the application. Regular meetings between the
stakeholders and developers are held to ensure that the implementation meets their
expectations.
Minimal Planning Models – These models involve minimal planning and focus on coding and
development:
-Big Bang Model: (An approach that involves minimal planning and focuses on coding and development)
The Big Bang Model is a software development approach that starts from nothing and requires almost
no planning. It is the simplest model in the Software Development Life Cycle (SDLC) as it requires lots of
funds and coding and takes more time.

The product is gradually built as the requirements from the customer come, however, the end-product
might not meet the actual requirements.

The Big Bang Model does not have specific stages like other software development models. Instead, it
involves combining time, effort, and resources to build a product. The product requirements are
understood and implemented as they arrive. The complete modules or at least parts of the modules are
integrated and tested. All the modules are run separately, and the defective ones are removed to find
the cause.

This model is suitable for small projects when few people are working on the project, the customer’s
demands are not exact and keep changing, or if it is a dummy/side-project. As there is no proper
planning in this model, it is considered the worst SDLC model and is highly unsuitable for large projects.