UNIT 2: Software Development Activities

Software Engineering core principles, Communication, Planning, Modelling,

Construction & Deployment principles
Communication:

1. Clear Communication:

 Ensure effective communication among team members, stakeholders, and clients.

 Use clear and concise language to convey ideas and requirements.

2. Active Listening:

 Actively listen to understand the needs and concerns of team members and stakeholders.

 Encourage open communication and feedback.

3. Documentation:

 Document decisions, requirements, and code to facilitate understanding and future reference.

 Maintain up-to-date documentation for the project.

Planning:

1. Requirements Analysis:

 Thoroughly analyze and understand project requirements before starting development.

 Clearly define the scope, goals, and constraints of the project.

2. Project Planning:

 Develop a comprehensive project plan outlining tasks, timelines, and resource allocation.

 Plan for contingencies and potential changes during the development process.

3. Agile Methodologies:

 Embrace agile methodologies for flexibility and adaptability to changing requirements.

 Iterative development allows for continuous improvement and frequent releases.

Modeling:

1. UML (Unified Modeling Language):

 Use UML diagrams to model system architecture, design, and relationships between components.

 Enhance understanding and communication through visual representations.

2. Data Modeling:

 Design efficient and scalable databases using techniques such as entity-relationship diagrams.

 Normalize data to reduce redundancy and improve data integrity.

3. Prototyping:

 Develop prototypes to validate design ideas and gather feedback early in the development process.

 Iteratively refine prototypes based on user and stakeholder input.

 UNIT 2: Software Development Activities
Construction:

1. Code Quality:

 Write clean, modular, and maintainable code.

 Follow coding standards and best practices.

2. Testing:

 Implement thorough testing, including unit tests, integration tests, and system tests.

 Conduct code reviews to identify and address issues early in the development cycle.

3. Refactoring:

 Regularly refactor code to improve its structure, readability, and performance.

 Eliminate code smells and technical debt.

Deployment:

1. Continuous Integration/Continuous Deployment (CI/CD):

 Implement CI/CD pipelines for automated testing and deployment.

 Ensure a streamlined and reliable process for delivering updates.

2. Monitoring and Logging:

 Implement robust monitoring and logging to detect and address issues in real-time.

 Use analytics to gather insights into system performance and user behavior.

3. Rollback Strategies:

 Have contingency plans for rollbacks in case of deployment failures.

 Minimize downtime and user impact during updates.

Requirements Engineering Process in Software Engineering

Requirements engineering is the process of identifying, eliciting, analyzing, specifying, validating, and managing the
needs and expectations of stakeholders for a software system. In this article, we’ll learn about it’s process,
advantages and disadvantages.

What is Requirements Engineering?

A systematic and strict approach to the definition, creation and verification of requirements for a software system is
known as requirements engineering. In order to guarantee the effective creation of a software product, the
requirements engineering process entails a number of tasks that help in understanding, recording and managing the
demands of stakeholders.

Steps in Requirements Engineering Process

The requirements engineering process is an iterative process that involves several steps, including:

Requirements Elicitation

This is the process of gathering information about the needs and expectations of stakeholders for the software
system. This step involves interviews, surveys, focus groups, and other techniques to gather information from
stakeholders.
 UNIT 2: Software Development Activities
Requirements Analysis

This step involves analyzing the information gathered in the requirements elicitation step to identify the high-level
goals and objectives of the software system. It also involves identifying any constraints or limitations that may affect
the development of the software system.

Requirements Specification

This step involves documenting the requirements identified in the analysis step in a clear, consistent, and
unambiguous manner. This step also involves prioritizing and grouping the requirements into manageable chunks.

Requirements Validation

This step involves checking that the requirements are complete, consistent, and accurate. It also involves checking
that the requirements are testable and that they meet the needs and expectations of stakeholders.

Requirements Management

This step involves managing the requirements throughout the software development life cycle, including tracking
and controlling changes, and ensuring that the requirements are still valid and relevant.

Requirement Engineering

The Requirements Engineering process is a critical step in the software development life cycle as it helps to ensure
that the software system being developed meets the needs and expectations of stakeholders, and that it is
developed on time, within budget, and to the required quality.

Requirement Engineering is the process of defining, documenting and maintaining the requirements. It is a process
of gathering and defining service provided by the system. it is the disciplined application of proven principle ,
methods ,tools and notations to describe a proposed system’s intended behaviour and its associated constraints.

Tools Involved in Requirement Engineering

 observation report

 Questionnaire ( survey , poll )

 Use cases

 User stories

 Requirement workshop

 Mind mapping

 Role playing

 Prototyping

Requirements Engineering Process Consists of the Following Main Activities

 Requirements elicitation

 Requirements specification

 Requirements verification and validation

 Requirements management

1. Requirements Elicitation

It is related to the various ways used to gain knowledge about the project domain and requirements. The various
sources of domain knowledge include customers, business manuals, the existing software of same type, standards
 UNIT 2: Software Development Activities
and other stakeholders of the project. The techniques used for requirements elicitation include interviews,
brainstorming, task analysis, Delphi technique, prototyping, etc. Some of these are discussed here. Elicitation does
not produce formal models of the requirements understood. Instead, it widens the domain knowledge of the analyst
and thus helps in providing input to the next stage.

Requirements elicitation is the process of gathering information about the needs and expectations of stakeholders
for a software system. This is the first step in the requirements engineering process and it is critical to the success of
the software development project. The goal of this step is to understand the problem that the software system is
intended to solve, and the needs and expectations of the stakeholders who will use the system.

There are several techniques that can be used to elicit requirements, including:

 Interviews: These are one-on-one conversations with stakeholders to gather information about their needs
and expectations.

 Surveys: These are questionnaires that are distributed to stakeholders to gather information about their
needs and expectations.

 Focus Groups: These are small groups of stakeholders who are brought together to discuss their needs and
expectations for the software system.

 Observation: This technique involves observing the stakeholders in their work environment to gather
information about their needs and expectations.

 Prototyping: This technique involves creating a working model of the software system, which can be used to
gather feedback from stakeholders and to validate requirements.

It’s important to document, organize and prioritize the requirements obtained from all these techniques to ensure
that they are complete, consistent and accurate.

2. Requirements Specification

This activity is used to produce formal software requirement models. All the requirements including the functional as
well as the non-functional requirements and the constraints are specified by these models in totality. During
specification, more knowledge about the problem may be required which can again trigger the elicitation process.
The models used at this stage include ER diagrams, data flow diagrams(DFDs), function decomposition
diagrams(FDDs), data dictionaries, etc.

Requirements specification is the process of documenting the requirements identified in the analysis step in a clear,
consistent, and unambiguous manner. This step also involves prioritizing and grouping the requirements into
manageable chunks.

The goal of this step is to create a clear and comprehensive document that describes the requirements for the
software system. This document should be understandable by both the development team and the stakeholders.

There are several types of requirements that are commonly specified in this step, including

1. Functional Requirements: These describe what the software system should do. They specify the
functionality that the system must provide, such as input validation, data storage, and user interface.

2. Non-Functional Requirements: These describe how well the software system should do it. They specify the
quality attributes of the system, such as performance, reliability, usability, and security.

3. Constraints: These describe any limitations or restrictions that must be considered when developing the
software system.

4. Acceptance Criteria: These describe the conditions that must be met for the software system to be
considered complete and ready for release.
 UNIT 2: Software Development Activities
In order to make the requirements specification clear, the requirements should be written in a natural language and
use simple terms, avoiding technical jargon, and using a consistent format throughout the document. It is also
important to use diagrams, models, and other visual aids to help communicate the requirements effectively.

Once the requirements are specified, they must be reviewed and validated by the stakeholders and development
team to ensure that they are complete, consistent, and accurate.

3. Requirements Verification and Validation

Verification: It refers to the set of tasks that ensures that the software correctly implements a specific function.

Validation: It refers to a different set of tasks that ensures that the software that has been built is traceable to
customer requirements. If requirements are not validated, errors in the requirement definitions would propagate to
the successive stages resulting in a lot of modification and rework. The main steps for this process include:

1. The requirements should be consistent with all the other requirements i.e no two requirements should
conflict with each other.

2. The requirements should be complete in every sense.

3. The requirements should be practically achievable.

Reviews, buddy checks, making test cases, etc. are some of the methods used for this.

Requirements verification and validation (V&V) is the process of checking that the requirements for a software
system are complete, consistent, and accurate, and that they meet the needs and expectations of the stakeholders.
The goal of V&V is to ensure that the software system being developed meets the requirements and that it is
developed on time, within budget, and to the required quality.

1. Verification is the process of checking that the requirements are complete, consistent, and accurate. It
involves reviewing the requirements to ensure that they are clear, testable, and free of errors and
inconsistencies. This can include reviewing the requirements document, models, and diagrams, and holding
meetings and walkthroughs with stakeholders.

2. Validation is the process of checking that the requirements meet the needs and expectations of the
stakeholders. It involves testing the requirements to ensure that they are valid and that the software system
being developed will meet the needs of the stakeholders. This can include testing the software system
through simulation, testing with prototypes, and testing with the final version of the software.

3. V&V is an iterative process that occurs throughout the software development life cycle. It is important to
involve stakeholders and the development team in the V&V process to ensure that the requirements are
thoroughly reviewed and tested.

It’s important to note that V&V is not a one-time process, but it should be integrated and continue throughout the
software development process and even in the maintenance stage.

4. Requirements Management

Requirement management is the process of analyzing, documenting, tracking, prioritizing and agreeing on the
requirement and controlling the communication to relevant stakeholders. This stage takes care of the changing
nature of requirements. It should be ensured that the SRS is as modifiable as possible so as to incorporate changes in
requirements specified by the end users at later stages too. Being able to modify the software as per requirements in
a systematic and controlled manner is an extremely important part of the requirements engineering process.

Requirements management is the process of managing the requirements throughout the software development life
cycle, including tracking and controlling changes, and ensuring that the requirements are still valid and relevant. The
goal of requirements management is to ensure that the software system being developed meets the needs and
expectations of the stakeholders and that it is developed on time, within budget, and to the required quality.
 UNIT 2: Software Development Activities
There are several key activities that are involved in requirements management, including:

1. Tracking and controlling changes: This involves monitoring and controlling changes to the requirements
throughout the development process, including identifying the source of the change, assessing the impact of
the change, and approving or rejecting the change.

2. Version control: This involves keeping track of different versions of the requirements document and other
related artifacts.

3. Traceability: This involves linking the requirements to other elements of the development process, such as
design, testing, and validation.

4. Communication: This involves ensuring that the requirements are communicated effectively to all
stakeholders and that any changes or issues are addressed in a timely manner.

5. Monitoring and reporting: This involves monitoring the progress of the development process and reporting
on the status of the requirements.

Requirements management is a critical step in the software development life cycle as it helps to ensure that the
software system being developed meets the needs and expectations of stakeholders, and that it is developed on
time, within budget, and to the required quality. It also helps to prevent scope creep and to ensure that the
requirements are aligned with the project goals.

Advantages and Disadvantages

The advantages and disadvantages of the requirements engineering process in software engineering include:

Advantages

 Helps ensure that the software being developed meets the needs and expectations of the stakeholders

 Can help identify potential issues or problems early in the development process, allowing for adjustments to
be made before significant

 Helps ensure that the software is developed in a cost-effective and efficient manner

 Can improve communication and collaboration between the development team and stakeholders

 Helps to ensure that the software system meets the needs of all stakeholders.

 Provides a clear and unambiguous description of the requirements, which helps to reduce
misunderstandings and errors.

 Helps to identify potential conflicts and contradictions in the requirements, which can be resolved before
the software development process begins.

 Helps to ensure that the software system is delivered on time, within budget, and to the required quality
standards.

 Provides a solid foundation for the development process, which helps to reduce the risk of failure.

Disadvantages

 Can be time-consuming and costly, particularly if the requirements gathering process is not well-managed

 Can be difficult to ensure that all stakeholders’ needs and expectations are taken into account

 Can be challenging to ensure that the requirements are clear, consistent, and complete

 Changes in requirements can lead to delays and increased costs in the development process.
 UNIT 2: Software Development Activities
 As a best practice, Requirements engineering should be flexible, adaptable, and should be aligned with the
overall project goals.

 It can be time-consuming and expensive, especially if the requirements are complex.

 It can be difficult to elicit requirements from stakeholders who have different needs and priorities.

 Requirements may change over time, which can result in delays and additional costs.

 There may be conflicts between stakeholders, which can be difficult to resolve.

 It may be challenging to ensure that all stakeholders understand and agree on the requirements.

Stages in Software Engineering Process

Requirements engineering is a critical process in software engineering that involves identifying, analyzing,
documenting, and managing the requirements of a software system. The requirements engineering process consists
of the following stages:

 Elicitation: In this stage, the requirements are gathered from various stakeholders such as customers, users,
and domain experts. The aim is to identify the features and functionalities that the software system should
provide.

 Analysis: In this stage, the requirements are analyzed to determine their feasibility, consistency, and
completeness. The aim is to identify any conflicts or contradictions in the requirements and resolve them.

 Specification: In this stage, the requirements are documented in a clear, concise, and unambiguous manner.
The aim is to provide a detailed description of the requirements that can be understood by all stakeholders.

 Validation: In this stage, the requirements are reviewed and validated to ensure that they meet the needs of
all stakeholders. The aim is to ensure that the requirements are accurate, complete, and consistent.

 Management: In this stage, the requirements are managed throughout the software development lifecycle.
The aim is to ensure that any changes or updates to the requirements are properly documented and
communicated to all stakeholders.

 Effective requirements engineering is crucial to the success of software development projects. It helps
ensure that the software system meets the needs of all stakeholders and is delivered on time, within budget,
and to the required quality standards.

Software Engineering – Software Requirement Tasks

Requirements engineering is a broad domain that focuses on being the connector between modeling, analysis,
design, and construction. It is the process that defines, identifies, manages, and develops requirements in a software
engineering design process. This process uses tools, methods, and principles to describe the system’s behavior and
the constraints that come along with it.

Requirements engineering is the most important part every business must follow, in order to build and release a
project successfully, as it is the foundation to key planning and implementation.
 UNIT 2: Software Development Activities

Requirements Engineering Process

Requirements Engineering Tasks: The software requirements engineering process includes the following steps of
activities:

1. Inception

2. Elicitation

3. Elaboration

4. Negotiation

5. Specification

6. Validation

7. Requirements Management

Let’s discuss each of these steps in detail.

1. Inception: This is the first phase of the requirements analysis process. This phase gives an outline of how to get
started on a project. In the inception phase, all the basic questions are asked on how to go about a task or the steps
required to accomplish a task. A basic understanding of the problem is gained and the nature of the solution is
addressed. Effective communication is very important in this stage, as this phase is the foundation as to what has to
be done further. Overall in the inception phase, the following criteria have to be addressed by the software
engineers:

 Understanding of the problem.

 The people who want a solution.

 Nature of the solution.

 Communication and collaboration between the customer and developer.

 UNIT 2: Software Development Activities
2. Elicitation: This is the second phase of the requirements analysis process. This phase focuses on gathering the
requirements from the stakeholders. One should be careful in this phase, as the requirements are what establishes
the key purpose of a project. Understanding the kind of requirements needed from the customer is very crucial for a
developer. In this process, mistakes can happen in regard to, not implementing the right requirements or forgetting
a part. The right people must be involved in this phase. The following problems can occur in the elicitation phase:

 Problem of Scope: The requirements given are of unnecessary detail, ill-defined, or not possible to
implement.

 Problem of Understanding: Not having a clear-cut understanding between the developer and customer
when putting out the requirements needed. Sometimes the customer might not know what they want or the
developer might misunderstand one requirement for another.

 Problem of Volatility: Requirements changing over time can cause difficulty in leading a project. It can lead
to loss and wastage of resources and time.

3. Elaboration: This is the third phase of the requirements analysis process. This phase is the result of the inception
and elicitation phase. In the elaboration process, it takes the requirements that have been stated and gathered in
the first two phases and refines them. Expansion and looking into it further are done as well. The main task in this
phase is to indulge in modeling activities and develop a prototype that elaborates on the features and constraints
using the necessary tools and functions.

4. Negotiation: This is the fourth phase of the requirements analysis process. This phase emphasizes discussion and
exchanging conversation on what is needed and what is to be eliminated. In the negotiation phase, negotiation is
between the developer and the customer and they dwell on how to go about the project with limited business
resources. Customers are asked to prioritize the requirements and make guesstimates on the conflicts that may arise
along with it. Risks of all the requirements are taken into consideration and negotiated in a way where the customer
and developer are both satisfied with reference to the further implementation. The following are discussed in the
negotiation phase:

 Availability of Resources.

 Delivery Time.

 Scope of requirements.

 Project Cost.

 Estimations on development.

5. Specification: This is the fifth phase of the requirements analysis process. This phase specifies the following:

 Written document.

 A set of models.

 A collection of use cases.

 A prototype.

In the specification phase, the requirements engineer gathers all the requirements and develops a working model.
This final working product will be the basis of any functions, features or constraints to be observed. The models used
in this phase include ER (Entity Relationship) diagrams, DFD (Data Flow Diagram), FDD (Function Decomposition
Diagrams), and Data Dictionaries.
A software specification document is submitted to the customer in a language that he/she will understand, to give a
glimpse of the working model.
 UNIT 2: Software Development Activities
6. Validation: This is the sixth phase of the requirements analysis process. This phase focuses on checking for errors
and debugging. In the validation phase, the developer scans the specification document and checks for the following:

 All the requirements have been stated and met correctly

 Errors have been debugged and corrected.

 Work product is built according to the standards.

This requirements validation mechanism is known as the formal technical review. The review team that works
together and validates the requirements include software engineers, customers, users, and other stakeholders.
Everyone in this team takes part in checking the specification by examining for any errors, missing information, or
anything that has to be added or checking for any unrealistic and problematic errors. Some of the validation
techniques are the following-

 Requirements reviews/inspections.

 Prototyping.

 Test-case generation.

 Automated consistency analysis.

7. Requirements Management: This is the last phase of the requirements analysis process. Requirements
management is a set of activities where the entire team takes part in identifying, controlling, tracking, and
establishing the requirements for the successful and smooth implementation of the project.
In this phase, the team is responsible for managing any changes that may occur during the project. New
requirements emerge, and it is in this phase, responsibility should be taken to manage and prioritize as to where its
position is in the project and how this new change will affect the overall system, and how to address and deal with
the change. Based on this phase, the working model will be analyzed carefully and ready to be delivered to the
customer.

Analysis principles – Analysis Modelling in Software Engineering

Analysis Model is a technical representation of the system. It acts as a link between the system description and the
design model. In Analysis Modelling, information, behavior, and functions of the system are defined and translated
into the architecture, component, and interface level design in the design modeling.

Objectives of Analysis Modelling:

 It must establish a way of creating software design.

 It must describe the requirements of the customer.

 It must define a set of requirements that can be validated, once the software is built.
 UNIT 2: Software Development Activities
Elements of Analysis Model:

Elements of Analysis Model

1. Data Dictionary:
It is a repository that consists of a description of all data objects used or produced by the software. It stores
the collection of data present in the software. It is a very crucial element of the analysis model. It acts as a
centralized repository and also helps in modeling data objects defined during software requirements.

2. Entity Relationship Diagram (ERD):

It depicts the relationship between data objects and is used in conducting data modeling activities. The
attributes of each object in the Entity-Relationship Diagram can be described using Data object description.
It provides the basis for activity related to data design.

3. Data Flow Diagram (DFD):

It depicts the functions that transform data flow, and it also shows how data is transformed when moving
from input to output. It provides the additional information which is used during the analysis of the
information domain and serves as a basis for the modeling of function. It also enables the engineer to
develop models of functional and information domains at the same time.

4. State Transition Diagram:

It shows various modes of behavior (states) of the system and also shows the transitions from one state to
another state in the system. It also provides the details of how the system behaves due to the consequences
of external events. It represents the behavior of a system by presenting its states and the events that cause
the system to change state. It also describes what actions are taken due to the occurrence of a particular
event.

5. Process Specification:
It stores the description of each function present in the data flow diagram. It describes the input to a
function, the algorithm that is applied for the transformation of input, and the output that is produced. It
also shows regulations and barriers imposed on the performance characteristics that are applicable to the
process and layout constraints that could influence the way in which the process will be implemented.

6. Control Specification:
It stores additional information about the control aspects of the software. It is used to indicate how the
software behaves when an event occurs and which processes are invoked due to the occurrence of the
event. It also provides the details of the processes which are executed to manage events.
 UNIT 2: Software Development Activities
7. Data Object Description:
It stores and provides complete knowledge about a data object present and used in the software. It also
gives us the details of attributes of the data object present in the Entity Relationship Diagram. Hence, it
incorporates all the data objects and their attributes.

Object-Oriented Analysis and Design | OOAD

Object-Oriented Analysis and Design (OOAD) is a software engineering methodology that employs object-oriented
principles to model and design complex systems. It involves analyzing the problem domain, representing it using
objects and their interactions, and then designing a modular and scalable solution. It helps create systems that are
easier to understand, maintain, and extend by organizing functionality into reusable and interconnected
components.

Important Topics for the Object-Oriented Analysis and Design

 Important Aspects of OOAD

 Object-Oriented Analysis

 Object-Oriented Design

 Advantages of Object-Oriented Analysis and Design(OOAD)

 Disadvantages of Object-Oriented Analysis and Design(OOAD)

 Real-world applications of Object-Oriented Analysis and Design(OOAD)

Important Aspects of OOAD

Here are some important aspects of OOAD:

 Object-Oriented Programming:

 Object-oriented programming involves modeling real-world objects as software objects, with

properties and methods that represent the behavior of those objects. OOAD uses this approach to
design and implement software systems.

 Design Patterns:

 Design patterns are reusable solutions to common problems in software design. OOAD uses design
patterns to help developers create more maintainable and efficient software systems.

 UML Diagrams:

 Unified Modeling Language (UML) is a standardized notation for creating diagrams that represent
different aspects of a software system. OOAD uses UML diagrams to represent the different
components and interactions of a software system.

 Use Cases:

 Use cases are a way of describing the different ways in which users interact with a software system.
OOAD uses use cases to help developers understand the requirements of a system and to design
software systems that meet those requirements.

Object-Oriented Analysis

Object-Oriented Analysis (OOA) is the first technical activity performed as part of object-oriented software
engineering. OOA introduces new concepts to investigate a problem. It is based on a set of basic principles, which
are as follows:
 UNIT 2: Software Development Activities
 The information domain is modeled:

 Lets say you’re building a game. OOA helps you figure out all the things you need to know about the
game world – the characters, their features, and how they interact. It’s like making a map of
everything important.

 Behavior is represented:

 OOA also helps you understand what your game characters will do. If a character jumps when you
press a button, OOA helps describe that action. It’s like writing down a script for each character.

 The function is described:

 Every program has specific tasks or jobs it needs to do. OOA helps you list and describe these jobs. In
our game, it could be tasks like moving characters or keeping score. It’s like making a to-do list for
your software.

 Data, functional, and behavioral models are divided to uncover greater detail:

 OOA is smart about breaking things into different parts. It splits the job into three categories: things
your game knows (like scores), things your game does (like jumping), and how things in your game
behave (like characters moving around). This makes it easier to understand.

 Starting Simple, Getting Detailed:

 OOA knows that at first, you just want to understand the big picture. So, it starts with a simple
version of your game or program. Later on, you add more details to make it work perfectly. It’s like
sketching a quick drawing before adding all the colors and details.

The above noted principles form the foundation for the OOA approach.

Object-Oriented Design

In the object-oriented software development process, the analysis model, which is initially formed through object-
oriented analysis (OOA), undergoes a transformation during object-oriented design (OOD). This evolution is crucial
because it shapes the analysis model into a detailed design model, essentially serving as a blueprint for constructing
the software.

The outcome of object-oriented design, or OOD, manifests in a design model characterized by multiple levels of
modularity. This modularity is expressed in two key ways:

 Subsystem Partitioning:

 At a higher level, major components of the system are organized into subsystems.

 This practice is similar to creating modules at the system level, providing a structured and organized
approach to managing the complexity of the software.

 Object Encapsulation:

 A more granular form of modularity is achieved through the encapsulation of data manipulation
operations into objects. ” It’s like putting specific tasks (or operations) and the data they need into
little boxes called “objects.”

 Each object does its job neatly and keeps things organized. So, if our game has a character jumping,
we put all the jumping stuff neatly inside an object.

 It’s like having a box for each task, making everything easier to handle and understand.

Furthermore, as part of the object-oriented design process, it is essential to define specific aspects:
 UNIT 2: Software Development Activities
 Data Organization of Attributes:

 OOD involves specifying how data attributes are organized within the objects. This includes
determining the types of data each object will hold and how they relate to one another, ensuring a
coherent and efficient data structure.

 Procedural Description of Operations:

 OOD requires a procedural description for each operation that an object can perform. This involves
detailing the steps or processes involved in carrying out specific tasks, ensuring clarity and precision
in the implementation of functionality.

Below diagram shows a design pyramid for object-oriented systems. It is having the following four layers.

1. The Subsystem Layer: It represents the subsystem that enables software to achieve user requirements and
implement technical frameworks that meet user needs.

2. The Class and Object Layer: It represents the class hierarchies that enable the system to develop using
generalization and specialization. This layer also represents each object.

3. The Message Layer: This layer deals with how objects interact with each other. It includes messages sent
between objects, method calls, and the flow of control within the system.

4. The Responsibilities Layer: It focuses on the responsibilities of individual objects. This includes defining the
behavior of each class, specifying what each object is responsible for, and how it responds to messages.

Advantages of Object-Oriented Analysis and Design(OOAD)

 Improved modularity:

 OOAD encourages the creation of small, reusable objects that can be combined to create more
complex systems, improving the modularity and maintainability of the software.
 UNIT 2: Software Development Activities
 Better abstraction:

 OOAD provides a high-level, abstract representation of a software system, making it easier to

understand and maintain.

 Improved reuse:

 OOAD encourages the reuse of objects and object-oriented design patterns, reducing the amount of
code that needs to be written and improving the quality and consistency of the software.

 Improved communication:

 OOAD provides a common vocabulary and methodology for software developers, improving
communication and collaboration within teams.

 Reusability:

 OOAD emphasizes the use of reusable components and design patterns, which can save time and
effort in software development by reducing the need to create new code from scratch.

 Scalability:

 OOAD can help developers design software systems that are scalable and can handle changes in user
demand and business requirements over time.

 Maintainability:

 OOAD emphasizes modular design and can help developers create software systems that are easier
to maintain and update over time.

 Flexibility:

 OOAD can help developers design software systems that are flexible and can adapt to changing
business requirements over time.

 Improved software quality:

 OOAD emphasizes the use of encapsulation, inheritance, and polymorphism, which can lead to
software systems that are more reliable, secure, and efficient.

Disadvantages of Object-Oriented Analysis and Design(OOAD)

 Complexity:

 OOAD can add complexity to a software system, as objects and their relationships must be carefully
modeled and managed.

 Overhead:

 OOAD can result in additional overhead, as objects must be instantiated, managed, and interacted
with, which can slow down the performance of the software.

 Steep learning curve:

 OOAD can have a steep learning curve for new software developers, as it requires a strong
understanding of OOP concepts and techniques.

 Complexity:

 OOAD can be complex and may require significant expertise to implement effectively. It may be
difficult for novice developers to understand and apply OOAD principles.
 UNIT 2: Software Development Activities
 Time-consuming:

 OOAD can be a time-consuming process that involves significant upfront planning and
documentation. This can lead to longer development times and higher costs.

 Rigidity:

 Once a software system has been designed using OOAD, it can be difficult to make changes without
significant time and expense. This can be a disadvantage in rapidly changing environments where
new technologies or business requirements may require frequent changes to the system.

 Cost:

 OOAD can be more expensive than other software engineering methodologies due to the upfront
planning and documentation required.

Real world applications of Object-Oriented Analysis and Design(OOAD)

Object-Oriented Analysis and Design (OOAD) has been widely applied across various industries to improve software
development processes, enhance maintainability, and promote code reusability. Here are some real-world
applications of OOAD:

1. Financial Systems:

 Banking Software: OOAD is often employed in banking systems to model complex financial
structures, transactions, and customer interactions. The modular and scalable nature of OOAD helps
in designing flexible and robust banking applications.

2. Healthcare Systems:

 Electronic Health Record (EHR) Systems: OOAD is utilized to model patient data, medical records,
and healthcare workflows. Object-oriented principles enable the creation of modular and adaptable
healthcare applications that can evolve with changing requirements.

3. Aerospace and Defense:

 Flight Control Systems: OOAD is crucial in designing flight control systems for aircraft. It helps model
the interactions between different components such as navigation systems, sensors, and control
surfaces, ensuring safety and reliability.

4. Telecommunications:

 Telecom Billing Systems: OOAD is applied to model and design billing systems in the
telecommunications industry. It allows for the representation of complex billing rules, subscription
plans, and customer data in a modular and scalable way.

5. E-commerce:

 Online Shopping Platforms: OOAD is commonly used in the development of e-commerce systems. It
helps model product catalogs, user profiles, shopping carts, and payment processes, making it easier
to maintain and extend the functionality of the platform.

Flow-Oriented Model:

The Flow-Oriented Model, also known as the Flowchart model, emphasizes the flow of control in a system. It is often
used to represent the sequential steps or processes in a system. Key characteristics include:
 UNIT 2: Software Development Activities
1. Sequential Flow:

 Represents the flow of control through a series of steps or processes.

 Each step is represented by a block or symbol, and arrows indicate the flow of control.

2. Decision Points:

 Includes decision points where the flow can branch based on certain conditions.

 Typically uses conditional statements to represent decision-making.

3. Visualization of Processes:

 Effective for visualizing and understanding processes and their order of execution.

4. Limited Abstraction:

 May lack the level of abstraction seen in other models, such as object-oriented models.

This model is often used in the early stages of system design to outline the high-level flow of a program or process.

Class-Based Model:

The Class-Based Model is a core concept in object-oriented programming (OOP) and design. It focuses on the
abstraction of entities into classes, which encapsulate data and behavior. Key characteristics include:

1. Classes and Objects:

 Entities are represented as classes, which define a blueprint for objects.

 Objects are instances of classes and encapsulate both data (attributes) and behavior (methods).

2. Inheritance:

 Supports inheritance, where a class can inherit properties and behaviors from another class.

 Promotes code reuse and the creation of a hierarchical structure.

3. Encapsulation:

 Encapsulation hides the internal details of a class and exposes only what is necessary.

 Supports the principle of information hiding.

4. Polymorphism:

 Allows objects of different classes to be treated as objects of a common base class.

 Enables flexibility and extensibility in the system.

Object-oriented languages like Java, C++, and Python are built on the principles of the Class-Based Model.

Behavioral Model:

The Behavioral Model focuses on capturing the dynamic aspects of a system, emphasizing the interactions between
entities and their behaviors over time. Key characteristics include:

1. Use Case Diagrams:

 Represents the interactions between external actors and the system.

 Use cases describe the functionality or behavior of the system from the user's perspective.
 UNIT 2: Software Development Activities
2. Activity Diagrams:

 Illustrates the flow of activities within a system.

 Shows the order of activities and decision points.

3. State Diagrams:

 Represents the various states that an object or system can be in.

 Transitions between states are triggered by events.

4. Sequence Diagrams:

 Shows the sequence of interactions between different entities in the system.

 Represents the chronological order of messages exchanged.

Behavioral models are crucial for understanding how a system responds to stimuli and how different components
collaborate to achieve specific functionalities.

Introduction of Software Design process

Software Design is the process of transforming user requirements into a suitable form, which helps the programmer
in software coding and implementation. During the software design phase, the design document is produced, based
on the customer requirements as documented in the SRS document. Hence, this phase aims to transform the SRS
document into a design document.

The following items are designed and documented during the design phase:

 Different modules are required.

 Control relationships among modules.

 Interface among different modules.

 Data structure among the different modules.

 Algorithms are required to be implemented among the individual modules.

Objectives of Software Design:

1. Correctness:
A good design should be correct i.e., it should correctly implement all the functionalities of the system.

2. Efficiency:
A good software design should address the resources, time, and cost optimization issues.

3. Flexibility:
A good software design should have the ability to adapt and accommodate changes easily. It includes
designing the software in a way, that allows for modifications, enhancements, and scalability without
requiring significant rework or causing major disruptions to the existing functionality.

4. Understandability:
A good design should be easily understandable, it should be modular, and all the modules are arranged in
layers.

5. Completeness:
The design should have all the components like data structures, modules, and external interfaces, etc.

6. Maintainability:
A good software design aims to create a system that is easy to understand, modify, and maintain over time.
 UNIT 2: Software Development Activities
This involves using modular and well-structured design principles e.g.,(employing appropriate naming
conventions and providing clear documentation). Maintainability in software Design also enables developers
to fix bugs, enhance features, and adapt the software to changing requirements without excessive effort or
introducing new issues.

Software Design Concepts:

Concepts are defined as a principal idea or invention that comes into our mind or in thought to understand
something. The software design concept simply means the idea or principle behind the design. It describes how you
plan to solve the problem of designing software, the logic, or thinking behind how you will design software. It allows
the software engineer to create the model of the system or software or product that is to be developed or built. The
software design concept provides a supporting and essential structure or model for developing the right software.
There are many concepts of software design and some of them are given below:

Software Design process

Points should be considered while Designing Software:

1. Abstraction- (Hide Irrelevant data )

Abstraction simply means to hide the details to reduce complexity and increases efficiency or quality.
Different levels of Abstraction are necessary and must be applied at each stage of the design process so that
any error that is present can be removed to increase the efficiency of the software solution and to refine the
software solution. The solution should be described in broad ways that cover a wide range of different things
at a higher level of abstraction and a more detailed description of a solution of software should be given at
the lower level of abstraction.

2. Modularity- (subdivide the system)

Modularity simply means dividing the system or project into smaller parts to reduce the complexity of the
system or project. In the same way, modularity in design means subdividing a system into smaller parts so
that these parts can be created independently and then use these parts in different systems to perform
 UNIT 2: Software Development Activities
different functions. It is necessary to divide the software into components known as modules because
nowadays, there are different software available like Monolithic software that is hard to grasp for software
engineers. So, modularity in design has now become a trend and is also important. If the system contains
fewer components then it would mean the system is complex which requires a lot of effort (cost) but if we
are able to divide the system into components then the cost would be small.

3. Architecture- (design a structure of something )

Architecture simply means a technique to design a structure of something. Architecture in designing
software is a concept that focuses on various elements and the data of the structure. These components
interact with each other and use the data of the structure in architecture.

4. Refinement- (removes impurities)

Refinement simply means to refine something to remove any impurities if present and increase the quality.
The refinement concept of software design is actually a process of developing or presenting the software or
system in a detailed manner that means to elaborate a system or software. Refinement is very necessary to
find out any error if present and then to reduce it.

5. Pattern- (a Repeated form)

The pattern simply means a repeated form or design in which the same shape is repeated several times to
form a pattern. The pattern in the design process means the repetition of a solution to a common recurring
problem within a certain context.

6. Information Hiding – Hide the Information

Information hiding simply means to hide the information so that it cannot be accessed by an unwanted
party. In software design, information hiding is achieved by designing the modules in a manner that the
information gathered or contained in one module is hidden and can’t be accessed by any other modules.

7. Refactoring-( Reconstruct something )

Refactoring simply means reconstructing something in such a way that it does not affect the behavior of any
other features. Refactoring in software design means reconstructing the design to reduce complexity and
simplify it without impacting the behavior or its functions. Fowler has defined refactoring as “the process of
changing a software system in a way that it won’t impact the behavior of the design and improves the
internal structure”.

Different levels of Software Design:

There are three different levels of software design. They are:

1. Architectural Design:
The architecture of a system can be viewed as the overall structure of the system & the way in which
structure provides conceptual integrity of the system. The architectural design identifies the software as a
system with many components interacting with each other. At this level, the designers get the idea of the
proposed solution domain.

2. Preliminary or high-level design:

Here the problem is decomposed into a set of modules, the control relationship among various modules
identified, and also the interfaces among various modules are identified. The outcome of this stage is called
the program architecture. Design representation techniques used in this stage are structure chart and UML.

3. Detailed design:
Once the high-level design is complete, a detailed design is undertaken. In detailed design, each module is
examined carefully to design the data structure and algorithms. The stage outcome is documented in the
form of a module specification document.
 UNIT 2: Software Development Activities
Software Design Process – Software Engineering
The design phase of software development deals with transforming the customer requirements as described in the
SRS documents into a form implementable using a programming language. The software design process can be
divided into the following three levels or phases of design:

1. Interface Design

2. Architectural Design

3. Detailed Design

Elements of a System

1. Architecture: This is the conceptual model that defines the structure, behavior, and views of a system. We
can use flowcharts to represent and illustrate the architecture.

2. Modules: These are components that handle one specific task in a system. A combination of the modules
makes up the system.

3. Components: This provides a particular function or group of related functions. They are made up of
modules.

4. Interfaces: This is the shared boundary across which the components of a system exchange information and
relate.

5. Data: This is the management of the information and data flow.

Software Design Process

 UNIT 2: Software Development Activities
Interface Design

Interface design is the specification of the interaction between a system and its environment. This phase proceeds at
a high level of abstraction with respect to the inner workings of the system i.e, during interface design, the internal
of the systems are completely ignored, and the system is treated as a black box. Attention is focused on the dialogue
between the target system and the users, devices, and other systems with which it interacts. The design problem
statement produced during the problem analysis step should identify the people, other systems, and devices which
are collectively called agents.

Interface design should include the following details:

1. Precise description of events in the environment, or messages from agents to which the system must
respond.

2. Precise description of the events or messages that the system must produce.

3. Specification of the data, and the formats of the data coming into and going out of the system.

4. Specification of the ordering and timing relationships between incoming events or messages, and outgoing
events or outputs.

Architectural Design

Architectural design is the specification of the major components of a system, their responsibilities, properties,
interfaces, and the relationships and interactions between them. In architectural design, the overall structure of the
system is chosen, but the internal details of major components are ignored. Issues in architectural design includes:

1. Gross decomposition of the systems into major components.

2. Allocation of functional responsibilities to components.

3. Component Interfaces.

4. Component scaling and performance properties, resource consumption properties, reliability properties, and
so forth.

5. Communication and interaction between components.

The architectural design adds important details ignored during the interface design. Design of the internals of the
major components is ignored until the last phase of the design.

Detailed Design

Design is the specification of the internal elements of all major system components, their properties, relationships,
processing, and often their algorithms and the data structures. The detailed design may include:

1. Decomposition of major system components into program units.

2. Allocation of functional responsibilities to units.

3. User interfaces.

4. Unit states and state changes.

5. Data and control interaction between units.

6. Data packaging and implementation, including issues of scope and visibility of program elements.

7. Algorithms and data structures.

 UNIT 2: Software Development Activities
Design Model:

A design model in software engineering is a representation of the architecture and structure of a software system. It
acts as a blueprint that guides the implementation phase of the software development process. Design models can
take various forms, and they help bridge the gap between the requirements specification and the actual code
implementation. Some common types of design models include:

1. Architectural Models:

 Describe the high-level structure of a system, including components, their interactions, and how
they fulfill the system's requirements.

 Examples include the client-server model, layered architecture, and microservices architecture.

2. Structural Models:

 Detail the organization of the software components, such as classes, modules, or components, and
how they are interconnected.

 Class diagrams, package diagrams, and component diagrams are examples of structural models.

3. Behavioral Models:

 Illustrate the dynamic aspects of a system, showing how components interact over time.

 Examples include sequence diagrams, activity diagrams, and state diagrams.

4. Data Models:

 Define the structure and relationships of the data within the system.

 Entity-relationship diagrams (ERD) and data flow diagrams (DFD) are common types of data models.

5. User Interface (UI) Models:

 Depict the layout and interaction flow of the user interface.

 Wireframes, mockups, and user flow diagrams fall under UI models.

Design models help software architects and developers make informed decisions about the system's structure,
behavior, and data organization before the actual coding phase begins.

Pattern-Based Design:

Pattern-Based Design refers to the use of design patterns to solve recurring design problems in software
development. A design pattern is a reusable solution to a common problem that arises within a specific context.
Design patterns provide a way to capture best practices and design expertise, promoting code reusability,
maintainability, and flexibility. Some widely recognized design patterns include:

1. Creational Patterns:

 Address object creation mechanisms, providing ways to instantiate objects.

 Examples: Singleton, Factory Method, Abstract Factory.

2. Structural Patterns:

 Concerned with the composition of classes or objects to form larger structures.

 Examples: Adapter, Decorator, Composite.

 UNIT 2: Software Development Activities
3. Behavioral Patterns:

 Focus on the interaction and communication between objects.

 Examples: Observer, Strategy, Command.

4. Architectural Patterns:

 Offer solutions for organizing and structuring entire systems.

 Examples: Model-View-Controller (MVC), Microservices, Layered Architecture.

 UNIT 1: Introduction to Software Engineering
Software Evolution – Software Engineering
Software Evolution is a term that refers to the process of developing software initially, and then timely updating it
for various reasons, i.e., to add new features or to remove obsolete functionalities, etc. This article focuses on
discussing Software Evolution in detail.

What is Software Evolution?

The software evolution process includes fundamental activities of change analysis, release planning, system
implementation, and releasing a system to customers.

1. The cost and impact of these changes are accessed to see how much the system is affected by the change
and how much it might cost to implement the change.

2. If the proposed changes are accepted, a new release of the software system is planned.

3. During release planning, all the proposed changes (fault repair, adaptation, and new functionality) are
considered.

4. A design is then made on which changes to implement in the next version of the system.

5. The process of change implementation is an iteration of the development process where the revisions to the
system are designed, implemented, and tested.

Necessity of Software Evolution

Software evaluation is necessary just because of the following reasons:

1. Change in requirement with time: With time, the organization’s needs and modus Operandi of working
could substantially be changed so in this frequently changing time the tools(software) that they are using
need to change to maximize the performance.

2. Environment change: As the working environment changes the things(tools) that enable us to work in that
environment also changes proportionally same happens in the software world as the working environment
changes then, the organizations require reintroduction of old software with updated features and
functionality to adapt the new environment.

3. Errors and bugs: As the age of the deployed software within an organization increases their preciseness or
impeccability decrease and the efficiency to bear the increasing complexity workload also continually
degrades. So, in that case, it becomes necessary to avoid use of obsolete and aged software. All such
obsolete Pieces of software need to undergo the evolution process in order to become robust as per the
workload complexity of the current environment.

4. Security risks: Using outdated software within an organization may lead you to at the verge of various
software-based cyberattacks and could expose your confidential data illegally associated with the software
that is in use. So, it becomes necessary to avoid such security breaches through regular assessment of the
security patches/modules are used within the software. If the software isn’t robust enough to bear the
current occurring Cyber attacks so it must be changed (updated).

5. For having new functionality and features: In order to increase the performance and fast data processing
and other functionalities, an organization need to continuously evolute the software throughout its life cycle
so that stakeholders & clients of the product could work efficiently.
 UNIT 1: Introduction to Software Engineering

Software Evolution

Laws used for Software Evolution

1. Law of Continuing Change

This law states that any software system that represents some real-world reality undergoes continuous change or
become progressively less useful in that environment.

2. Law of Increasing Complexity

As an evolving program changes, its structure becomes more complex unless effective efforts are made to avoid this
phenomenon.

3. Law of Conservation of Organization Stability

Over the lifetime of a program, the rate of development of that program is approximately constant and independent
of the resource devoted to system development.

4. Law of Conservation of Familiarity

This law states that during the active lifetime of the program, changes made in the successive release are almost
constant.

Master Software Testing and Automation in an efficient and time-bound manner by mentors with real-time industry
experience. Join our Software Automation Course and embark on an exciting journey, mastering the skill set with
ease!

Changing Nature of Software – Software Engineering

The software is an instruction or computer program that when executed provides desired features, function, and
performance. A data structure that enables the program to adequately manipulate information and documents that
describe the operation and use of the program.
 UNIT 1: Introduction to Software Engineering
Characteristics of software:

There is some characteristic of software which is given below:

1. Reliability: The ability of the software to consistently perform its intended tasks without unexpected failures
or errors.

2. Usability: How easily and effectively users can interact with and navigate through the software.

3. Efficiency: The optimal utilization of system resources to perform tasks on time.

4. Maintainability: How easily and cost-effectively software can be modified, updated, or extended.

5. Portability: The ability of software to run on different platforms or environments without requiring
significant modifications.

Changing Nature of Software:

Nowadays, seven broad categories of computer software present continuing challenges for software engineers.
Which is given below:

1. System Software: System software is a collection of programs that are written to service other programs.
Some system software processes complex but determinate, information structures. Other system
application processes largely indeterminate data. Sometimes when, the system software area is
characterized by the heavy interaction with computer hardware that requires scheduling, resource sharing,
and sophisticated process management.

2. Application Software: Application software is defined as programs that solve a specific business need.
Application in this area processes business or technical data in a way that facilitates business operation or
management technical decision-making. In addition to conventional data processing applications, application
software is used to control business functions in real-time.

3. Engineering and Scientific Software: This software is used to facilitate the engineering function and task.
however modern applications within the engineering and scientific area are moving away from conventional
numerical algorithms. Computer-aided design, system simulation, and other interactive applications have
begun to take a real-time and even system software characteristic.

4. Embedded Software: Embedded software resides within the system or product and is used to implement
and control features and functions for the end-user and for the system itself. Embedded software can
perform limited and esoteric functions or provide significant function and control capability.

5. Product-line Software: Designed to provide a specific capability for use by many customers, product-line
software can focus on the limited and esoteric marketplace or address the mass consumer market.

6. Web Application: It is a client-server computer program that the client runs on the web browser. In their
simplest form, Web apps can be little more than a set of linked hypertext files that present information using
text and limited graphics. However, as e-commerce and B2B applications grow in importance. Web apps are
evolving into a sophisticated computing environment that not only provides a standalone feature,
computing function, and content to the end user.

7. Artificial Intelligence Software: Artificial intelligence software makes use of a nonnumerical algorithm to
solve a complex problem that is not amenable to computation or straightforward analysis. Applications
within this area include robotics, expert systems, pattern recognition, artificial neural networks, theorem
proving, and game playing.
 UNIT 1: Introduction to Software Engineering
Layered Technology in Software Engineering
Software engineering is a fully layered technology, to develop software we need to go from one layer to another. All
the layers are connected and each layer demands the fulfillment of the previous layer.

Fig: The diagram shows the layers of software development

Layered technology is divided into four parts:

1. A quality focus: It defines the continuous process improvement principles of software. It provides integrity that
means providing security to the software so that data can be accessed by only an authorized person, no outsider can
access the data. It also focuses on maintainability and usability.

2. Process: It is the foundation or base layer of software engineering. It is key that binds all the layers together which
enables the development of software before the deadline or on time. Process defines a framework that must be
established for the effective delivery of software engineering technology. The software process covers all the
activities, actions, and tasks required to be carried out for software development.

Process activities are listed below:-

 Communication: It is the first and foremost thing for the development of software. Communication is
necessary to know the actual demand of the client.

 Planning: It basically means drawing a map for reduced the complication of development.

 Modeling: In this process, a model is created according to the client for better understanding.

 Construction: It includes the coding and testing of the problem.

 Deployment:- It includes the delivery of software to the client for evaluation and feedback.
 UNIT 1: Introduction to Software Engineering
3. Method: During the process of software development the answers to all “how-to-do” questions are given by
method. It has the information of all the tasks which includes communication, requirement analysis, design
modeling, program construction, testing, and support.

4. Tools: Software engineering tools provide a self-operating system for processes and methods. Tools are
integrated which means information created by one tool can be used by another.

Software Process Framework – Software Engineering

Software Process Framework is an abstraction of the software development process. This article focuses on
discussing the Software Process Framework.

What is a Software Process Framework?

Software Process Framework details the steps and chronological order of a process. Since it serves as a foundation
for them, it is utilized in most applications. Task sets, umbrella activities, and process framework activities all define
the characteristics of the software development process. Software Process includes:

1. Tasks: They focus on a small, specific objective.

2. Action: It is a set of tasks that produce a major work product.

3. Activities: Activities are groups of related tasks and actions for a major objective.

Software Process Framework

 UNIT 1: Introduction to Software Engineering
Process Framework Activities

The process framework is required for representing common process activities. Five framework activities are
described in a process framework for software engineering. Communication, planning, modeling, construction, and
deployment are all examples of framework activities. Each engineering action defined by a framework activity
comprises a list of needed work outputs, project milestones, and software quality assurance (SQA) points.

1. Communication

By communication, customer requirement gathering is done. Communication with consumers and stakeholders to
determine the system’s objectives and the software’s requirements.

2. Planning

Establish engineering work plan, describes technical risk, lists resources requirements, work produced and defines
work schedule.

3. Modeling

Architectural models and design to better understand the problem and to work towards the best solution. The
software model is prepared by:

 Analysis of requirements

 Design

4. Construction

Creating code, testing the system, fixing bugs, and confirming that all criteria are met. The software design is
mapped into a code by:

 Code generation

 Testing

5. Deployment

In this activity, a complete or non-complete product or software is represented to the customers to evaluate and
give feedback. On the basis of their feedback, we modify the product for the supply of better products.

Umbrella Activities

Umbrella Activities are that take place during a software development process for improved project management
and tracking.

1. Software project tracking and control: This is an activity in which the team can assess progress and take
corrective action to maintain the schedule. Take action to keep the project on time by comparing the
project’s progress against the plan.

2. Risk management: The risks that may affect project outcomes or quality can be analyzed. Analyze potential
risks that may have an impact on the software product’s quality and outcome.

3. Software quality assurance: These are activities required to maintain software quality. Perform actions to
ensure the product’s quality.

4. Formal technical reviews: It is required to assess engineering work products to uncover and remove errors
before they propagate to the next activity. At each level of the process, errors are evaluated and fixed.

5. Software configuration management: Managing of configuration process when any change in the software
occurs.
 UNIT 1: Introduction to Software Engineering
6. Work product preparation and production: The activities to create models, documents, logs, forms, and lists
are carried out.

7. Reusability management: It defines criteria for work product reuse. Reusable work items should be backed
up, and reusable software components should be achieved.

8. Measurement: In this activity, the process can be defined and collected. Also, project and product measures
are used to assist the software team in delivering the required software.

Project Monitoring and Control

Monitoring and Controlling are processes needed to track, review, and regulate the progress and
performance of the project. It also identifies any areas where changes to the project management
method are required and initiates the required changes.

The Monitoring & Controlling process group includes eleven processes, which are:

1. Monitor and control project work: The generic step under which all other monitoring and
controlling activities fall under.
2. Perform integrated change control: The functions involved in making changes to the
project plan. When changes to the schedule, cost, or any other area of the project
management plan are necessary, the program is changed and re-approved by the project
sponsor.
3. Validate scope: The activities involved with gaining approval of the project's deliverables.
4. Control scope: Ensuring that the scope of the project does not change and that unauthorized
activities are not performed as part of the plan (scope creep).
5. Control schedule: The functions involved with ensuring the project work is performed
according to the schedule, and that project deadlines are met.
 UNIT 1: Introduction to Software Engineering
6. Control costs: The tasks involved with ensuring the project costs stay within the approved
budget.
7. Control quality: Ensuring that the quality of the project?s deliverables is to the standard
defined in the project management plan.
8. Control communications: Providing for the communication needs of each project
stakeholder.
9. Control Risks: Safeguarding the project from unexpected events that negatively impact the
project's budget, schedule, stakeholder needs, or any other project success criteria.
10. Control procurements: Ensuring the project's subcontractors and vendors meet the project
goals.
11. Control stakeholder engagement: The tasks involved with ensuring that all of the project's
stakeholders are left satisfied with the project work.

Capability Maturity Model Integration (CMMI)

Capability Maturity Model Integration (CMMI) is a successor of CMM and is a more evolved model that
incorporates best components of individual disciplines of CMM like Software CMM, Systems Engineering CMM,
People CMM, etc. Since CMM is a reference model of matured practices in a specific discipline, so it becomes
difficult to integrate these disciplines as per the requirements. This is why CMMI is used as it allows the integration
of multiple disciplines as and when needed.

Objectives of CMMI :

1. Fulfilling customer needs and expectations.

2. Value creation for investors/stockholders.

3. Market growth is increased.

4. Improved quality of products and services.

5. Enhanced reputation in Industry.

CMMI Representation – Staged and Continuous :

A representation allows an organization to pursue a different set of improvement objectives. There are two
representations for CMMI :

 Staged Representation :

 uses a pre-defined set of process areas to define improvement path.

 provides a sequence of improvements, where each part in the sequence serves as a foundation for
the next.

 an improved path is defined by maturity level.

 maturity level describes the maturity of processes in organization.

 Staged CMMI representation allows comparison between different organizations for multiple
maturity levels.
 UNIT 1: Introduction to Software Engineering
 Continuous Representation :

 allows selection of specific process areas.

 uses capability levels that measures improvement of an individual process area.

 Continuous CMMI representation allows comparison between different organizations on a process-

area-by-process-area basis.

 allows organizations to select processes which require more improvement.

 In this representation, order of improvement of various processes can be selected which allows the
organizations to meet their objectives and eliminate risks.

CMMI Model – Maturity Levels :

In CMMI with staged representation, there are five maturity levels described as follows :

1. Maturity level 1 : Initial

 processes are poorly managed or controlled.

 unpredictable outcomes of processes involved.

 ad hoc and chaotic approach used.

 No KPAs (Key Process Areas) defined.

 Lowest quality and highest risk.

2. Maturity level 2 : Managed

 requirements are managed.

 processes are planned and controlled.

 projects are managed and implemented according to their documented plans.

 This risk involved is lower than Initial level, but still exists.

 Quality is better than Initial level.

3. Maturity level 3 : Defined

 processes are well characterized and described using standards, proper procedures, and methods,
tools, etc.

 Medium quality and medium risk involved.

 Focus is process standardization.

4. Maturity level 4 : Quantitatively managed

 quantitative objectives for process performance and quality are set.

 quantitative objectives are based on customer requirements, organization needs, etc.

 process performance measures are analyzed quantitatively.

 higher quality of processes is achieved.

 lower risk
 UNIT 1: Introduction to Software Engineering
5. Maturity level 5 : Optimizing

 continuous improvement in processes and their performance.

 improvement has to be both incremental and innovative.

 highest quality of processes.

 lowest risk in processes and their performance.

CMMI Model – Capability Levels

A capability level includes relevant specific and generic practices for a specific process area that can improve the
organization’s processes associated with that process area. For CMMI models with continuous representation, there
are six capability levels as described below :

1. Capability level 0 : Incomplete

 incomplete process – partially or not performed.

 one or more specific goals of process area are not met.

 No generic goals are specified for this level.

 this capability level is same as maturity level 1.

2. Capability level 1 : Performed

 process performance may not be stable.

 objectives of quality, cost and schedule may not be met.

 a capability level 1 process is expected to perform all specific and generic practices for this level.

 only a start-step for process improvement.

3. Capability level 2 : Managed

 process is planned, monitored and controlled.

 managing the process by ensuring that objectives are achieved.

 objectives are both model and other including cost, quality, schedule.

 actively managing processing with the help of metrics.

4. Capability level 3 : Defined

 a defined process is managed and meets the organization’s set of guidelines and standards.

 focus is process standardization.

5. Capability level 4 : Quantitatively Managed

 process is controlled using statistical and quantitative techniques.

 process performance and quality is understood in statistical terms and metrics.

 quantitative objectives for process quality and performance are established.

6. Capability level 5 : Optimizing

 focuses on continually improving process performance.

 performance is improved in both ways – incremental and innovation.

 UNIT 1: Introduction to Software Engineering
 emphasizes on studying the performance results across the organization to ensure that common
causes or issues are identified and fixed.

Process Patterns in Software Engineering

As the software team moves through the software process they encounter problems. It would be very useful if
solutions to these problems were readily available so that problems can be resolved quickly. Process-related
problems which are encountered during software engineering work, it identifies the encountered problem and in
which environment it is found, then it will suggest proven solutions to problem, they all are described by process
pattern. By solving problems a software team can construct a process that best meets needs of a project.

Uses of the process pattern:

At any level of abstraction, patterns can be defined. They can be used to describe a problem and solution associated
with framework activity in some situations. While in other situations patterns can be used to describe a problem and
solution associated with a complete process model.

Template:

 Pattern Name – Meaningful name must be given to a pattern within context of software process (e.g.
Technical Reviews).

 Forces – The issues that make problem visible and may affect its solution also environment in which pattern
is encountered.

Type:

It is of three types :

1. Stage pattern – Problems associated with a framework activity for process are described by stage pattern.
Establishing Communication might be an example of a staged pattern. This pattern would incorporate task
pattern Requirements Gathering and others.

2. Task-pattern – Problems associated with a software engineering action or work task and relevant to
successful software engineering practice (e.g., Requirements Gathering is a task pattern) are defined by task-
pattern.

3. Phase pattern – Even when the overall flow of activities is iterative in nature, it defines sequence of
framework activities that occurs within process. Spiral Model or Prototyping might be an example of a phase
pattern.

Initial Context: Conditions under which the pattern applies are described by initial context. Prior to the initiation of
the pattern :

1. What organizational or term-related activities have already occurred?

2. Entry state for the process?

3. Software engineering information or project information already exists?

For example, the Planning pattern requires that :

 Collaborative communication has been established between customers and software engineers.

 Successful completion of a number of task patterns for the communication pattern has occurred.

 The project constraints, basic requirements, and the project scope are known.

Problem: Any specific problem is to be solved by pattern.

 UNIT 1: Introduction to Software Engineering
Solution: Describes how to implement pattern successfully. This section describes how initial state of process is
modified as a consequence of initiation of pattern.

Resulting Context: Once the pattern has been successfully implemented, it describes conditions. Upon completion of
pattern :

1. Organizational or term-related activities must have occurred?

2. What should be the exit state for the process?

3. What software engineering information has been developed?

Related pattern: Provide a list of all process patterns that are directly related to this one. It can be represented n a
hierarchy or in some other diagrammatic form.

Known uses and Examples: In which the pattern is applicable, it indicates the specific instances. For example,
communication is mandatory at the beginning of every software project, is recommended throughout the software
project, and is mandatory once the deployment activity is underway.

Example of Process Pattern:

Let’s see an example of a process pattern to understand it more clearly.

Template:

Pattern Name: Prototyping Model Design

Intent: Requirements are not clear. So aim is to make an model iteratively to solidify the exact requirements.

Type: Phase Pattern

Initial Context: Before going to the prototyping these basic conditions should be made

1. Stakeholder has some idea about their requirements i.e. what they exactly want

2. Communication medium should be established between stakeholder and software development team to ensure
proper understanding about the requirements and future product

3. Initial understanding about other factors of project like scope of project, duration of project, budget of project etc.

Problem: Identifying and Solidifying the hazy and nonexistent requirements.

Solution: A description of the prototyping should be presented.

Resulting Context: A prototype model which can give a clear idea about the actual product and that needs to be
agreed by stakeholder.

Related Patterns: Requirement extraction, Iterative design, customer communication, Iterative development,
Customer assessment etc.

Known Uses & Examples: When stakeholder requirements are unclear and uncertain, prototyping is recommended.

Software Process Assessment

Software Process Assessment is a disciplined and organized examination of the software process which is being used
by any organization bases the on the process model. The Software Process Assessment includes many fields and
parts like identification and characterization of current practices, the ability of current practices to control or avoid
significant causes of poor (software) quality, cost, schedule and identifying areas of strengths and weaknesses of the
software.
 UNIT 1: Introduction to Software Engineering
Types of Software Assessment :

 Self Assessment : This is conducted internally by the people of their own organisation.

 Second Party assessment: This is conducted by an external team or people of the own organisation are
supervised by an external team.

 Third Party assessment:

In an ideal case Software Process Assessment should be performed in a transparent, open and collaborative
environment. This is very important for the improvement of the software and the development of the product. The
results of the Software Process Assessment are confidential and are only accessible to the company. The assessment
team must contain at least one person from the organization that is being assessed.

Software Process Maturity Assessment:

The scope of Software Process Assessment includes many components like it should cover all the processes in the
organisation, a selected subset of the software process or a specific project. The idea of process maturity serves as
the foundation for the majority of standard-based process evaluation methodologies.

Though an organisation is the assessment objective, even when the same approach is applied again, the outcomes of
a process evaluation may vary. The different results are mainly due to two reasons. The reasons are that the
organization that is being investigated must be determined. When the company is very large it is possible for the
company to have different definitions due to which the actual scope of appraisal may be different in successive
assessments. Even if it is the same organization the sample of projects selected to represent the organization may
affect the scope and result. Process maturity is important when the organisation intended to embark on an long
term improvement strategy.

Software Process Cycle:

Generally there are six different steps in the complete cycle:

 Selecting a team: The first step is to select all the team members. Everyone must be software professionals
with sound knowledge in software engineering.

 The standard process maturity questionnaire is filled out by the representatives of the site that will be
evaluated.

 In accordance with the CMM core process areas, the assessment team analyses the questionnaire results to
determine the areas that call for additional investigation.

 The evaluation team visits the location to learn more about the software procedures used there.

 The evaluation team compiles a set of results outlining the organization’s software process’s advantages and
disadvantages.

 In order to deliver the findings to the right audience, the assessment team creates a Key Process Area (KPA)
profile analysis.

SCAMPI;

SCAMPI stands for Standard CMMI Assessment Method for Process Improvement. To fulfil the demands of the
CMMI paradigm, the Standard CMMI Assessment Method for Process Improvement (SCAMPI) was created (Software
Engineering Institute, 2000). Moreover, it is based on the CBA IPI. The CBA IPI and SCAMPI both have three steps.

1. Plan and become ready

2. Carry out the evaluation on-site

3. Report findings
 UNIT 1: Introduction to Software Engineering
The planning and preparation phase includes the following activities:

 Describe the scope of the evaluation.

 Create the assessment strategy.

 Get the evaluation crew ready and trained.

 Make a quick evaluation of the participants.

 CMMI Appraisal Questionnaire distribution

 Look at the survey results.

 Perform a preliminary document evaluation.

The onsite evaluation phase includes the following activities:

 Display the results.

 Execute the findings.

 Complete / end the assessment.

Difference Between PSP and TSP

Software is the set of instructions in the form of programs to govern the computer system and process the hardware
components. To produce a software product a set of activities is used. This set is called a software process.

 In this article, we will see a difference between PSP and TSP.

 UNIT 1: Introduction to Software Engineering
PSP:

The personal software process is focused on individuals to improve their performance. The PSP is an individual
process, and it is a bottom-up approach to software process improvement. The PSP is a prescriptive process, it is a
more mature methodology with a well-defined set of tools and techniques.

Key Features of PSP :

 Process-focused: PSP is a process-focused methodology that emphasizes the importance of following a

disciplined approach to software development.

 Personalized: PSP is personalized to an individual’s skill level, experience, and work habits. It recognizes that
individuals have different strengths and weaknesses, and tailors the process to meet their specific needs.

 Metrics-driven: PSP is metrics-driven, meaning that it emphasizes the collection and analysis of data to
measure progress and identify areas for improvement.

 Incremental: PSP is incremental, meaning that it breaks down the development process into smaller, more
manageable pieces that can be completed in a step-by-step fashion.

 Quality-focused: PSP is quality-focused, meaning that it emphasizes the importance of producing high-
quality software that meets user requirements and is free of defects.

Advantages :

 Improved productivity: PSP provides a structured approach to software development that can help
individuals improve their productivity by breaking down the development process into smaller, more
manageable steps.

 Improved quality: PSP emphasizes the importance of producing high-quality software that meets user
requirements and is free of defects. By collecting and analyzing data throughout the development process,
individuals can identify and eliminate sources of errors and improve the quality of their work.

 Personalized approach: PSP is tailored to an individual’s skill level, experience, and work habits, which can
help individuals work more efficiently and effectively.

 Improved estimation: PSP emphasizes the importance of accurate estimation, which can help individuals
plan and execute projects more effectively.

 Continuous improvement: PSP promotes a culture of continuous improvement, which can help individuals
learn from past experiences and apply that knowledge to future projects.

Disadvantages :

 Time-consuming: PSP can be time-consuming, particularly when individuals are first learning the
methodology and need to collect and analyze data throughout the development process.

 Complex: PSP can be complex, particularly for individuals who are not familiar with software engineering
concepts or who have limited experience in software development.

 Heavy documentation: PSP requires a significant amount of documentation throughout the development
process, which can be burdensome for some individuals.

 Limited to individual use: PSP is designed for individual use, which means that it may not be suitable for
team-based software development projects.
 UNIT 1: Introduction to Software Engineering
TSP:

TSP is a team-based process. It is focused on team productivity. Basically, it is a top-down approach. The TSP is an
adaptive process, and process management methodology.

Key Features of TSP :

 Team-focused: TSP is team-focused, meaning that it emphasizes the importance of collaboration and
communication among team members throughout the software development process.

 Process-driven: TSP is process-driven, meaning that it provides a structured approach to software

development that emphasizes the importance of following a disciplined process.

 Metrics-driven: TSP is metrics-driven, meaning that it emphasizes the collection and analysis of data to
measure progress, identify areas for improvement, and make data-driven decisions.

 Incremental: TSP is incremental, meaning that it breaks down the development process into smaller, more
manageable pieces that can be completed in a step-by-step fashion.

 Quality-focused: TSP is quality-focused, meaning that it emphasizes the importance of producing high-
quality software that meets user requirements and is free of defects.

 Feedback-oriented: TSP is feedback-oriented, meaning that it emphasizes the importance of receiving

feedback from peers, mentors, and other stakeholders to identify areas for improvement.

Advantages of TSP :

 Improved productivity: TSP provides a structured approach to software development that can help teams
improve their productivity by breaking down the development process into smaller, more manageable steps.

 Improved quality: TSP emphasizes the importance of producing high-quality software that meets user
requirements and is free of defects. By collecting and analyzing data throughout the development process,
teams can identify and eliminate sources of errors and improve the quality of their work.

 Team collaboration: TSP promotes team collaboration, which can help teams work more efficiently and
effectively by leveraging the skills and expertise of all team members.

 Improved estimation: TSP emphasizes the importance of accurate estimation, which can help teams plan
and execute projects more effectively.

 Continuous improvement: TSP promotes a culture of continuous improvement, which can help teams learn
from past experiences and apply that knowledge to future projects.

Disadvantages of TSP :

 Time-consuming: TSP can be time-consuming, particularly when teams are first learning the methodology
and need to collect and analyze data throughout the development process.

 Complex: TSP can be complex, particularly for teams that are not familiar with software engineering
concepts or who have limited experience in software development.

 Heavy documentation: TSP requires a significant amount of documentation throughout the development
process, which can be burdensome for some teams.

 Requires discipline: TSP requires teams to follow a disciplined approach to software development, which
can be challenging for some teams who prefer a more flexible approach.

 Cost: TSP can be costly to implement, particularly if teams need to invest in training or software tools to
support the methodology.
 UNIT 1: Introduction to Software Engineering
PSP TSP

PSP is a project management process that defines how TSP is a project management process that defines
to manage a project in a face-to-face environment. how to manage a project in a virtual environment.

PSP is more formal and structured than TSP. TSP is less formal and structured than PSP.

PSP is based on the waterfall model. TSP is based on the agile model.

PSP is more suited for large projects. TSP is more suited for small projects.

TSP projects are typically completed in multiple

PSP projects are typically completed in one phase.
phases.

PSP is a high-level language and it is easy to learn and TSP is a low-level language and it is difficult to learn
use. and use.

PSP is a structured language and it is easy to read and TSP is an unstructured language and it is difficult to
write. read and write.

PSP programs are written in English and they are easy to TSP programs are written in assembly language and
understand. they are difficult to understand.

PSP is a portable language and it can be run on any TSP is a platform-dependent language and it can be
platform. run only on specific platforms.

PSP is an interpreted language and it does not need to TSP is a compiled language and it needs to be
be compiled. compiled before it can be run.

PSP is a free language and it can be downloaded from TSP is a commercial language and it is not available
the internet. for free.

PSP is an open-source language and it is available to TSP is a closed-source language and it is not available
everyone. to everyone.
 UNIT 1: Introduction to Software Engineering
Introduction of Process Management
A process is a program in execution. For example, when we write a program in C or C++ and compile it, the compiler
creates binary code. The original code and binary code are both programs. When we actually run the binary code, it
becomes a process. A process is an ‘active’ entity instead of a program, which is considered a ‘passive’ entity. A
single program can create many processes when run multiple times; for example, when we open a .exe or binary file
multiple times, multiple instances begin (multiple processes are created).

Process management includes various tools and techniques such as process mapping, process analysis, process
improvement, process automation, and process control. By applying these tools and techniques, organizations can
streamline their processes, eliminate waste, and improve productivity. Overall, process management is a critical
aspect of modern business operations and can help organizations achieve their goals and stay competitive in today’s
rapidly changing marketplace.

What is Process Management?

If the operating system supports multiple users then services under this are very important. In this regard, operating
systems have to keep track of all the completed processes, Schedule them, and dispatch them one after another.
However, the user should feel that he has full control of the CPU. Process management refers to the techniques and
strategies used by organizations to design, monitor, and control their business processes to achieve their goals
efficiently and effectively. It involves identifying the steps involved in completing a task, assessing the resources
required for each step, and determining the best way to execute the task.

Process management can help organizations improve their operational efficiency, reduce costs, increase customer
satisfaction, and maintain compliance with regulatory requirements. It involves analyzing the performance of
existing processes, identifying bottlenecks, and making changes to optimize the process flow.

Some of the systems call in this category are as follows.

 Create a child’s process identical to the parent’s.

 Terminate a process

 Wait for a child process to terminate

 Change the priority of the process

 Block the process

 Ready the process

 Dispatch a process

 Suspend a process

 Resume a process

 Delay a process

 Fork a process
 UNIT 1: Introduction to Software Engineering
How Does a Process Look Like in Memory?

The process looks like

Explanation of Process

 Text Section: A Process, sometimes known as the Text Section, also includes the current activity represented
by the value of the Program Counter.

 Stack: The stack contains temporary data, such as function parameters, returns addresses, and local
variables.

 Data Section: Contains the global variable.

 Heap Section: Dynamically memory allocated to process during its run time.

Key Components of Process Management

Below are some key component of process management.

 Process mapping: Creating visual representations of processes to understand how tasks flow, identify
dependencies, and uncover improvement opportunities.

 Process analysis: Evaluating processes to identify bottlenecks, inefficiencies, and areas for improvement.

 Process redesign: Making changes to existing processes or creating new ones to optimize workflows and
enhance performance.

 Process implementation: Introducing the redesigned processes into the organization and ensuring proper
execution.

 Process monitoring and control: Tracking process performance, measuring key metrics, and implementing
control mechanisms to maintain efficiency and effectiveness.

Importance of Process Management System

It is critical to comprehend the significance of process management for any manager overseeing a firm. It does more
than just make workflows smooth. Process Management makes sure that every part of business operations moves as
quickly as possible.

By implementing business processes management, we can avoid errors caused by inefficient human labor and cut
down on time lost on repetitive operations. It also keeps data loss and process step errors at bay. Additionally,
process management guarantees that resources are employed effectively, increasing the cost-effectiveness of our
company. Process management not only makes business operations better, but it also makes sure that our
procedures meet the needs of your clients. This raises income and improves consumer happiness.
 UNIT 1: Introduction to Software Engineering
Characteristics of a Process

A process has the following attributes.

 Process Id: A unique identifier assigned by the operating system.

 Process State: Can be ready, running, etc.

 CPU registers: Like the Program Counter (CPU registers must be saved and restored when a process is
swapped in and out of the CPU)

 Accounts information: Amount of CPU used for process execution, time limits, execution ID, etc

 I/O status information: For example, devices allocated to the process, open files, etc

 CPU scheduling information: For example, Priority (Different processes may have different priorities, for
example, a shorter process assigned high priority in the shortest job first scheduling)

All of the above attributes of a process are also known as the context of the process. Every process has its
own process control block(PCB), i.e. each process will have a unique PCB. All of the above attributes are part of the
PCB.

States of Process

A process is in one of the following states:

 New: Newly Created Process (or) being-created process.

 Ready: After the creation process moves to the Ready state, i.e. the process is ready for execution.

 Run: Currently running process in CPU (only one process at a time can be under execution in a single
processor)

 Wait (or Block): When a process requests I/O access.

 Complete (or Terminated): The process completed its execution.

 Suspended Ready: When the ready queue becomes full, some processes are moved to a suspended ready
state

 Suspended Block: When the waiting queue becomes full.

 UNIT 1: Introduction to Software Engineering
Context Switching of Process

The process of saving the context of one process and loading the context of another process is known as Context
Switching. In simple terms, it is like loading and unloading the process from the running state to the ready state.

When Does Context Switching Happen?

1. When a high-priority process comes to a ready state (i.e. with higher priority than the running process).
2. An Interrupt occurs.
3. User and kernel-mode switch (It is not necessary though)
4. Preemptive CPU scheduling is used.

Context Switch vs Mode Switch

A mode switch occurs when the CPU privilege level is changed, for example when a system call is made or a fault
occurs. The kernel works in more a privileged mode than a standard user task. If a user process wants to access
things that are only accessible to the kernel, a mode switch must occur. The currently executing process need not be
changed during a mode switch. A mode switch typically occurs for a process context switch to occur. Only
the kernel can cause a context switch.

CPU-Bound vs I/O-Bound Processes

A CPU-bound process requires more CPU time or spends more time in the running state. An I/O-bound process
requires more I/O time and less CPU time. An I/O-bound process spends more time in the waiting state.

Process planning is an integral part of the process management operating system. It refers to the mechanism used
by the operating system to determine which process to run next. The goal of process scheduling is to improve overall
system performance by maximizing CPU utilization, minimizing execution time, and improving system response
time.

Process Scheduling Algorithms

The operating system can use different scheduling algorithms to schedule processes. Here are some commonly used
timing algorithms:

 First-come, first-served (FCFS): This is the simplest scheduling algorithm, where the process is executed on a
first-come, first-served basis. FCFS is non-preemptive, which means that once a process starts executing, it
continues until it is finished or waiting for I/O.

 Shortest Job First (SJF): SJF is a proactive scheduling algorithm that selects the process with the shortest
burst time. The burst time is the time a process takes to complete its execution. SJF minimizes the average
waiting time of processes.

 Round Robin (RR): Round Robin is a proactive scheduling algorithm that reserves a fixed amount of time in a
round for each process. If a process does not complete its execution within the specified time, it is blocked
and added to the end of the queue. RR ensures fair distribution of CPU time to all processes and avoids
starvation.

 Priority Scheduling: This scheduling algorithm assigns priority to each process and the process with the
highest priority is executed first. Priority can be set based on process type, importance, or resource
requirements.

 Multilevel queue: This scheduling algorithm divides the ready queue into several separate queues, each
queue having a different priority. Processes are queued based on their priority, and each queue uses its own
scheduling algorithm. This scheduling algorithm is useful in scenarios where different types of processes
have different priorities.
 UNIT 1: Introduction to Software Engineering
Advantages of Process Management

 Improved Efficiency: Process management can help organizations identify bottlenecks and inefficiencies in
their processes, allowing them to make changes to streamline workflows and increase productivity.

 Cost Savings: By identifying and eliminating waste and inefficiencies, process management can help
organizations reduce costs associated with their business operations.

 Improved Quality: Process management can help organizations improve the quality of their products or
services by standardizing processes and reducing errors.

 Increased Customer Satisfaction: By improving efficiency and quality, process management can enhance the
customer experience and increase satisfaction.

 Compliance with Regulations: Process management can help organizations comply with regulatory
requirements by ensuring that processes are properly documented, controlled, and monitored.

Disadvantages of Process Management

 Time and Resource Intensive: Implementing and maintaining process management initiatives can be time-
consuming and require significant resources.

 Resistance to Change: Some employees may resist changes to established processes, which can slow down
or hinder the implementation of process management initiatives.

 Overemphasis on Process: Overemphasis on the process can lead to a lack of focus on customer needs and
other important aspects of business operations.

 Risk of Standardization: Standardizing processes too much can limit flexibility and creativity, potentially
stifling innovation.

 Difficulty in Measuring Results: Measuring the effectiveness of process management initiatives can be
difficult, making it challenging to determine their impact on organizational performance.

Waterfall Model – Software Engineering

The classical waterfall model is the basic software development life cycle model. It is very simple but idealistic.
Earlier this model was very popular but nowadays it is not used. But it is very important because all the other
software development life cycle models are based on the classical waterfall model.

Why Do We Use Waterfall Model?

The waterfall model is a software development model used in the context of large, complex projects, typically in the
field of information technology. It is characterized by a structured, sequential approach to project
management and software development.

The waterfall model is useful in situations where the project requirements are well-defined and the project goals are
clear. It is often used for large-scale projects with long timelines, where there is little room for error and the project
stakeholders need to have a high level of confidence in the outcome.

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 relies heavily 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.
 UNIT 1: Introduction to Software Engineering
4. Rigorous Planning: The waterfall model involves a rigorous planning process, where the project scope,
timelines, and deliverables are carefully defined and monitored throughout the project lifecycle.

Overall, the waterfall model is used in situations where there is a need for a highly structured and systematic
approach to software development. It can be effective in ensuring that large, complex projects are completed on
time and within budget, with a high level of quality and customer satisfaction.

Phases of Waterfall Model

Waterfall Model is a classical software development methodology that was first introduced by Winston W. Royce in
1970. It is a linear and sequential approach to software development that consists of several phases that must be
completed in a specific order.

The Waterfall Model has six phases:

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

2. Design Phase: 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. Implementation and Unit Testing: The implementation phase 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. Integration and System 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.

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.

The classical waterfall model divides the life cycle into a set of phases. This model considers that one phase can be
started after the completion of the previous phase. That is the output of one phase will be the input to the next
phase. Thus the development process can be considered as a sequential flow in the waterfall. Here the phases do
not overlap with each other. The different sequential phases of the classical waterfall model are shown in the below
figure.
 UNIT 1: Introduction to Software Engineering

Phases of Classical Waterfall Model

Let us now learn about each of these phases in detail.

1. Feasibility Study

The main goal of this phase is to determine whether it would be financially and technically feasible to develop the
software.
The feasibility study involves understanding the problem and then determining the various possible strategies to
solve the problem. These different identified solutions are analyzed based on their benefits and drawbacks, The best
solution is chosen and all the other phases are carried out as per this solution strategy.

2. Requirements Analysis and Specification

The aim of the requirement analysis and specification phase is to understand the exact requirements of the
customer and document them properly. This phase consists of two different activities.

 Requirement gathering and analysis: Firstly all the requirements regarding the software are gathered from
the customer and then the gathered requirements are analyzed. The goal of the analysis part is to remove
incompleteness (an incomplete requirement is one in which some parts of the actual requirements have
been omitted) and inconsistencies (an inconsistent requirement is one in which some part of the
requirement contradicts some other part).

 Requirement specification: These analyzed requirements are documented in a software requirement

specification (SRS) document. SRS document serves as a contract between the development team and
customers. Any future dispute between the customers and the developers can be settled by examining the
SRS document.

3. Design

The goal of this phase is to convert the requirements acquired in the SRS into a format that can be coded in a
programming language. It includes high-level and detailed design as well as the overall software architecture.
A Software Design Document is used to document all of this effort (SDD).
 UNIT 1: Introduction to Software Engineering
4. Coding and Unit Testing

In the coding phase software design is translated into source code using any suitable programming language. Thus
each designed module is coded. The aim of the unit testing phase is to check whether each module is working
properly or not.

5. Integration and System testing

Integration of different modules is undertaken soon after they have been coded and unit tested. Integration of
various modules is carried out incrementally over a number of steps. During each integration step, previously
planned modules are added to the partially integrated system and the resultant system is tested. Finally, after all the
modules have been successfully integrated and tested, the full working system is obtained and system testing is
carried out on this.
System testing consists of three different kinds of testing activities as described below.

 Alpha testing: Alpha testing is the system testing performed by the development team.

 Beta testing: Beta testing is the system testing performed by a friendly set of customers.

 Acceptance testing: After the software has been delivered, the customer performed acceptance testing to
determine whether to accept the delivered software or reject it.

6. Maintenance

Maintenance is the most important phase of a software life cycle. The effort spent on maintenance is 60% of the
total effort spent to develop a full software. There are basically three types of maintenance.

 Corrective Maintenance: This type of maintenance is carried out to correct errors that were not discovered
during the product development phase.

 Perfective Maintenance: This type of maintenance is carried out to enhance the functionalities of the
system based on the customer’s request.

 Adaptive Maintenance: Adaptive maintenance is usually required for porting the software to work in a new
environment such as working on a new computer platform or with a new operating system.

Advantages of Classical Waterfall Model

The classical waterfall model is an idealistic model for software development. It is very simple, so it can be
considered the basis for other software development life cycle models. Below are some of the major advantages of
this SDLC model.

 Easy to Understand: Classical Waterfall Model is very simple and easy to understand.

 Individual Processing: Phases in the Classical Waterfall model are processed one at a time.

 Properly Defined: In the classical waterfall model, each stage in the model is clearly defined.

 Clear Milestones: Classical Waterfall model has very clear and well-understood milestones.

 Properly Documented: Processes, actions, and results are very well documented.

 Reinforces Good Habits: Classical Waterfall Model reinforces good habits like define-before-design and
design-before-code.

 Working: Classical Waterfall Model works well for smaller projects and projects where requirements are
well understood.
 UNIT 1: Introduction to Software Engineering
Disadvantages of Classical Waterfall Model

The Classical Waterfall Model suffers from various shortcomings, basically, we can’t use it in real projects, but we
use other software development lifecycle models which are based on the classical waterfall model. Below are some
major drawbacks of this model.

 No Feedback Path: In the classical waterfall model evolution of software from one phase to another phase is
like a waterfall. It assumes that no error is ever committed by developers during any phase. Therefore, it
does not incorporate any mechanism for error correction.

 Difficult to accommodate Change Requests: This model assumes that all the customer requirements can be
completely and correctly defined at the beginning of the project, but actually customer’s requirements keep
on changing with time. It is difficult to accommodate any change requests after the requirements
specification phase is complete.

 No Overlapping of Phases: This model recommends that a new phase can start only after the completion of
the previous phase. But in real projects, this can’t be maintained. To increase efficiency and reduce cost,
phases may overlap.

 Limited Flexibility: The Waterfall Model is a rigid and linear approach to software development, which
means that it is not well-suited for projects with changing or uncertain requirements. Once a phase has been
completed, it is difficult to make changes or go back to a previous phase.

 Limited Stakeholder Involvement: The Waterfall Model is a structured and sequential approach, which
means that stakeholders are typically involved in the early phases of the project (requirements gathering
and analysis) but may not be involved in the later phases (implementation, testing, and deployment).

 Late Defect Detection: In the Waterfall Model, testing is typically done toward the end of the development
process. This means that defects may not be discovered until late in the development process, which can be
expensive and time-consuming to fix.

 Lengthy Development Cycle: The Waterfall Model can result in a lengthy development cycle, as each phase
must be completed before moving on to the next. This can result in delays and increased costs if
requirements change or new issues arise.

 Not Suitable for Complex Projects: The Waterfall Model is not well-suited for complex projects, as the linear
and sequential nature of the model can make it difficult to manage multiple dependencies and interrelated
components.

When to Use Waterfall Model?

Here are some cases where use of Waterfall Model is best suited:

 Only well-defined, unambiguous, and fixed requirements are employed with this paradigm.

 The definition of a product is constant.

 People understand technology.

 There are no unclear prerequisites.

 There are many resources with the necessary knowledge readily available.

 When it’s a brief project.

The Waterfall approach involves little client engagement in the product development process. The product can only
be shown to end consumers when it is ready.
 UNIT 1: Introduction to Software Engineering
Applications of Classical Waterfall Model

 Large-scale Software Development Projects: The Waterfall Model is often used for large-scale software
development projects, where a structured and sequential approach is necessary to ensure that the project is
completed on time and within budget.

 Safety-Critical Systems: The Waterfall Model is often used in the development of safety-critical systems,
such as aerospace or medical systems, where the consequences of errors or defects can be severe.

 Government and Defense Projects: The Waterfall Model is also commonly used in government and defense
projects, where a rigorous and structured approach is necessary to ensure that the project meets all
requirements and is delivered on time.

 Projects with well-defined Requirements: The Waterfall Model is best suited for projects with well-defined
requirements, as the sequential nature of the model requires a clear understanding of the project objectives
and scope.

 Projects with Stable Requirements: The Waterfall Model is also well-suited for projects with stable
requirements, as the linear nature of the model does not allow for changes to be made once a phase has
been completed.

Incremental Process Model – Software Engineering

The incremental process model is also known as the Successive version model. This article focuses on discussing the
Incremental Process Model in detail.

What is the Incremental Process Model?

First, a simple working system implementing only a few basic features is built and then that is delivered to the
customer. Then thereafter many successive iterations/ versions are implemented and delivered to the customer
until the desired system is released.

A, B, and C are modules of Software Products that are incrementally developed and delivered.

Life Cycle Activities

Requirements of Software are first broken down into several modules that can be incrementally constructed and
delivered.

1. At any time, the plan is made just for the next increment and not for any kind of long-term plan. Therefore, it
is easier to modify the version as per the need of the customer.

2. The Development Team first undertakes to develop core features (these do not need services from other
features) of the system.

3. Once the core features are fully developed, then these are refined to increase levels of capabilities by adding
new functions in Successive versions.

4. Each incremental version is usually developed using an iterative waterfall model of development.
 UNIT 1: Introduction to Software Engineering
5. As each successive version of the software is constructed and delivered, now the feedback of the Customer
is to be taken and these were then incorporated into the next version.

6. Each version of the software has more additional features than the previous ones.

7. After Requirements gathering and specification, requirements are then split into several different versions
starting with version 1, in each successive increment, the next version is constructed and then deployed at
the customer site.

8. After the last version (version n), it is now deployed at the client site.

Types of Incremental Model

1. Staged Delivery Model

Construction of only one part of the project at a time.

2. Parallel Development Model

Different subsystems are developed at the same time. It can decrease the calendar time needed for the
development, i.e. TTM (Time to Market) if enough resources are available.
 UNIT 1: Introduction to Software Engineering

When to use Incremental Process Model

1. Funding Schedule, Risk, Program Complexity, or need for early realization of benefits.

2. When Requirements are known up-front.

3. When Projects have lengthy development schedules.

4. Projects with new Technology.

 Error Reduction (core modules are used by the customer from the beginning of the phase and then
these are tested thoroughly).

 Uses divide and conquer for a breakdown of tasks.

 Lowers initial delivery cost.

 Incremental Resource Deployment.

5. Requires good planning and design.

6. The total cost is not lower.

7. Well-defined module interfaces are required.

Characteristics of Incremental Process Model

1. System development is divided into several smaller projects.

2. To create a final complete system, partial systems are constructed one after the other.

3. Priority requirements are addressed first.

4. The requirements for that increment are frozen once they are created.
 UNIT 1: Introduction to Software Engineering
Advantages of Incremental Process Model

1. Prepares the software fast.

2. Clients have a clear idea of the project.

3. Changes are easy to implement.

4. Provides risk handling support, because of its iterations.

5. Adjusting the criteria and scope is flexible and less costly.

6. Comparing this model to others, it is less expensive.

7. The identification of errors is simple.

Disadvantages of Incremental Process Model

1. A good team and proper planned execution are required.

2. Because of its continuous iterations the cost increases.

3. Issues may arise from the system design if all needs are not gathered upfront throughout the duration of the
program lifecycle.

4. Every iteration step is distinct and does not flow into the next.

5. It takes a lot of time and effort to fix an issue in one unit if it needs to be corrected in all the units.

Rapid application development model (RAD) – Software Engineering

The Rapid Application Development Model was first proposed by IBM in the 1980s. The RAD model is a type of
incremental process model in which there is an extremely short development cycle. When the requirements are fully
understood and the component-based construction approach is adopted then the RAD model is used. Various
phases in RAD are Requirements Gathering, Analysis and Planning, Design, Build or Construction, and finally
Deployment.

The critical feature of this model is the use of powerful development tools and techniques. A software project can be
implemented using this model if the project can be broken down into small modules wherein each module can be
assigned independently to separate teams. These modules can finally be combined to form the final product.
Development of each module involves the various basic steps as in the waterfall model i.e. analyzing, designing,
coding, and then testing, etc. as shown in the figure. Another striking feature of this model is a short period i.e. the
time frame for delivery(time-box) is generally 60-90 days.
 UNIT 1: Introduction to Software Engineering
Multiple teams work on developing the software system using the RAD model parallely.

The use of powerful developer tools such as JAVA, C++, Visual BASIC, XML, etc. is also an integral part of the projects.
This model consists of 4 basic phases:

1. Requirements Planning – It involves the use of various techniques used in requirements elicitation like
brainstorming, task analysis, form analysis, user scenarios, FAST (Facilitated Application Development
Technique), etc. It also consists of the entire structured plan describing the critical data, methods to obtain
it, and then processing it to form a final refined model.

2. User Description – This phase consists of taking user feedback and building the prototype using developer
tools. In other words, it includes re-examination and validation of the data collected in the first phase. The
dataset attributes are also identified and elucidated in this phase.

3. Construction – In this phase, refinement of the prototype and delivery takes place. It includes the actual use
of powerful automated tools to transform processes and data models into the final working product. All the
required modifications and enhancements are too done in this phase.

4. Cutover – All the interfaces between the independent modules developed by separate teams have to be
tested properly. The use of powerfully automated tools and subparts makes testing easier. This is followed
by acceptance testing by the user.

The process involves building a rapid prototype, delivering it to the customer, and taking feedback. After validation
by the customer, the SRS document is developed and the design is finalized.

When to use RAD Model?

When the customer has well-known requirements, the user is involved throughout the life cycle, the project can be
time-boxed, the functionality delivered in increments, high performance is not required, low technical risks are
involved and the system can be modularized. In these cases, we can use the RAD Model. when it is necessary to
design a system that can be divided into smaller units within two to three months. when there is enough money in
the budget to pay for both the expense of automated tools for code creation and designers for modeling.
 UNIT 1: Introduction to Software Engineering
Advantages:

 The use of reusable components helps to reduce the cycle time of the project.

 Feedback from the customer is available at the initial stages.

 Reduced costs as fewer developers are required.

 The use of powerful development tools results in better quality products in comparatively shorter time
spans.

 The progress and development of the project can be measured through the various stages.

 It is easier to accommodate changing requirements due to the short iteration time spans.

 Productivity may be quickly boosted with a lower number of employees.

Disadvantages:

 The use of powerful and efficient tools requires highly skilled professionals.

 The absence of reusable components can lead to the failure of the project.

 The team leader must work closely with the developers and customers to close the project on time.

 The systems which cannot be modularized suitably cannot use this model.

 Customer involvement is required throughout the life cycle.

 It is not meant for small-scale projects as in such cases, the cost of using automated tools and techniques
may exceed the entire budget of the project.

 Not every application can be used with RAD.

Applications:

1. This model should be used for a system with known requirements and requiring a short development time.

2. It is also suitable for projects where requirements can be modularized and reusable components are also
available for development.

3. The model can also be used when already existing system components can be used in developing a new
system with minimum changes.

4. This model can only be used if the teams consist of domain experts. This is because relevant knowledge and
the ability to use powerful techniques are a necessity.

5. The model should be chosen when the budget permits the use of automated tools and techniques required.

Drawbacks of rapid application development:

 It requires multiple teams or a large number of people to work on the scalable projects.

 This model requires heavily committed developer and customers. If commitment is lacking then RAD
projects will fail.

 The projects using RAD model requires heavy resources.

 If there is no appropriate modularization then RAD projects fail. Performance can be problem to such
projects.

 The projects using RAD model find it difficult to adopt new technologies.
 UNIT 1: Introduction to Software Engineering
Prototyping Model – Software Engineering
Prototyping is defined as the process of developing a working replication of a product or system that has to be
engineered. It offers a small-scale facsimile of the end product and is used for obtaining customer feedback. The
Prototyping concept is described below:

The Prototyping Model is one of the most popularly used Software Development Life Cycle Models (SDLC models).
This model is used when the customers do not know the exact project requirements beforehand. In this model, a
prototype of the end product is first developed, tested, and refined as per customer feedback repeatedly till a final
acceptable prototype is achieved which forms the basis for developing the final product.

Prototyping Concept

In this process model, the system is partially implemented before or during the analysis phase thereby giving the
customers an opportunity to see the product early in the life cycle. The process starts by interviewing the customers
and developing the incomplete high-level paper model. This document is used to build the initial prototype
supporting only the basic functionality as desired by the customer. Once the customer figures out the problems, the
prototype is further refined to eliminate them. The process continues until the user approves the prototype and
finds the working model to be satisfactory.

Steps Prototyping Model

Step 1: Requirement Gathering and Analysis: This is the initial step in designing a prototype model. In this phase,
users are asked about what they expect or what they want from the system.

Step 2: Quick Design: This is the second step in Prototyping Model. This model covers the basic design of the
requirement through which a quick overview can be easily described.

Step 3: Build a Prototype: This step helps in building an actual prototype from the knowledge gained from prototype
design.

Step 4: Initial User Evaluation: This step describes the preliminary testing where the investigation of the
performance model occurs, as the customer will tell the strength and weaknesses of the design, which was sent to
the developer.

Step 5: Refining Prototype: If any feedback is given by the user, then improving the client’s response to feedback
and suggestions, the final system is approved.

Step 6: Implement Product and Maintain: This is the final step in the phase of the Prototyping Model where the
final system is tested and distributed to production, here the program is run regularly to prevent failures.
 UNIT 1: Introduction to Software Engineering

Prototyping Models
 UNIT 1: Introduction to Software Engineering
Types of Prototyping Models

There are four types of Prototyping Models, which are described below.

 Rapid Throwaway Prototyping

 Evolutionary Prototyping

 Incremental Prototyping

 Extreme Prototyping

1. Rapid Throwaway Prototyping

This technique offers a useful method of exploring ideas and getting customer feedback for each of them. In this
method, a developed prototype need not necessarily be a part of the ultimately accepted prototype. Customer
feedback helps in preventing unnecessary design faults and hence, the final prototype developed is of better
quality.

2. Evolutionary Prototyping

In this method, the prototype developed initially is incrementally refined on the basis of customer feedback till it
finally gets accepted. In comparison to Rapid Throwaway Prototyping, it offers a better approach that saves time as
well as effort. This is because developing a prototype from scratch for every iteration of the process can sometimes
be very frustrating for the developers.

3. Incremental Prototyping

In this type of incremental prototyping, the final expected product is broken into different small pieces of prototypes
and developed individually. In the end, when all individual pieces are properly developed, then the different
prototypes are collectively merged into a single final product in their predefined order. It’s a very efficient approach
that reduces the complexity of the development process, where the goal is divided into sub-parts and each sub-part
is developed individually. The time interval between the project’s beginning and final delivery is substantially
reduced because all parts of the system are prototyped and tested simultaneously. Of course, there might be the
possibility that the pieces just do not fit together due to some lack of ness in the development phase – this can only
be fixed by careful and complete plotting of the entire system before prototyping starts.

4. Extreme Prototyping

This method is mainly used for web development. It consists of three sequential independent phases:

1. In this phase, a basic prototype with all the existing static pages is presented in HTML format.

2. In the 2nd phase, Functional screens are made with a simulated data process using a prototype services
layer.

3. This is the final step where all the services are implemented and associated with the final prototype.

This Extreme Prototyping method makes the project cycling and delivery robust and fast and keeps the entire
developer team focused and centralized on product deliveries rather than discovering all possible needs and
specifications and adding necessitated features.

Advantages of Prototyping Model

 The customers get to see the partial product early in the life cycle. This ensures a greater level of customer
satisfaction and comfort.

 New requirements can be easily accommodated as there is scope for refinement.

 Missing functionalities can be easily figured out.

 UNIT 1: Introduction to Software Engineering
 Errors can be detected much earlier thereby saving a lot of effort and cost, besides enhancing the quality of
the software.

 The developed prototype can be reused by the developer for more complicated projects in the future.

 Flexibility in design.

 Early feedback from customers and stakeholders can help guide the development process and ensure that
the final product meets their needs and expectations.

 Prototyping can be used to test and validate design decisions, allowing for adjustments to be made before
significant resources are invested in development.

 Prototyping can help reduce the risk of project failure by identifying potential issues and addressing them
early in the process.

 Prototyping can facilitate communication and collaboration among team members and stakeholders,
improving overall project efficiency and effectiveness.

 Prototyping can help bridge the gap between technical and non-technical stakeholders by providing a
tangible representation of the product.

Disadvantages of the Prototyping Model

 Costly with respect to time as well as money.

 There may be too much variation in requirements each time the prototype is evaluated by the customer.

 Poor Documentation due to continuously changing customer requirements.

 It is very difficult for developers to accommodate all the changes demanded by the customer.

 There is uncertainty in determining the number of iterations that would be required before the prototype is
finally accepted by the customer.

 After seeing an early prototype, the customers sometimes demand the actual product to be delivered soon.

 Developers in a hurry to build prototypes may end up with sub-optimal solutions.

 The customer might lose interest in the product if he/she is not satisfied with the initial prototype.

 The prototype may not be scalable to meet the future needs of the customer.

 The prototype may not accurately represent the final product due to limited functionality or incomplete
features.

 The focus on prototype development may shift the focus away from the final product, leading to delays in
the development process.

 The prototype may give a false sense of completion, leading to the premature release of the product.

 The prototype may not consider technical feasibility and scalability issues that can arise during the final
product development.

 The prototype may be developed using different tools and technologies, leading to additional training and
maintenance costs.

 The prototype may not reflect the actual business requirements of the customer, leading to dissatisfaction
with the final product.
 UNIT 1: Introduction to Software Engineering
Applications of Prototyping Model

 The Prototyping Model should be used when the requirements of the product are not clearly understood or
are unstable.

 The prototyping model can also be used if requirements are changing quickly.

 This model can be successfully used for developing user interfaces, high-technology software-intensive
systems, and systems with complex algorithms and interfaces.

 The prototyping Model is also a very good choice to demonstrate the technical feasibility of the product.

Spiral Model – Software Engineering

The Spiral Model is one of the most important Software Development Life Cycle models, which provides support
for Risk Handling. This article focuses on discussing the Spiral Model in detail.

What is the Spiral Model?

The Spiral Model is a Software Development Life Cycle (SDLC) model that provides a systematic and iterative
approach to software development. In its diagrammatic representation, looks like a spiral with many loops. The
exact number of loops of the spiral is unknown and can vary from project to project. Each loop of the spiral is called
a Phase of the software development process.

1. The exact number of phases needed to develop the product can be varied by the project manager depending
upon the project risks.

2. As the project manager dynamically determines the number of phases, the project manager has an
important role in developing a product using the spiral model.

3. It is based on the idea of a spiral, with each iteration of the spiral representing a complete software
development cycle, from requirements gathering and analysis to design, implementation, testing, and
maintenance.

What Are the Phases of Spiral Model?

The Spiral Model is a risk-driven model, meaning that the focus is on managing risk through multiple iterations of the
software development process. It consists of the following phases:

1. Planning

The first phase of the Spiral Model is the planning phase, where the scope of the project is determined and a plan is
created for the next iteration of the spiral.

2. Risk Analysis

In the risk analysis phase, the risks associated with the project are identified and evaluated.

3. Engineering

In the engineering phase, the software is developed based on the requirements gathered in the previous iteration.

4. Evaluation

In the evaluation phase, the software is evaluated to determine if it meets the customer’s requirements and if it is of
high quality.

5. Planning

The next iteration of the spiral begins with a new planning phase, based on the results of the evaluation.
 UNIT 1: Introduction to Software Engineering
The Spiral Model is often used for complex and large software development projects, as it allows for a more flexible
and adaptable approach to software development. It is also well-suited to projects with significant uncertainty or
high levels of risk.

The Radius of the spiral at any point represents the expenses(cost) of the project so far, and the angular dimension
represents the progress made so far in the current phase.

Spiral Model

Each phase of the Spiral Model is divided into four quadrants as shown in the above figure. The functions of these
four quadrants are discussed below:

1. Objectives determination and identify alternative solutions: Requirements are gathered from the
customers and the objectives are identified, elaborated, and analyzed at the start of every phase. Then
alternative solutions possible for the phase are proposed in this quadrant.

2. Identify and resolve Risks: During the second quadrant, all the possible solutions are evaluated to select the
best possible solution. Then the risks associated with that solution are identified and the risks are resolved
using the best possible strategy. At the end of this quadrant, the Prototype is built for the best possible
solution.

3. Develop the next version of the Product: During the third quadrant, the identified features are developed
and verified through testing. At the end of the third quadrant, the next version of the software is available.

4. Review and plan for the next Phase: In the fourth quadrant, the Customers evaluate the so-far developed
version of the software. In the end, planning for the next phase is started.

Risk Handling in Spiral Model

A risk is any adverse situation that might affect the successful completion of a software project. The most important
feature of the spiral model is handling these unknown risks after the project has started. Such risk resolutions are
easier done by developing a prototype.
 UNIT 1: Introduction to Software Engineering
1. The spiral model supports coping with risks by providing the scope to build a prototype at every phase of
software development.

2. The Prototyping Model also supports risk handling, but the risks must be identified completely before the
start of the development work of the project.

3. But in real life, project risk may occur after the development work starts, in that case, we cannot use the
Prototyping Model.

4. In each phase of the Spiral Model, the features of the product dated and analyzed, and the risks at that point
in time are identified and are resolved through prototyping.

5. Thus, this model is much more flexible compared to other SDLC models.

Why Spiral Model is called Meta Model?

The Spiral model is called a Meta-Model because it subsumes all the other SDLC models. For example, a single loop
spiral actually represents the Iterative Waterfall Model.

1. The spiral model incorporates the stepwise approach of the Classical Waterfall Model.

2. The spiral model uses the approach of the Prototyping Model by building a prototype at the start of each
phase as a risk-handling technique.

3. Also, the spiral model can be considered as supporting the Evolutionary model – the iterations along the
spiral can be considered as evolutionary levels through which the complete system is built.

Advantages of the Spiral Model

Below are some advantages of the Spiral Model.

1. Risk Handling: The projects with many unknown risks that occur as the development proceeds, in that case,
Spiral Model is the best development model to follow due to the risk analysis and risk handling at every
phase.

2. Good for large projects: It is recommended to use the Spiral Model in large and complex projects.

3. Flexibility in Requirements: Change requests in the Requirements at a later phase can be incorporated
accurately by using this model.

4. Customer Satisfaction: Customers can see the development of the product at the early phase of the
software development and thus, they habituated with the system by using it before completion of the total
product.

5. Iterative and Incremental Approach: The Spiral Model provides an iterative and incremental approach to
software development, allowing for flexibility and adaptability in response to changing requirements or
unexpected events.

6. Emphasis on Risk Management: The Spiral Model places a strong emphasis on risk management, which
helps to minimize the impact of uncertainty and risk on the software development process.

7. Improved Communication: The Spiral Model provides for regular evaluations and reviews, which can
improve communication between the customer and the development team.

8. Improved Quality: The Spiral Model allows for multiple iterations of the software development process,
which can result in improved software quality and reliability.
 UNIT 1: Introduction to Software Engineering
Disadvantages of the Spiral Model

Below are some main disadvantages of the spiral model.

1. Complex: The Spiral Model is much more complex than other SDLC models.

2. Expensive: Spiral Model is not suitable for small projects as it is expensive.

3. Too much dependability on Risk Analysis: The successful completion of the project is very much dependent
on Risk Analysis. Without very highly experienced experts, it is going to be a failure to develop a project
using this model.

4. Difficulty in time management: As the number of phases is unknown at the start of the project, time
estimation is very difficult.

5. Complexity: The Spiral Model can be complex, as it involves multiple iterations of the software development
process.

6. Time-Consuming: The Spiral Model can be time-consuming, as it requires multiple evaluations and reviews.

7. Resource Intensive: The Spiral Model can be resource-intensive, as it requires a significant investment in
planning, risk analysis, and evaluations.

The most serious issue we face in the cascade model is that taking a long length to finish the item, and the product
became obsolete. To tackle this issue, we have another methodology, which is known as the Winding model or spiral
model. The winding model is otherwise called the cyclic model.

When To Use the Spiral Model?

1. When a project is vast in software engineering, a spiral model is utilized.

2. A spiral approach is utilized when frequent releases are necessary.

3. When it is appropriate to create a prototype

4. When evaluating risks and costs is crucial

5. The spiral approach is beneficial for projects with moderate to high risk.

6. The SDLC’s spiral model is helpful when requirements are complicated and ambiguous.

7. If modifications are possible at any moment

8. When committing to a long-term project is impractical owing to shifting economic priorities.

 UNIT 3 : Software Testing Basics
Software Testing Tutorial
The Software Testing Tutorial serves as a comprehensive guide for learning Software Testing. It covers all software
testing basics to the most advanced concepts, making it beneficial for both beginners and experienced professionals.

Software testing is a process that involves evaluating and examining computer software or applications to ensure
they function correctly and meet the desired requirements. It involves identifying any errors, gaps, or missing
requirements that may negatively affect the software’s performance, usability, functionality, or security.

In this tutorial, you will learn the fundamental concepts of software testing, including black box testing, white box
testing, visual box testing, grey box testing, and more. This tutorial follows a structured approach, starting with the
basics and gradually progressing to more advanced topics as you move through the tutorial. Get ready to enhance
your knowledge and skills in software testing!

Software Testing Tutorial

What is Testing?

Testing is a collection of methods to evaluate an application’s suitability for use in accordance with a predetermined
script, however, testing is not able to detect every application flaw. The basic goal of testing is to find application
flaws so that they may be identified and fixed. It merely shows that a product doesn’t work in some particular
circumstances, not that it works correctly under all circumstances.

Testing offers comparisons between software behavior and state and mechanisms since mechanisms can identify
problems in software. The method may incorporate previous iterations of the same or similar items, comparable
goods, expected-purpose interfaces, pertinent standards, or other criteria, but is not restricted to these.

What is Software Testing?

Software testing involves executing a program to identify any error or bug in the software product’s code. This
process takes into account all aspects of the software, including its reliability, scalability, portability, reusability, and
usability. The main goal of software testing is to ensure that the system and its components meet the specified
requirements and work accurately in every case.
 UNIT 3 : Software Testing Basics
Why Learn Software Testing?

Here are the following that it is important to learn Software Testing:

 Helps to create reliable software: Software testing is compulsory to provide facilities to the customers like
the delivery of software applications which require maintenance costs, and need to be more accurate,
consistent, and reliable.

 Helps to deliver quality products: It is very important to check the quality of the product. Quality products
delivered to the customers help in gaining their profitable and effective output this can be done by using
software testing methods.

 Helps to achieve effective performance: Software testing is required for the effective performance of the
software application or software product.

 Ensures application is failure-free: Software testing ensures that the application should not result in any
failures because the cost of fixing is larger in the later stage of the development of software.

 Helps to detect bugs: Software testing points out the defect and errors made during the development phase
which helps individuals receive quality products.

Software Testing Strategies

Software testing is the process of evaluating a software application to identify if it meets specified requirements and
to identify any defects. The following are common testing strategies:

1. Black box testing – Tests the functionality of the software without looking at the internal code structure.

2. White box testing – Tests the internal code structure and logic of the software.

3. Unit testing – Tests individual units or components of the software to ensure they are functioning as
intended.

4. Integration testing – Tests the integration of different components of the software to ensure they work
together as a system.

5. Functional testing – Tests the functional requirements of the software to ensure they are met.

6. System testing – Tests the complete software system to ensure it meets the specified requirements.

7. Acceptance testing – Tests the software to ensure it meets the customer’s or end-user’s expectations.

8. Regression testing – Tests the software after changes or modifications have been made to ensure the
changes have not introduced new defects.

9. Performance testing – Tests the software to determine its performance characteristics such as speed,
scalability, and stability.

10. Security testing – Tests the software to identify vulnerabilities and ensure it meets security requirements.

Software Testing is a type of investigation to find out if there is any default or error present in the software so that
the errors can be reduced or removed to increase the quality of the software and to check whether it fulfills the
specifies requirements or not.
According to Glen Myers, software testing has the following objectives:

 The process of investigating and checking a program to find whether there is an error or not and does it
fulfill the requirements or not is called testing.

 When the number of errors found during the testing is high, it indicates that the testing was good and is a
sign of good test case.
 UNIT 3 : Software Testing Basics
The main objective of software testing is to design the tests in such a way that it systematically finds different types
of errors without taking much time and effort so that less time is required for the development of the software. The
overall strategy for testing software includes:

1. Before testing starts, it’s necessary to identify and specify the requirements of the product in a
quantifiable manner. Different characteristics quality of the software is there such as maintainability that
means the ability to update and modify, the probability that means to find and estimate any risk, and
usability that means how it can easily be used by the customers or end-users. All these characteristic
qualities should be specified in a particular order to obtain clear test results without any error.

2. Specifying the objectives of testing in a clear and detailed manner. Several objectives of testing are there
such as effectiveness that means how effectively the software can achieve the target, any failure that means
inability to fulfill the requirements and perform functions, and the cost of defects or errors that mean the
cost required to fix the error. All these objectives should be clearly mentioned in the test plan.

3. For the software, identifying the user’s category and developing a profile for each user. Use cases describe
the interactions and communication among different classes of users and the system to achieve the target.
So as to identify the actual requirement of the users and then testing the actual use of the product.

4. Developing a test plan to give value and focus on rapid-cycle testing. Rapid Cycle Testing is a type of test
that improves quality by identifying and measuring the any changes that need to be required for improving
the process of software. Therefore, a test plan is an important and effective document that helps the tester
to perform rapid cycle testing.

5. Robust software is developed that is designed to test itself. The software should be capable of detecting or
identifying different classes of errors. Moreover, software design should allow automated and regression
testing which tests the software to find out if there is any adverse or side effect on the features of software
due to any change in code or program.

6. Before testing, using effective formal reviews as a filter. Formal technical reviews is technique to identify
the errors that are not discovered yet. The effective technical reviews conducted before testing reduces a
significant amount of testing efforts and time duration required for testing software so that the overall
development time of software is reduced.
 UNIT 3 : Software Testing Basics
7. Conduct formal technical reviews to evaluate the nature, quality or ability of the test strategy and test
cases. The formal technical review helps in detecting any unfilled gap in the testing approach. Hence, it is
necessary to evaluate the ability and quality of the test strategy and test cases by technical reviewers to
improve the quality of software.

8. For the testing process, developing a approach for the continuous development. As a part of a statistical
process control approach, a test strategy that is already measured should be used for software testing to
measure and control the quality during the development of software.

Advantages or Disadvantages:

Advantages of software testing:

1. Improves software quality and reliability – Testing helps to identify and fix defects early in the development
process, reducing the risk of failure or unexpected behavior in the final product.

2. Enhances user experience – Testing helps to identify usability issues and improve the overall user
experience.

3. Increases confidence – By testing the software, developers and stakeholders can have confidence that the
software meets the requirements and works as intended.

4. Facilitates maintenance – By identifying and fixing defects early, testing makes it easier to maintain and
update the software.

5. Reduces costs – Finding and fixing defects early in the development process is less expensive than fixing
them later in the life cycle.

Disadvantages of software testing:

1. Time-consuming – Testing can take a significant amount of time, particularly if thorough testing is
performed.

2. Resource-intensive – Testing requires specialized skills and resources, which can be expensive.

3. Limited coverage – Testing can only reveal defects that are present in the test cases, and it is possible for
defects to be missed.

4. Unpredictable results – The outcome of testing is not always predictable, and defects can be hard to
replicate and fix.

5. Delays in delivery – Testing can delay the delivery of the software if testing takes longer than expected or if
significant defects are identified.

Types of Software Testing

In this section, we are going to understand the various types of software testing, which can be used at the time of
the Software Development Life Cycle.

As we know, software testing is a process of analyzing an application's functionality as per the customer
prerequisite.

If we want to ensure that our software is bug-free or stable, we must perform the various types of software testing
because testing is the only method that makes our application bug-free.
 UNIT 3 : Software Testing Basics

The different types of Software Testing

The categorization of software testing is a part of diverse testing activities, such as test strategy, test deliverables, a
defined test objective, etc. And software testing is the execution of the software to find defects.

The purpose of having a testing type is to confirm the AUT (Application Under Test).

To start testing, we should have a requirement, application-ready, necessary resources available. To maintain
accountability, we should assign a respective module to different test engineers.

The software testing mainly divided into two parts, which are as follows:

o Manual Testing

o Automation Testing
 UNIT 3 : Software Testing Basics
What is Manual Testing?

Testing any software or an application according to the client's needs without using any automation tool is known
as manual testing.

In other words, we can say that it is a procedure of verification and validation. Manual testing is used to verify the
behavior of an application or software in contradiction of requirements specification.

We do not require any precise knowledge of any testing tool to execute the manual test cases. We can easily
prepare the test document while performing manual testing on any application.

To get in-detail information about manual testing, click on the following link: https://www.javatpoint.com/manual-
testing.

Classification of Manual Testing

In software testing, manual testing can be further classified into three different types of testing, which are as
follows:

o White Box Testing

o Black Box Testing

o Grey Box Testing

For our better understanding let's see them one by one:

White Box Testing

In white-box testing, the developer will inspect every line of code before handing it over to the testing team or the
concerned test engineers.
 UNIT 3 : Software Testing Basics

Subsequently, the code is noticeable for developers throughout testing; that's why this process is known as WBT
(White Box Testing).

In other words, we can say that the developer will execute the complete white-box testing for the particular
software and send the specific application to the testing team.

The purpose of implementing the white box testing is to emphasize the flow of inputs and outputs over the software
and enhance the security of an application.

ADVERTISEMENT

White box testing is also known as open box testing, glass box testing, structural testing, clear box testing, and
transparent box testing.

To get the in-depth knowledge about white box testing refers to the below link: https://www.javatpoint.com/white-
box-testing.

Black Box Testing

Another type of manual testing is black-box testing. In this testing, the test engineer will analyze the software
against requirements, identify the defects or bug, and sends it back to the development team.
 UNIT 3 : Software Testing Basics
Then, the developers will fix those defects, do one round of White box testing, and send it to the testing team.

Here, fixing the bugs means the defect is resolved, and the particular feature is working according to the given
requirement.

ADVERTISEMENT

ADVERTISEMENT

The main objective of implementing the black box testing is to specify the business needs or the customer's
requirements.

In other words, we can say that black box testing is a process of checking the functionality of an application as per
the customer requirement. The source code is not visible in this testing; that's why it is known as black-box testing.

Types of Black Box Testing

Black box testing further categorizes into two parts, which are as discussed below:

o Functional Testing

o Non-function Testing

Functional Testing

The test engineer will check all the components systematically against requirement specifications is known
as functional testing. Functional testing is also known as Component testing.

In functional testing, all the components are tested by giving the value, defining the output, and validating the actual
output with the expected value.

ADVERTISEMENT

Functional testing is a part of black-box testing as its emphases on application requirement rather than actual code.
The test engineer has to test only the program instead of the system.
 UNIT 3 : Software Testing Basics
Types of Functional Testing

Just like another type of testing is divided into several parts, functional testing is also classified into various
categories.

The diverse types of Functional Testing contain the following:

o Unit Testing

o Integration Testing

o System Testing

Now, Let's understand them one by one:

1. Unit Testing

Unit testing is the first level of functional testing in order to test any software. In this, the test engineer will test the
module of an application independently or test all the module functionality is called unit testing.

The primary objective of executing the unit testing is to confirm the unit components with their performance. Here,
a unit is defined as a single testable function of a software or an application. And it is verified throughout the
specified application development phase.

Click on the below link to get the complete information about unit testing: https://www.javatpoint.com/unit-testing.

2. Integration Testing

Once we are successfully implementing the unit testing, we will go integration testing. It is the second level of
functional testing, where we test the data flow between dependent modules or interface between two features is
called integration testing.

The purpose of executing the integration testing is to test the statement's accuracy between each module.

Types of Integration Testing

Integration testing is also further divided into the following parts:

o Incremental Testing

o Non-Incremental Testing
 UNIT 3 : Software Testing Basics

Incremental Integration Testing

Whenever there is a clear relationship between modules, we go for incremental integration testing. Suppose, we
take two modules and analysis the data flow between them if they are working fine or not.

If these modules are working fine, then we can add one more module and test again. And we can continue with the
same process to get better results.

ADVERTISEMENT

In other words, we can say that incrementally adding up the modules and test the data flow between the modules is
known as Incremental integration testing.

Types of Incremental Integration Testing

Incremental integration testing can further classify into two parts, which are as follows:

1. Top-down Incremental Integration Testing

2. Bottom-up Incremental Integration Testing

Let's see a brief introduction of these types of integration testing:

1. Top-down Incremental Integration Testing

In this approach, we will add the modules step by step or incrementally and test the data flow between them. We
have to ensure that the modules we are adding are the child of the earlier ones.

2. Bottom-up Incremental Integration Testing

In the bottom-up approach, we will add the modules incrementally and check the data flow between modules. And
also, ensure that the module we are adding is the parent of the earlier ones.

Non-Incremental Integration Testing/ Big Bang Method

Whenever the data flow is complex and very difficult to classify a parent and a child, we will go for the non-
incremental integration approach. The non-incremental method is also known as the Big Bang method.
 UNIT 3 : Software Testing Basics
3. System Testing

Whenever we are done with the unit and integration testing, we can proceed with the system testing.

In system testing, the test environment is parallel to the production environment. It is also known as end-to-
end testing.

In this type of testing, we will undergo each attribute of the software and test if the end feature works according to
the business requirement. And analysis the software product as a complete system.

Click on the below link to get the complete information about system testing: https://www.javatpoint.com/system-
testing.

ADVERTISEMENT

Non-function Testing

The next part of black-box testing is non-functional testing. It provides detailed information on software product
performance and used technologies.

Non-functional testing will help us minimize the risk of production and related costs of the software.

Non-functional testing is a combination of performance, load, stress, usability and, compatibility testing.

For more information about Non-functional testing, refer to the following link: https://www.javatpoint.com/non-
functional-testing.

Types of Non-functional Testing

Non-functional testing categorized into different parts of testing, which we are going to discuss further:

o Performance Testing

o Usability Testing

o Compatibility Testing
 UNIT 3 : Software Testing Basics
1. Performance Testing

In performance testing, the test engineer will test the working of an application by applying some load.

In this type of non-functional testing, the test engineer will only focus on several aspects, such as Response time,
Load, scalability, and Stability of the software or an application.

Classification of Performance Testing

Performance testing includes the various types of testing, which are as follows:

o Load Testing

o Stress Testing

o Scalability Testing

o Stability Testing

o Load Testing

While executing the performance testing, we will apply some load on the particular application to check the
application's performance, known as load testing. Here, the load could be less than or equal to the desired load.

It will help us to detect the highest operating volume of the software and bottlenecks.

o Stress Testing

It is used to analyze the user-friendliness and robustness of the software beyond the common functional limits.

Primarily, stress testing is used for critical software, but it can also be used for all types of software applications.

o Scalability Testing

To analysis, the application's performance by enhancing or reducing the load in particular balances is known
as scalability testing.

ADVERTISEMENT

In scalability testing, we can also check the system, processes, or database's ability to meet an upward need. And in
this, the Test Cases are designed and implemented efficiently.

o Stability Testing

Stability testing is a procedure where we evaluate the application's performance by applying the load for a precise
time.

It mainly checks the constancy problems of the application and the efficiency of a developed product. In this type of
testing, we can rapidly find the system's defect even in a stressful situation.
 UNIT 3 : Software Testing Basics
2. Usability Testing

Another type of non-functional testing is usability testing. In usability testing, we will analyze the user-friendliness
of an application and detect the bugs in the software's end-user interface.

Here, the term user-friendliness defines the following aspects of an application:

o The application should be easy to understand, which means that all the features must be visible to end-
users.

o The application's look and feel should be good that means the application should be pleasant looking and
make a feel to the end-user to use it.

3. Compatibility Testing

In compatibility testing, we will check the functionality of an application in specific hardware and software
environments. Once the application is functionally stable then only, we go for compatibility testing.

Here, software means we can test the application on the different operating systems and other browsers,
and hardware means we can test the application on different sizes.

ADVERTISEMENT

Grey Box Testing

Another part of manual testing is Grey box testing. It is a collaboration of black box and white box testing.

Since, the grey box testing includes access to internal coding for designing test cases. Grey box testing is performed
by a person who knows coding as well as testing.

In other words, we can say that if a single-person team done both white box and black-box testing, it is
considered grey box testing.

Automation Testing

The most significant part of Software testing is Automation testing. It uses specific tools to automate manual design
test cases without any human interference.

Automation testing is the best way to enhance the efficiency, productivity, and coverage of Software testing.

It is used to re-run the test scenarios, which were executed manually, quickly, and repeatedly.
 UNIT 3 : Software Testing Basics
In other words, we can say that whenever we are testing an application by using some tools is known as automation
testing.

We will go for automation testing when various releases or several regression cycles goes on the application or
software. We cannot write the test script or perform the automation testing without understanding the
programming language.

Some other types of Software Testing

In software testing, we also have some other types of testing that are not part of any above discussed testing, but
those testing are required while testing any software or an application.

o Smoke Testing

o Sanity Testing

o Regression Testing

o User Acceptance Testing

o Exploratory Testing

o Adhoc Testing

o Security Testing

o Globalization Testing

Let's understand those types of testing one by one:

In smoke testing, we will test an application's basic and critical features before doing one round of deep and
rigorous testing.

Or before checking all possible positive and negative values is known as smoke testing. Analyzing the workflow of
the application's core and main functions is the main objective of performing the smoke testing.

Sanity Testing

It is used to ensure that all the bugs have been fixed and no added issues come into existence due to these changes.
Sanity testing is unscripted, which means we cannot documented it. It checks the correctness of the newly added
features and components.
 UNIT 3 : Software Testing Basics
Regression Testing

Regression testing is the most commonly used type of software testing. Here, the term regression implies that we
have to re-test those parts of an unaffected application.

Regression testing is the most suitable testing for automation tools. As per the project type and accessibility of
resources, regression testing can be similar to Retesting.

Whenever a bug is fixed by the developers and then testing the other features of the applications that might be
simulated because of the bug fixing is known as regression testing.

In other words, we can say that whenever there is a new release for some project, then we can perform Regression
Testing, and due to a new feature may affect the old features in the earlier releases.

User Acceptance Testing

The User acceptance testing (UAT) is done by the individual team known as domain expert/customer or the client.
And knowing the application before accepting the final product is called as user acceptance testing.

In user acceptance testing, we analyze the business scenarios, and real-time scenarios on the distinct environment
called the UAT environment. In this testing, we will test the application before UAI for customer approval..

Exploratory Testing

Whenever the requirement is missing, early iteration is required, and the testing team has experienced testers when
we have a critical application. New test engineer entered into the team then we go for the exploratory testing.

To execute the exploratory testing, we will first go through the application in all possible ways, make a test
document, understand the flow of the application, and then test the application.

Adhoc Testing

Testing the application randomly as soon as the build is in the checked sequence is known as Adhoc testing.

It is also called Monkey testing and Gorilla testing. In Adhoc testing, we will check the application in contradiction of
the client's requirements; that's why it is also known as negative testing.

When the end-user using the application casually, and he/she may detect a bug. Still, the specialized test engineer
uses the software thoroughly, so he/she may not identify a similar detection.

Security Testing

It is an essential part of software testing, used to determine the weakness, risks, or threats in the software
application.

The execution of security testing will help us to avoid the nasty attack from outsiders and ensure our software
applications' security.

In other words, we can say that security testing is mainly used to define that the data will be safe and endure the
software's working process.

Globalization Testing

Another type of software testing is Globalization testing. Globalization testing is used to check the developed
software for multiple languages or not. Here, the words globalization means enlightening the application or
software for various languages.

Globalization testing is used to make sure that the application will support multiple languages and multiple features.

In present scenarios, we can see the enhancement in several technologies as the applications are prepared to be
used globally.
 UNIT 3 : Software Testing Basics
Refer to the following link to get the completed information related to the globalization testing:

Smoke Testing

Smoke Testing comes into the picture at the time of receiving build software from the development team. The
purpose of smoke testing is to determine whether the build software is testable or not. It is done at the time of
"building software." This process is also known as "Day 0".

It is a time-saving process. It reduces testing time because testing is done only when the key features of the
application are not working or if the key bugs are not fixed. The focus of Smoke Testing is on the workflow of the
core and primary functions of the application.

Testing the basic & critical feature of an application before doing one round of deep, rigorous testing (before
checking all possible positive and negative values) is known as smoke testing.

In the smoke testing, we only focus on the positive flow of the application and enter only valid data, not the invalid
data. In smoke testing, we verify every build is testable or not; hence it is also known as Build Verification Testing.

When we perform smoke testing, we can identify the blocker bug at the early stage so that the test engineer won't
sit idle, or they can proceed further and test the independent testable modules.

Note:

o The test engineer knows that the module is independent testable because we have already done one round
of smoke testing on them.

o The development team can take their time to fix the bug, and they are not under pressure because the
testing team is not sitting idle, and the release does not get postponed, hence it is a time-saving process.

Process to conduct Smoke Testing

Smoke testing does not require to design test cases. There's need only to pick the required test cases from already
designed test cases.

As mentioned above, Smoke Testing focuses on the workflow of core applications so; we choose test case suits that
covers the major functionality of the application. The number of test cases should be minimized as much as possible
and time of execution must not be more than half an hour.

When we perform smoke testing

Generally, whenever the new build is installed, we will perform one round of smoke testing because in the latest
build, we may encounter the blocker bug. After all, there might be some change that might have broken a major
feature (fixing the bug of or adding a new feature could have affected a major portion of the original software), or
we do smoke testing where the installation is happening.

When the stable build is installed anywhere (Test Server, Production Server, and User Acceptance testing), we do
smoke testing to find the blocker bug.
 UNIT 3 : Software Testing Basics

Let's use some different scenarios, which help us to understand better when to do smoke testing:

Scenarios 1

The developer develops the application and handed over to the testing team, and the testing team will start the
functional testing

Suppose we assume that four days we are given to the functional testing. On the first day, we check one module,
and on the second day, we will go for another module. And on the fourth day, we find a critical bug when it is given
it to the developer; he/she says it will take another two days to fix it. Then we have to postpone the release date for
these extra two days.

To overcome this problem, we perform smoke testing, let us see how it works, in the above situation, instead of the
testing module by module thoroughly and come up with critical bug at the end, it is better to do smoke
testing before we go for functional, integration and system testing that is, in each module we have to test for
essential or critical features, and then proceed for further testing as we can see in the below images:
 UNIT 3 : Software Testing Basics
Scenario 2

While performing the functional testing, if the test engineer identifies the major bug in the early stages, sometimes it
is not suitable for the developer to find a major bug in the initial stages. So the test engineer will perform the smoke
testing before doing the functional, integration, system, and other types of testing.

While doing smoke testing, the test engineer finds the major bug; he/she will give to the development team for
fixing the bug. After the bug is fixed, the test engineer will continue for further testing as we can see in the below
image:

Scenario 3

In this scenario, if we are already perform the smoke testing and found the blocker bug and also resolved that bug.
After performing the system testing, we will send the application from the testing server to the end-user server for
one round of user acceptance testing. And when the customer performs the acceptance testing and does not find
any issues and satisfied with the application because we already perform the smoke testing.

Scenarios 4

Once the acceptance testing is done, the application will be deployed to the production server. We have done a
round of smoke testing on the production server to check whether the application is installed correctly or not. If any
real end-user will found any blocker bug, they will get irritated and will not use the application again, which may lead
to the loss of customer business as we can see in the below image:
 UNIT 3 : Software Testing Basics

For not getting this problem in the future, the development team manager, the testing team manager, will take the
customer login and do one round of smoke testing.

For example, the real user using the Facebook application and every time we got new features updated internally,
and the actual user will not affect because they will not aware of the internal changes and use the application
properly.

In the production server, smoke testing can be done by the Business analyst (BA), Development team manager,
testing team manager, build team, and the customer.

Why we do smoke testing?

o We will do the smoke testing to ensure that the product is testable.

o We will perform smoke testing in the beginning and detect the bugs in the basic features and send it to the
development team so that the development team will have enough time to fix the bugs.

o We do smoke testing to make sure that the application is installed correctly.

o When we go for smoke testing on every build?

Whenever a new build is installed, we make sure that build is testable or not, and if it is testable, then we perform
smoke testing like as we can see in the below image:

Types of smoke testing

Smoke testing is divided into two types:

Formal smoke testing

In this, the development team sends the application to the Test Lead. Then the test lead will instruct the testing
team to do smoke testing and send the reports after performing the smoke testing. Once the testing team is done
with smoke testing, they will send the smoke testing report to the test lead.
 UNIT 3 : Software Testing Basics
Informal smoke testing

Here, the Test lead says that the application is ready for further testing. The test leads do not specify to do smoke
testing, but still, the testing team starts testing the application by doing smoke testing.

Real Time Example:

Suppose, we are using an eCommerce site, and the core working of this site should be login, specific search, add an
item into the cart, add an item into the favorite, payment options, etc. Here we are testing function to place an
order. After testing, the tester has to be sure and confident about the functioning of the function of the application.

Steps of the workflow are given below:

o Click on item

o Description page should be open.

o Click on Add to Cart

o The cart should be open

o Click on Buy Now

o Payment options should be displayed. Choose one of them.

o Order placed

If this function is working correctly, then tester will pass it in testing and test the next function of the same
application.

Advantages of smoke testing

o It is a time-saving process.

o In the early stage, we can find the bugs.

o It will help to recover the quality of the system, which decreases the risk.

o It is easy testing to perform because it saves our test effort and time.
 UNIT 3 : Software Testing Basics
Sanity Testing

In this section, we are going to understand the working of sanity testing, which is used to check whether the bugs
have been fixed after the build or not.

And we also learn about its process, why we need to perform the sanity testing, the objective of sanity testing,
real-time examples, various attributes of sanity testing, advantages, and disadvantages.

What is Sanity Testing?

Generally, Sanity testing is performed on stable builds and it is also known as a variant of regression testing.

Sanity testing was performed when we are receiving software build (with minor code changes) from the
development team. It is a checkpoint to assess if testing for the build can proceed or not.

In other words, we can say that sanity testing is performed to make sure that all the defects have been solved and
no added issues come into the presence because of these modifications.

Sanity testing also ensures that the modification in the code or functions does not affect the associated modules.
Consequently, it can be applied only on connected modules that can be impacted.

The Objective of Sanity Testing

The key objective of implementing sanity testing is to fulfill the following aspects:

o The primary aim of executing the sanity testing is to define that the planned features work unevenly as
expected. If the sanity test fails, the build is refused to save the costs and time complexity in more severe
testing.

o The execution of sanity testing makes sure that new modifications don't change the software's current
functionalities.

o It also validates the accuracy of the newly added features and components.

Attributes of Sanity Testing

For understanding the fundamental of the sanity testing techniques, we have to learn their attribute and several
other components. Hence, following are some of the important features of Sanity testing:

o Narrow and deep

o A Subset of Regression Testing

o Unscripted

o Not documented

o Performed by testers
 UNIT 3 : Software Testing Basics

Narrow and deep

In software testing, sanity testing is a narrow and deep method where limited components are protected deeply.

Subcategory of Regression Testing

It is a subdivision of regression testing, which mainly emphases on the less important unit of the application.

It is used to test the application efficiency under the requirements of the modification or new features that have
been executed.

Unscripted

Generally, sanity testing is unscripted.

Not documented

Typically, sanity testing cannot be documented.

Performed by test engineers

Usually, Sanity testing is done by the test engineers.

Sanity Testing Process

The main purpose of performing sanity testing is to check the incorrect outcomes or defects which are not existing in
component procedures. And also, ensure that the newly added features may not affect the functionalities of current
features.

Therefore, we need to follow the below steps to implement the sanity testing process gradually:

o Identification

o Evaluation

o Testing
 UNIT 3 : Software Testing Basics
Step1: Identification

The first step in the sanity testing process is Identification, where we detect the newly added components and
features as well as the modification presented in the code while fixing the bug.

Step2: Evaluation

After completing the identification step, we will analyze newly implemented components, attributes and modify
them to check their intended and appropriate working as per the given requirements.

Step3: Testing

Once the identification and evaluation step are successfully processed, we will move to the next step, which
is testing.

In this step, we inspect and assess all the linked parameters, components, and essentials of the above analyzed
attributed and modified them to make sure that they are working fine.

If all the above steps are working fine, the build can be subjected to more detailed and exhausting testing, and the
release can be passed for thorough testing.

Who executes the Sanity testing?

Generally, a sanity test case is executed by the test engineers.

When do we need to perform Sanity testing?

There are no such hard and fast software testing rules to execute the sanity tests process.

It is a quick process of testing the application as it does not include the scripting any of the test cases.

A Sanity testing is a narrow regression test that emphasizes specific areas of the component. And if we encounter
the below two conditions, we needed to execute one round of sanity testing, and those conditions are as follows:

Case1

We go for sanity testing whenever there is an improvement in the functionality of the specified software.

Case2

Whenever the bugs have been fixed, or a new feature added, we need to perform sanity testing in order to check
whether the application is still working fine or not.

Examples of Sanity Testing

For our better understanding of sanity testing, we will see the below example:

Example 1

Suppose we have an e-commerce application, which contains several modules, but here, we mainly concentrate
only a few modules such as the login page, the home page, the new user creation page, the user profile page, etc.

o While a new user tries to login into the application, he/she is not able to log in, as there is a bug in the login
page.

o Because the password field in the login module accepts less than four alpha-numeric characters and based
on the specification, the password field should not be accepted below 7-8 characters.

o Thus, it is considered as bug, which is reported by the testing team to the development team to fix it.

o Once the development team fixes the specified bug and reports back to the testing team, the testing team
tests the same feature to verify that the modification that happens in the code is working fine or not.
 UNIT 3 : Software Testing Basics
o And the testing team also verifies that the particular modification does not impact other related
functionalities.

o To modify the password on the user profile page there is a process.

o As part of the sanity testing process, we must authenticate the login page and the profile page to confirm
that the changes are working fine at both the places.

Advantages and Disadvantages of Sanity Testing

Below are some of the vital benefits and drawbacks of Sanity testing.

Advantages of Sanity Testing

Some of the dynamic benefits of performing sanity testing are as follows:

Sanity testing is easy to understand and implement.

o It helps us to find any deployment or compilation issues.

o It is less expensive as compared to other types of software testing.

o It helps in rapidly finding the bugs in the core functionality.

o There is no documentation mandatory for sanity testing, that's why it can be executed in lesser time.

o The execution of sanity testing will help us save unnecessary testing effort and time because it only focused
on one or a few functionality areas.

o Sanity testing helps in detecting the missing dependent objects.

Disadvantages of Sanity testing

Following are the drawbacks of sanity testing:

o It's become a very complex process for the developers to understand how to fix the defects acknowledged
throughout the sanity testing if they do not follow the design structure level.

o All the test cases are not covered under sanity testing.

o It is emphasized only on the statement and functions of the application.

o We do not have future references since the sanity testing is unscripted.

o It became a complex process to find any other components as sanity testing is executed only for some
limited features.

Overview

In this tutorial, we learned that the execution of the sanity testing, real-time examples, benefits, and drawbacks.

Sanity testing is implemented when a new functionality, modification request, or bug fix is executed in the program.

It is a narrow and deep testing process that is intensive only on those components where the modification has
impacted.

Sanity testing is beneficial as it provides various advantages like, it offers a quick assessment of the quality of
software release.

Sanity testing allows us to check the application's small functionality if a minor change occurs in the software.

Static Testing
 UNIT 3 : Software Testing Basics
In this section, we are going to understand Static testing, which is used to check the application without executing
the code. And we also learn about static Testing, why we use static Testing, how to perform it, a different
technique for static Testing, advantages of static testing, and various Static Testing tools.

Introduction to Static Testing

Static testing is a verification process used to test the application without implementing the code of the application.
And it is a cost-effective process.

To avoid the errors, we will execute Static testing in the initial stage of development because it is easier to identify
the sources of errors, and it can fix easily.

In other words, we can say that Static testing can be done manually or with the help of tools to improve the quality
of the application by finding the error at the early stage of development; that is also called the verification process.

We can do some of the following important activities while performing static testing:

o Business requirement review

o Design review

o Code walkthroughs

o The test documentation review

Why do we need to perform Static Testing?

We can perform static testing to fulfill the below aspects:

o We can use static testing to improve the development productivity.

o If we performed static testing on an application, we could find the detects in the earlier stages and easily fix
them.

o The usage of static testing will decrease the testing cost, development timescales, and time.

What are the different features we can test in Static Testing?

We can test the various testing activities in Static Testing, which are as follows:

o BRD [Business Requirements Document]

o Functional or system Requirements

o Unit Use Cases

o Prototype

o Prototype Specification Document

o Test Data

o DB Fields Dictionary Spreadsheet

o Documentation/Training Guides/ User Manual

o Test Cases/Test Plan Strategy Document

o Traceability Matrix Document

o Performance Test Scripts/Automation

When we performed Static Testing?

 UNIT 3 : Software Testing Basics
To perform static testing, we need to follow the below steps:

Step1: To review the design of the application entirely, we will perform the inspection process.

Step2: After that, we will use a checklist for each document under review to make sure that all reviews are covered
completely.

We can also implement several activities while performing static testing, which are discussed in the following table:

Activities Explanation

Architecture Review o The architecture review activities contain all business-level processes such
as network diagram, load balancing, server locations, protocol definitions,
test equipment, database accessibility, etc.

Use Cases Requirements o It is used to authenticates all the end-user actions along with associated
Validation input and output.

o If the use case is more comprehensive and detailed, we can make more
precise and inclusive test cases.

Functional o The functional requirement validation activity is used to make sure that all
Requirements necessary elements identify correctly.
Validation
o And it also took care of the software, interface listings, network
requirements, hardware, and database functionality.

Field Dictionary o In the field dictionary validation, we will test each field in the user interface
Validation specified to create field-level validation test cases.

o And we can check the fields for error messages, minimum or maximum
length, list values, etc.

Prototype/Screen o The prototype validation activity contains the authentication of requirements

Mockup Validation and uses cases.

Why we need Static Testing?

We required Static testing whenever we encounter the following situation while testing an application or the
software:

o Dynamic Testing is time-consuming

o Flaws at earlier stages/identification of Bugs

o Dynamic Testing is expensive

o Increased size of the software

Dynamic Testing is time-consuming

We need static testing to test the application as dynamic testing is time-taking process even though the dynamic
testing identifies the bug and provides some information about the bug.
 UNIT 3 : Software Testing Basics
Flaws at earlier stages/identification of Bugs

When we are developing the software, we cannot completely rely on Dynamic testing as it finds the bugs or defects
of the application/software at a later stage because it will take the programmer's plenty of time and effort to fix the
bugs.

Dynamic Testing is expensive

We need to perform the static testing on the software product because dynamic testing is more expensive than
static testing. Involving the test cases is expensive in dynamic testing as the test cases have been created in the
initial stages.

And we also need to preserve the implementation and validation of the test case, which takes lots of time from the
test engineers.

Increased size of the software

Whenever we test the software, it will increase the size of the software product, which we cannot handle because of
the reduction in the productivity of code coverage.

That is why we require static testing to get free from the bugs or defects earlier in the software development life
cycle.

Objectives of Static testing

The main objectives of performing static testing is as below:

o Static testing will decrease the flaws in production.

o Static testing will identify, anticipate and fix the bugs at the earliest possible time.

o It is used to save both time and cost.

o It is used to identify defects in the early stage of SDLC, where we can fix them easily.

Some useful points for Successful Static Testing Process

The following guidelines help us to perform a successful static testing process in Software testing.

o We can train participants with examples.

o The testing cost and time can decrease if we delete the major delays in test execution.

o We can retain the process formal as per the project culture.

o We can make emphasis only on things that matter.

o As we know that a software walkthrough and review are usually merged into peer reviews; therefore, we
can plan explicitly and track the review activities.

o We can resolve the client's problems.

Static Testing Techniques

Static testing techniques offer a great way to enhance the quality and efficiency of software development. The Static
testing technique can be done in two ways, which are as follows:

o Review

o Static Analysis
 UNIT 3 : Software Testing Basics

Review

In static testing, the review is a technique or a process implemented to find the possible bugs in the application. We
can easily identify and eliminate faults and defects in the various supporting documents such as SRS [Software
Requirements Specifications] in the review process.

In other words, we can say that a review in Static Testing is that where all the team members will understand about
the project's progress.

In static testing, reviews can be divided into four different parts, which are as follows:

o Informal reviews

o Walkthroughs

o Technical/peer review

o Inspections

Let's understand them in detail one by one:

o Informal reviews
In informal review, the document designer place the contents in front of viewers, and everyone gives their
view; therefore, bugs are acknowledged in the early stage.

o Walkthrough
Generally, the walkthrough review is used to performed by a skilled person or expert to verify the bugs.
Therefore, there might not be problem in the development or testing phase.

o Peer review
In Peer review, we can check one another's documents to find and resolve the bugs, which is generally done
in a team.
 UNIT 3 : Software Testing Basics
o Inspection
In review, the inspection is essentially verifying the document by the higher authority, for example,
the verification of SRS [software requirement specifications] document.

Static Analysis

Another Static Testing technique is static analysis, which is used to contain the assessment of the code quality,
which is established by developers.

We can use the different tools to perform the code's analysis and evaluation of the same.

In other words, we can say that developers' developed code is analyzed with some tools for structural bugs, which
might cause the defects.

The static analysis will also help us to identify the below errors:

o Dead code

o Unused variables

o Endless loops

o Incorrect syntax

o Variable with undefined value

In static testing, Static Analysis can be further classified into three parts, which are as discuss below:

Data Flow: In static analysis, the data flow is connected to the stream processing.

Control Flow: Generally, the control flow is used to specify how the commands or instructions are implemented.

Cyclomatic Complexity: It is the measurement of the program's complexity, which is mostly linked to the number of
independent paths in the control flow graph of the program.

Tools used for Static Testing

In static testing, we have several tools in the market, but here we are discussing the most commonly used tools,
which are as follow:

o CheckStyle

o SourceMeter

o Soot
 UNIT 3 : Software Testing Basics
CheckStyle

It is a development tool that is used to help the developers write Java code, which follows a coding standard.
The CheckStyle tool automates the process of checking Java code.

It is a highly configured tool, which is made to support almost any coding standard. The Google Java Style, Sun code
conventions are those configuration files, which is supported by CheckStyle.

Feature of CheckStyle

Following are the most common features of CheckStyle:

o It can check various characteristics of our source code.

o The CheckStyle code has the capability to verify the code layout and formatting issues.

o It can also help to identify the method design problems, class design problems.

SourceMeter

It is an advanced tool for the specific static source code analysis of various programming languages such
as C/C++, C#, Java, Python, and RPG projects.

With the SourceMeter tool's help, we can easily identify the vulnerable spots of a system under development from
the source code.

The free version with partial functionality of SourceMeter can be accessible for all programming languages.

In SourceMeter, we can use the output of the analysis, the quality of the analyzed source code to enhance and
developed both the short and long term in a directed way.

Feature of SourceMeter

The most commonly used features of the SourceMeter tool are as follows:

o It provides the most precise coding error detection.

o The SourceMeter tool will provide a deep static code analysis.

o It improved the user interface with the help of third-party integration.

o It will provide platform-independent command-line tools.

Soot

It is a Java optimization framework, which means that it is a framework for analyzing and transforming Java and
Android applications where we can test the following aspects:

o Named module and modular jar files.

o Automatic modules, which means the modules are repeatedly created from jars in the module-path.

o Exploded modules
 UNIT 3 : Software Testing Basics
o Resolving modules in Soot's

And a Soot can also produce possibly transformed code in the various output formats such as Android bytecode,
Java bytecode Jasmin, and Jimple.

Advantages of Static Testing

The advantages of static testing are as follows:

o Improved Product quality

Static testing will enhance the product quality because it identifies the flaws or bugs in the initial stage of
software development.

o Improved the efficiency of Dynamic testing

The usage of Static testing will improve Dynamic Testing efficiency because the code gets cleaner and better
after executing Static Testing.
As we understood above, static Testing needs some efforts and time to generate and keep good quality test
cases.

o Reduced SDLC cost

The Static Testing reduced the SDLC cost because it identifies the bugs in the earlier stages of the software
development life cycle. So, it needs less hard work and time to change the product and fix them.

o Immediate evaluation & feedback

The static testing provides us immediate evaluation and feedback of the software during each phase while
developing the software product.

o Exact location of bug is traced

When we perform the static testing, we can easily identify the bugs' exact location compared to the dynamic
Testing.

Overview

In the Static testing section, we have learned the following topics:

o Static testing is used to identify the faults in the early stage of the Software development cycle [SDLC].

o We have understood that Static Testing is not a replacement for dynamic Testing because both testings
identify different bug types.

o We have understood the objective of Static Testing.

o In static testing, the reviews are the productive approach to test the application because the reviews help
identify the bugs and recognize the design flaws, missing requirements, and non-maintainable code, etc.

o We have understood several static testing tools, which help us enhance testing performance for the
software product.
 UNIT 3 : Software Testing Basics
Dynamic Testing

In this section, we are going to understand Dynamic testing, which is done when the code is executed in the run
time environment.

And we also learn about Dynamic testing, why we use it, how to perform it, what are a different technique for
Dynamic testing, various tools for Dynamic Testing.

Introduction to Dynamic Testing

Dynamic testing is one of the most important parts of Software testing, which is used to analyse the code's dynamic
behavior.

The dynamic testing is working with the software by giving input values and verifying if the output is expected by
implementing a specific test case that can be done manually or with an automation process.

The dynamic testing can be done when the code is executed in the run time environment. It is a validation
process where functional testing [unit, integration, system, and user acceptance testing] and non-functional testing
[Performance, usability, compatibility, recovery and security testing] are performed.

As we know that Static testing is a verification process, whereas dynamic testing is a validation process, and
together they help us to deliver a cost-effective quality Software product.

Why do we need to perform Dynamic Testing?

We can easily understand how to implement dynamic testing during the STLC [Software Testing Life Cycle] if we
consider the characteristics accessible by dynamic testing.

Using dynamic testing, the team can verify the software's critical features, but some of those can be left without any
assessment. And they can also affect the functioning, reliability, and performance of the software product.

Hence, we can perform Dynamic testing to fulfill the various below aspects:

o We will perform dynamic testing to check whether the application or software is working fine during and
after installing the application without any error.

o We can perform dynamic testing to verify the efficient behavior of the software.

o The software should be compiled and run if we want to perform dynamic testing.

o Generally, Dynamic Testing is implemented to define the dynamic behavior of code.

o The team implements the code to test the software application's performance in a run-time environment
during the dynamic testing process.

o It makes sure that the concurrency of the software application with the customer's potentials, needs and the
end-user.

o It is an operative technique to measure the effect of several environmental stresses on the software
application like network, hardware

Characteristic of Dynamic Testing

For understanding the fundamental of the software testing techniques, we have to learn their attribute and several
other components. Hence, following are some of the important characteristics of dynamic testing:

o It is implemented throughout the validation stage of software testing.

o Dynamic Testing is done by performing the program.

o Both functional and non-functional testing include in dynamic testing.

 UNIT 3 : Software Testing Basics
o In Dynamic testing, we can easily identify the bugs for the particular software.

o It helps the team in validating the reliability of the software application.

o Unlike static testing, the team implements the software's code to get expected outputs in dynamic testing.

o Dynamic testing is performed directly on the software application as compare to other testing techniques.

o Dynamic testing is a more formal testing approach for different testing activities such as test execution,
coverage consideration, reporting and test case identification.

Dynamic testing Process

Generally, dynamic testing follows a set process when the approach and test implementation performances are
decided, and the team can move to execute the different testing activities.

With the help of this process, the team can find any irregularity from the approaches and strategies and help us
display all the testing steps.

In the STLC, the process of Dynamic Testing involves different functions. And all the functions in the dynamic testing
process rely on the conclusion of the earlier task in the testing process.

The Dynamic testing process will complete in the following steps:

o Test case design

o Test environment step-up

o Test case execution

o Test analysis and evaluation

o Bug Reporting

The actual Dynamic Testing Process begins from Test Case Design in the software testing life cycle. Now, we discuss
each step one by one to get complete knowledge of the dynamic testing process.

Step1: Test Case Design

In the first step of the dynamic testing process, the teams will design the test cases. Here, we are creating those test
cases that depend on the requirements and scope of testing established before the start of the project.

In this step, we can originate the test conditions, obtain the test cases, extract the coverage Items, and identify
those features that need to be tested.

Step2: Environment Setup

In the test environment phase, we will make sure that the testing environment should always be parallel to the
production environment because the testing is implemented directly on the software product.

In this step, the dynamic testing process's main objective is to install the test environment, which helps us succeed in
the test machines.
 UNIT 3 : Software Testing Basics
Step3: Test Execution

Once we successfully install the test environment, we will execute those test cases prepared in the primary stage of
the dynamic testing process.

Step4: Analysis & Evaluation

After executing the test cases, we will analyse and evaluate the outcomes derived from the testing. And we will
compare those outcomes with the expected results.

If expected and actual results are not the same according to executing, we will consider those test cases as fail, and
log the Bug in the bug repository.

Step5: Bug Reporting

After analyzing the test cases, we will be reported and recorded any bugs or defects between the actual result and
expected result to the concerned person. And the concerned person will make sure that the issue has been solved
and delivering a quality product.

Example of Dynamic Testing

Let us take one sample example where we understand how dynamic testing will woks.

So, for this, we will understand the login module of any application, such as www. Twitter.com.

Suppose we want to create one new account with a secure password, so we need to follow some pre-defined rules
in the password field.

And the password should have eight characters long, capital letters and at least one special character.

If we are testing this functionality, we would take all the input conditions to test this and then verify the output.

We can also put the non-working constraints, such as input a 4-character password, and validate if there is an error
occurred or not.

Types of Dynamic testing

Dynamic testing divided into two different testing approach, which are as follows:

o White-box testing

o Black-box testing

Both the testing techniques will help us execute the dynamic testing process efficiently as they play an important
role in verify the performance and quality of the software.

Let's understand them one by one in detail and also see the below diagram of it:
 UNIT 3 : Software Testing Basics

White-box testing

The word white box is used to describe the core perspective of the system. The developers will perform the white
box testing, where they will test every line of the program's code.

When the developers perform the White-box testing and then send the software application to the testing team, the
testing team will do the black box testing, validate the application as well as the requirements. The white-box testing
is further divided into data flow/control testing.

Data flow Testing

The data flow testing is used to identify the program's test paths as per the settings of descriptions and uses of
variables in the program. And it does not relate to data flow diagrams.

Black-box testing

The black-box testing is a testing technique where the test engineer selects a module and gives an input value to
observe its functionality and analysis of whether the function is giving the expected output or not. If the function
produced the correct output, then the particular function will be marked as pass.

To perform black-box testing, the test engineer should have specific knowledge about the software's requirement
rather than programming knowledge of the software.

And then, they can develop the test cases to check the correctness of the software's functionality.

Black-box testing is further classified into two types, which are as follows:

o Functional testing

o Non-function testing

Functional testing

Functional testing is one of the most important parts of black-box testing. It mainly focuses on application
specification rather than the actual code, and the test engineer will test the program rather than the system.
 UNIT 3 : Software Testing Basics
The functional testing is used to validate the software application's functionality, whether the function is working as
per the requirement specification.

In functional testing, each module has been tested by giving the value, determining the output, and verifying the
actual output with the expected value.

The functional testing is classified into four different type of testing, which are as follows:

o Unit testing

o Integration testing

o System testing

o User acceptance testing

Unit testing

o The unit testing is the first level of functional testing to perform any testing on the software application.

o We will perform the unit testing whenever the application is ready and given to the Test engineer. He/she
will start checking every component of the module or application independently or one by one. And this
process is known as components testing.

o The primary objective to perform unit testing is to test the correctness of remote code and validate the unit
components with their performance.

Integration testing

o When we have successfully done the unit testing on the specific software, we will go for the integration
testing. The integration testing will help us to combined individual units and tested as a group. And it is the
second levelof functional testing.

o When all the components or modules are working independently, we will check the data flow between the
dependent modules, which is known as integration testing.

o The developers and the test engineer perform the integration testing. And the main purpose of the
integration is to identify the faults in the interaction between the integrated units.

System testing

o System testing is used to check the end-to-end flow of an application or the software as a user.

o System testing is also known as end-to-end testing as the testing environment is similar to the production
environment.

o In the third level (system testing) of functional testing, we go through all the necessary modules of an
application and check if the end features or the end business works fine, and test the product as a whole
system.

User acceptance testing

o The user acceptance testing is performed to certify the system according to requirements. The customer or
client does it before accepting the final product.

o In other words, we can say that the UAT is done by the customer (domain expert) for their satisfaction and
check whether the application is working according to given business scenarios and real-time scenarios.

o It is the last level of functional testing, which is execute before releasing the software to the market or
production environment where two or more end-users will involve.
 UNIT 3 : Software Testing Basics
Non- Functional testing

Another part of black-box testing is non-functional testing. It is used to test non-functional constraints like load test,
reliability, performance, and software accountability.

The main objective of performing the non-functional testing is to test the software system's reading speed according
to the non-functional parameters because these parameters are never tested before the functional testing.

Non-functional testing plays a vital role in customer satisfaction while testing the software or the application.

It reduces the risk of production and related costs of the software, and it provides a thorough knowledge of product
behavior and used technologies.

Furthermore, the non-functional testing is divided into various parts, which can be performed at the test level.

o Performance testing

o Usability testing

o Compatibility testing

o Recovery testing

o Security testing

Let's understand them in details one by one:

Performance Testing

o The performance testing is the most importantly used type of non-functional

o Once the software is stable and moved to the production, and it may be accessed by multiple users
concurrently, we will do performance testing.

o The performance testing is testing where we check the behavior of an application by applying some load.

o As we know it is non-functional testing, which doesn't mean that we always use performance testing when
the application is functionally stable; only then we go for performance testing.

Usability Testing

o In usability testing, we will check the user-friendliness, efficiency, and accuracy of the software application.

o If we are using usability testing, it ensures that the developed software is easy to test while using the system
without facing any problem and makes end-user life easier.

Compatibility testing

o The next type of non-functional testing is compatibility testing, which is used to check the functionality of
an application on different software, hardware platforms, network, and browsers.

o The compatibility testing is not performed for all the applications; we will use the compatibility testing only
for those applications where we don't have control over the platform used by users.

Recovery testing

o In recovery testing, we can verify how well a system can recover from hardware failures and crashes.

o It reproduced the failure modes or essential producing failures in a controlled environment.

o The recovery testing is performed to confirm that a system is fault-tolerant and can improve well from
failures.
 UNIT 3 : Software Testing Basics
Security testing

o The security testing is used to discover the weaknesses, risks, or threats in the software application and help
us stop the nasty attack from outsiders and ensure our software applications' security.

o The main purpose of security testing is to identify all the possible uncertainties and vulnerabilities of the
application so that the software does not stop working.

Advantages and disadvantages of Dynamic Testing

From detecting and evaluating several bugs and errors in the software to verifying the software's performance,
dynamic testing provides serval benefits to the users and the testing team.

However, we have various advantages of dynamic testing as well as some disadvantages.

Therefore, below we listed some of the advantages and disadvantages of dynamic testing:

Advantages

Following are the advantages of dynamic testing:

o It validates the performance of the software application.

o The usage of dynamic testing ensures the reliability and constancy of the software product.

o It can automate with the help of tools that detect the problematic and complex bugs in the testing process,
which cannot be covered through static Analysis.

o It helps the testing team to identify the weak areas of the run-time environment.

o The most important benefit of using dynamic testing over static testing is the relatively higher number of
bugs can be found.

o As compared to static testing, dynamic testing requires a smaller number of meetings at the planning level
of testing.

o It implements the software, end to end, and delivers Bug-free software.

o It becomes an essential tool for identifying any security threats.

o In dynamic testing, we can detect the problematic bugs which may have escaped the review processes.

o It also identifying those bugs which cannot be noticed by static testing.

o Dynamic testing can also find security threats, which ensure a better and secure application.

Disadvantages

Following are drawbacks of dynamic testing:

o It is a time-consumingprocess as it implements the software application or code, which needs a massive

resource.

o The dynamic testing process is a bit costlieras it increases the budget of the software.

o The dynamic testing needs more human resources to complete the task, which makes its implementation
costlier.

o Generally, dynamic testing is executed after the coding phase is completed, and therefore, the bugs are
identified later in the life cycle.
 UNIT 3 : Software Testing Basics
Overview

In the dynamic testing section, we have learned the following topics:

o After understood the dynamic testing above, we can easily say that the importance of dynamic testing is
massive in the software testing life cycle (STLC).

o Dynamic testing is used to perform the dynamic behavior of the code.

o We have understood the process of dynamic Testing and the various types of dynamic testing.

o In dynamic testing, we can directly implement the software tests to verify the functional performance,
behavior, reliability, and other significant features of the software.

o We have understood the advantages and disadvantages of dynamic testing.

Load Testing

In this section, we are going to understand load testing, which is the important part of Performance testing and
used to check the performance of the software by applying some load.

And we also learn about its process, why we need to perform the load testing, the objective of load testing, example,
various strategies of load Testing, advantage and disadvantage.

Introduction of Load Testing

In software testing, load testing is an integral part of performance testing under non-functional testing.

Load testing is testing where we check an application's performance by applying some load, which is either less than
or equal to the desired load.

Here, load means that when N-number of users using the application simultaneously or sending the request to the
server at a time.

Load testing will help to detect the maximum operating capacity of an application and any blockages or bottlenecks.

It governs how the software application performs while being accessed by several users at the same time.

The load testing is mainly used to test the Client/Server's performance and applications that are web-based.

In other words, we can say the load testing is used to find whether the organization used for compering the
application is necessary or not, and the performance of the application is maintained when it is at the maximum of
its user load.

Generally, load testing is used to signify how many concurrent users handle the application and the application's
scale in terms of hardware, network capacity etc.

The Objective of Load Testing

The main objective of using the load testing is to fulfill the following aspects:

o The load testing is used to perform the maximum quantity of software applications without important
performance breakdown.

o It is used to govern the scalability of the application and allows various users to access it.

o It is used to identify the total count of users that can access the application simultaneously.

o The load testing is used to determine whether the latest infrastructure can run the software application or
not and determine the sustainability of the application concerning extreme user load.
 UNIT 3 : Software Testing Basics
Why is load testing important?

The load testing is essential because of the following factor:

o It guarantees the system and its consistency and performance.

o The load testing is necessary if any code changes occur in the application that may affect the application's
performance.

o It is important because it reproduces the real user scenarios.

o It helps find the system's bottlenecks.

Rules for load testing

During the execution of the load testing, a test engineer should follow the below rules:

o A test engineer tries to evade downloading images on the site.

o Once the application becomes functionally stable, load testing should be planned.

o The reliability of response time concludes the past period should be logged and the same should be
compared with several test runs.

o For each scenario or script number of users should be decided.

Load Testing Process

The Load testing process will be completed in the following steps:

Step1: Test environment setup

o In the first step, we will set up the test environment to execute the load testing to ensure the testing can be
done appropriately.

o And the test environment should be set up near to the production environment as likely in terms
of network, hardware, software specifications etc.

Step2: Load the test scenario or specify the performance criteria

o In the next step, we will define the performance criteria, which contain the response time, reasonable limits
on throughput, and the load test transaction.

o And then, we create the load test scenarios, which ensure the success criteria are finalized.

o In the load testing, transactions are decided for an application

and data is set for each transaction.

Note: A test scenario is a combination of scripts, and virtual users executed during a testing session. The Scenarios
could be of two types, either manual or goal oriented.

For example, In the LoadRunner testing tool, the scenarios are created with the LoadRunner controller's help.

Step3: Execution of test scenarios

o Once we successfully create the load test scenarios, we will execute the particular test scenarios.
 UNIT 3 : Software Testing Basics
o But before we execute the load test scenarios, we have to set the different configurations and matrices to
collect the information.

o The load on the server is matched by consecutively several virtual users to complete the tasks concurrently.

o And we can execute the entire scenario in virtual user groups or individual virtual users.

Step4: Analysis of the test result

o After executing the load test scenarios, we will analyze the test results.

o The load test Scenario can be inspected with the help of LoadRunner online monitors like:

o System resource

o Run-time transaction

o Network delay

o Web resource

Step5: Re-test

o The last step of the load testing process depends on the test result because if the test fails, we have to
perform the same process repeatedly until the test result is passed and all the issues and bottlenecks are
fixed.

Examples of Load Testing

Let see some real-time example where we can see the massive failure of the particular application as they did not
perform the load testing:

Example1

E-commerce websites capitalize deeply in advertising campaigns but not in Load Testing to guarantee ideal system
performance, and they get massive users at the same time. Because of that, some very popular sites have suffered a
serious failure

Example2

Amazon lost $66,000-$66,240 per minute because the amazon.com server crashed heavily by users' traffic for 30
minutes in 2013.

And during a festival offer, an Airline website cannot handle 10000+ users at the same time.

Example3

More people have a habit of booking a flight ticket throughout holidays or on the days when an air company has an
offer.

As we can see, more people incline to buy products during a promotional event like Diwali, Black Friday, big billion
days sales.

And if a website or an application crashes in such an event, users may leave the website and go to a competitor's
application, leading to loss of revenue and market share. Those scenarios may occur because we do not perform the
load testing on the system.

Note: Based on a survey if a site is crashed or slow, 70-75% of the users would leave the website. If the website or an
application did not load in 3 seconds, 40-50% of the users said they would buy elsewhere.

Difference between Load and Stress testing

The major difference between load and stress testing is listed in the following table:
 UNIT 3 : Software Testing Basics

Load Testing Stress Testing

Using load testing, the test engineer can detect the By using Stress testing, the test engineer can check the
bottleneck and tell the cause of bottlenecks before system capacity when the number of users suddenly
deployment to the production server. increases before the system failure or crashes.

Types of Load Testing tools

We have the various type of load testing tools to execute the load testing, which is as follows:

Load Testing Tools [Open-Source]

o To perform the load testing, we can use the open-source load testing tools as we have various load testing
tools available in the market for free of cost.

o If we have a limited budget for the particular project, we can use open-source tools. But not every time, as
they may not be as advanced as the paid load testing tool.

o JMeter is the most frequently used open-source load testing tool.

Manual Load Testing

o One of the most effective load testing approaches is the manual process to perform the load testing. Still, we
cannot rely on it as it does not produce repeatable outputs and assessable stress levels on an application.

o And if we perform the load testing manually, it requires a lot of workforces, which is quite expensive
compared to paid tools.

Load Testing Tools [Enterprise-class]

o The paid load testing tools are used to support many protocols; therefore, it can implement various types of
applications like Streaming Media, ERP/CRM, etc.

o LoadRunner is the most popular licensed load testing tool.

 UNIT 3 : Software Testing Basics
In house Developed Load Testing Tools

o The particular organization uses the in-house developed load testing tools approaches to build their tools to
perform the load tests on their application for understanding the importance of load testing

Load testing tools

We have various types of load testing tools available in the market, where some are commercial tools and open-
source tools. Let see some of the most common load testing are as follows:

o LoadNinja

o Apache JMeter

o NeoLoad

o HP Performance Tester

o WebLoad

o LoadView

Advantages and disadvantages of load testing

Advantages

Some of the vital benefits of performing the load testing are as follows:

o Load testing helps us to detect the bottlenecks and performance-related issues before production.

o The load testing enhances the scalability regarding network, software and database for the system or
software application.

o The major advantage of performing the load testing is reducing the cost failures, which also helps us
minimize the system interruption risks.

o Customer's satisfaction is enhanced while using the load testing.

Disadvantages

Following are the drawbacks of load testing:

o Load testing can only be executed if we have enough knowledge of any programming language as well as
testing tools.

o Usage of load testing tools can be an expensive process because pricing depends on the number of virtual
users supported.

Overview

In the load testing tutorial, we have understood the following aspects of load testing:

o While executing an application's performance testing, the load plays a vital role and helps to learn the
software's effectiveness and ability or an application.

o If we ignored the load testing, it might cause financial losses.

o It is specifying as a type of software testingwhich controls a system's performance under real-life load
conditions.

o It expands the scalability, performance issues, and constancy of the application before production is
available.
 UNIT 3 : Software Testing Basics
Stress Testing

In this section, we are going to understand Stress Testing, which is an important part of Performance testing and
used to checks the behavior of an application by applying a load greater than the desired load.

And we also learn about its process, why we need to perform the Stress testing, the objective of Stress testing,
examples, various features of stress Testing, advantage and disadvantage.

Introduction of Stress Testing

In software testing, stress testing is an important part of performance testing under non-functional testing.

Stress Testing is testing used to check the accessibility and robustness of software beyond usual functional limits. It
mainly considers for critical software but it can also be used for all types of software applications.

It is also known as Endurance Testing, fatigue testing or Torture Testing.

The stress testing includes the testing beyond standard operational size, repeatedly to a breaking point, to get the
outputs.

It highlights the error handling and robustness under a heavy load instead of correct behavior under regular
conditions.

In other words, we can say that Stress testing is used to verify the constancy and

dependability of the system and also make sure that the system would not crash under disaster circumstances.

To analyses how the system works under extreme conditions, we perform stress testing outside the normal load.

The Objective of Stress Testing

The main objective of using stress testing is to fulfill the following aspects:

o The primary purpose of executing the stress testing is to confirm that the software does not crash in lacking
computational resources like disk space, memory, and network request.

o The implementation of stress testing certifies that the system fails and improves effortlessly, known as the
recoverability process.

o We can use stress testing to discover hardware issues, data corruption issues.

o Stress testing will help us to identify the security weaknesses that might sneak-in throughout constant peak
load.

o It helps determine the software application's data integrity throughout the extreme load, which implies that
the data should be in a dependable state after a failure.

Features of Stress Testing

Following are the basic features of stress testing:

o Stress testing also makes sure that unpredicted failures do not cause security issues.

o It is used to analyze the system works under rare circumstances and the system's behavior after a failure.

o Stress testing is used to check the system has saved the data before crashing or not.

o Stress testing guarantees to display a suitable error message when the system is under stress.

Why do we need to perform the Stress Testing?

We need to perform stress testing if we encounter the following situations:

 UNIT 3 : Software Testing Basics
Whenever e-commerce or online shopping sites announce a sale during the festival may witness a spike in traffic. Or
when an article is mention in a top newspaper, its knowledges an unexpected flow in traffic.

If we fail to assist this sudden traffic can result in loss of profits and status. So, in that case, we need to execute
the Stress Testing to integrate such irregular traffic spikes.

Stress testing is also needed to be performed for the below scenarios:

o When the system is under stress, it should display a proper error message.

o To inspect whether the system works under bizarre circumstances.

o If the system is failed under risky situations could result in huge profits loss.

o By implementing Stress Testing, we will be prepared for extreme conditions.

Example of Stress Testing

Let's see some real-time examples where we can discover the usage of Stress Testing.

Example 1: E-commerce website/ application

Throughout the new product releases, sales, holidays, promotions, and festival offers, the e-commerce application
tends to get many users in a very short time.

Example 2: News website at the time of some major/viral event

The news website will crash or slow down when a major event happens; for example, when Michael Jackson passed
away, a maximum number of news websites are slow down, or some of them also crashed.

To overcome this situation, we need to perform stress testing on the particular application and be prepared to
recover quickly in case of any crashes or failure.

Example 3: Education Board's result website

Stress testing is important to perform on the education board's result website. On the day of some results, many
students, users, and applicants will logins to the particular to check their grades.

Therefore, the execution of stress testing helps identify the failure of the application and evaluate the performance
and recoverability when the ultimate load occurs in a short duration or when the result is out.

Note: Stress testing of the website or an application is very significant to handle such an unexpected increase in
several visitors or users.

Types of Stress Testing

Stress testing can be categories into various parts, which are as follows:
 UNIT 3 : Software Testing Basics
o Product or Application stress testing

o Server-client or distribute Stress Testing

o Analytical Stress Testing

o Systematic Stress Testing

o Transactional Stress Testing

Product or Application Stress Testing

o The application or product stress testing is mainly focused on determining the faults related to network
issues, data locking, blocking, and a performance bottleneck in a software product.

Server-client or Distribute Stress Testing

o In this type of stress testing, all the clients related to the server are tested.

o The distribute stress testing is used to perform across all clients from the server.

o The server can communicate with clients A and B, but it cannot link with clients C and D when there is stress
on the client-server system as we can see in the below image:

Analytical/ Exploratory Stress Testing

o Analytical or exploratory testing is used to execute the system with unusual constraints unlikely to occur in a
real scenario.

o It is mainly used to identify the bugs in rare situations such as a large number of users logged
simultaneously or a database went offline when retrieved from a website.

Let see some examples of analytical Stress Testing where such irregular conditions are used:

o When a large number of parallel users try to log into the application.

o Data is added in enormously large quantity in the database.

o When the website tries to reach it from the front end, and database linked to the website shuts down.

Systematic Stress Testing

o It is combined testing used to execute the test across various systems running on a similar server.

o Using systematic stress testing, we can easily detect the bottleneck where data of one application blocks
another application.
 UNIT 3 : Software Testing Basics
Transactional Stress Testing

o Another type of stress testing is transactional stress testing, which is used to implemented one or more
transactions between various applications.

o The main objective of performing the transactional stress testing is to enhance the system performance.

Process of Stress testing / how to perform stress testing

The stress testing process will be completed into the following steps:

Step1: Detect the testing environment

In the first step of stress testing, we will identify the network, software, and hardware configurations and tools
available to achieve the stress test.

Step2: Find performance acceptance criteria

After identifying the testing environment, we will find the performance acceptance criteria, which help us categorize
the metrics used to test the application's performance under stress.

And also, identifying the success criteria for a stress test, for example, the maximum load can apply to the
application for it to fail.

Step3: Plan and design stress tests

In the next step of the stress testing process, we will plan and design a stress test plan, identify test scenarios etc.

Step4: Configure the test environment

Once the stress test plan has been created successfully, we will move to our next step where we create the test
environment, tools and resources essential to perform each approach as features and components become available
for test.

Step5: Implement test design

After the test environment's configuration, we will develop the stress tests resulting the test design best performs.

Step6: Execute tests

In the next step, we will execute the particular test, observe and confirm the tests along with test data and output
collection.
 UNIT 3 : Software Testing Basics
Step7: Analyze the results

In the last step of the stress testing process, we will analyze the outcomes, combine and share the respective teams'
output data.

Stress testing tools

As we know that stress testing is part of performance testing, the tools used for performance testing can be used
for stress testing.Therefore, we have various types of Stress testing tools available in the market, where some are
commercial tools and open-source tools. Some of the most commonly Stress testing are listed below:

o Apache JMeter

o NeoLoad

o Stress tester

o LoadRunner

Advantages and disadvantages of Stress Testing

Advantages

Some of the vital benefits of performing Stress testing is as follows:

o Stress testing signifies the system's behavior after failure and makes sure that the system recovers quickly
from the crashes.

o The most important advantage of executing the stress testing will make the system work in regular and
irregular conditions in a suitable way.

o It determines the scalability and enhance the performance of the software.

Disadvantages

Some of the most common drawbacks of Stress testing are as follows:

o Even in open-source tools like JMeter, a load testing environment is required, which should be as close to
the production environment setup as possible.

o If we are writing the Stress test script, the person should have enough scripting knowledge of the language
supported by the particular tool.

o If we are using stress testing, it will require additional resources, which makes this testing bit costlier.

o If we perform the Stress Testing manually, it became a tedious and complicated task to complete, and it may
also not produce the expected results.

Overview

In this tutorial, we have understood that stress testing is used to assess the system under extreme situations. It can
verify the system to recover back to normal status.

It is a type of non-functional testing and generally executed after the functional testing.

Stress testing entirely concentrate on testing the system under extreme load situations to detect its breaking
point and see if suitable messages are shown when the system is not responsive.

Recovery testing

In this section, we are going to understand recovery testing, which is an important part of Non-functional
testing and used to test how soon the application is recovered from the hardware crashed or fails.
 UNIT 3 : Software Testing Basics
And we also learn about its process, why we need to perform the recovery testing, who perform the recovery
testing, example, advantage and disadvantage.

Introduction of Recovery Testing

Recovery testing is testing where the test engineer will test the application to check how well the Software or the
application recovers from disasters or crashes.

It is one of the most important types of non-functional testing categorized under performance testing.

In other words, we can say that the recovery testing is done to verify how fast and better the application can
improve or learn the capability of the software after it has gone through any software, hardware crashes or
network failures etc.

It is the software's required failure in a diversity of ways to confirm that recovery is properly performed.

While executing the recovery testing, we should first take the backup and save it to a secured location to keep away
from any data loss if the data is not recovered successfully.

The software/ hardware is forcefully failed to verify the following aspects while executing the recovery testing:

o Lost data can be retrieved completely or not.

o It fails to verify that the fraction of scenarios in which the system can recover back.

o It is failing to verify that if any other additional operations of the software can be done or not.

Example of Recovery testing

Let us see a scenarios where we can understand how the recovery testing is performed:

Scenario 1

Suppose we are using the browser, let say Google Chrome, and the power goes off. When we switch on the system
again and re-open Google Chrome, we get a message window that displays whether we want to start a new session
or restore the previous session.

So, in this situation, while we are restarting the system while a browser has a definite number of sessions and check
if the browser can recover all of them or not.

Some of the most common failures which need to test for recovery:

Here, we list out some of the most frequent failures which needs to test, while performing the recovery testing:

o External device not responding

o Network issue

o Wireless network signal loss

o Power failure

o Server not responding

o Database overload

o External server not reachable

o DLL file missing

o Physical conditions

o Stopped services
 UNIT 3 : Software Testing Basics
Why recovery testing is important?

The recovery testing is significant if we are developing the application for a user who will decides the difference
between success and failure for our organization. T

Therefore, we need to develop software, which has enough consistency and recoverability.

When do we need to perform the recovery testing?

o Whenever we have a release or upgrade, we need to review the system-specific recovery testing.

o To perform recovery testing, we need to ensure that everyone is included in each other's roles and
responsibilities.

o Critical business functions can normally run when there is a failure or disaster.

Who implements Recovery testing?

The Recovery testing is a part of Business Continuity Planning (BCP) and involves a host of roles. The following
concerned persons can perform the recovery testing:

o It can be executed by the Production Service and Service Management teams who have the knowledge and
experience in managing such outages.

o The Technical SMEs recognize the core systems maintained by the hardware.

o The recovery testing can perform by the IT operations teams which manage servers and other hardware
infrastructure.

Recovery testing life cycle

The recovery testing life cycle includes the various phase, which is as follows:

o Standard operations

o Disaster and failure occurrence

o Interruption to Standard Process

o Recovery Process

o Rebuild Process

Let's understand them one by one in details:

o Standard Operations

In the standard operations phase, we will establish the system according to the Software and hardware
requirements, where the particular system can execute as expected. It is used to define the way system is planned to
work.

o Disaster and failure Occurrence

In the next phase of recovery testing, we can identify the several failures of the system and those failures are as
follows:
 UNIT 3 : Software Testing Basics
o Power failure

o Hardware failure

o Physical conditions

o Server not reachable and many more.

o Interruption to Standard Process

It leads us to losses in terms of business, financial losses, relations with the client, reputation in the market, etc.

o Recovery Process

In recovery testing, the recovery process is used to keep away from the most important losses in companies and
have backup plans with minimal impact on the interruption system.

o Rebuild Process

The last phase of the recovery testing process is the rebuild process, which contains the already specified documents
and processes that have to be followed. And in this phase, all configuration files and folders are restored to retrieve
the lost data.

Steps to be performed before implementing a Recovery Testing:

The following steps need to be performed before executing the recovery testing process to ensure the performance
of recovery testing:

Step1: Appropriate recovery analysis

Before implementing the recovery testing, we should make sure that the proper analysis has to be done to verify the
possibility of recovery. The recovery analysis is necessary for our better understanding of the recovery-related
modification, which can impact the system's working.

To complete the appropriate analysis, we can observe the below aspects:

o The system's capability to allocate additional resources such as servers in case of critical failures or
additional CPUs.

o How to track the failures.

o The effect of the failures, failures that can occur, and solutions to the failure.

Step2: Preparation of Test Plan

In the next step, we will prepare the Test cases according to the analysis results, which we discussed in the above
step.

Step3: Preparation of Test environment

 UNIT 3 : Software Testing Basics
After preparing the test cases, we moved to our next step to design the test environment as per the recovery
analysis results.

Step4: Keeping the Back-up of the data

After the preparing the test cases and test environment, we can go to our next step to keep the back-up data related
to the software, for example, several states of the software and database.

Similarly, if the data is significant, then we can keep the backup data depending upon the criticality, with the help
of the below strategies:

o The backing up of the data at one or various locations.

o Single back up or Multiple back-ups.

o Automatic set up for back up at every n minute, for example, 20 minutes.

o Online and Offline backups.

o To perform and track the backups, we can have a separate team.

o Allocation of resources for recovery testing.

Step5: Recovery personnel Allocation

Once the backup of data is sustained successfully, we will have enough knowledge for the recovery testing being
conducted and allocate the recovery personnel.

Step6: Documentation

In the last step, we will document all the steps performed before and throughout the recovery testing because, in
case of a failure, the system can be tested for its performance.

Advantages and Disadvantages of Recovery testing

Advantages

Some of the major benefits of performing the recovery testing are as follows:

o One of the most important advantages of recovery testing is to recovers system quality because whenever
the bugs are detected and fixed, it improves the system's quality.

o The recovery testing will help us to remove risks.

o It helps us to decreases the risk of failure of the software product in the market.

o When we implement the recovery testing, we can easily identify the performance-related issues and fix
them before the software product goes live in the market.

o The system is more stable, reliable and bug-free once we performed the recovery testing.

Disadvantages

Following are the disadvantages of recovery testing:

o Recovery testing is a time-consuming process as the test cases are random.

o It is an expensive process.

o A skilled person is essential to test the recovery testing; if the untrained test engineer implements the
recovery testing, they should have all the data for testing: data and backup files.
 UNIT 3 : Software Testing Basics
o In recovery testing, we may not detect all the potential bugs in a few cases because sometimes the issues
are unpredictable.

Overview

In the above recovery testing tutorial, we have understood the numerous recovery testing characteristics, which
helps to learn whether the system or program meets its requirements after a failure.

Recovery testing is necessary if we have any project that overhauls business processes or technology. In case of
failures it helps us to validate that recovery.

The occurrence of executing recovery testing is in reverse proportional to the impact of failure on the system.
Therefore, recurrent testing plays an important role in minimizing the impact.

As we know that the failures can happen anytime due to many common reasons, such as recovery testing removes
critical bugs, which makes the system ready to recover from those failures.

Exploratory Testing

In this section, we will learn about exploratory testing, its types, when we use it, the advantage and disadvantages of
it.

What is exploratory testing?

If requirement does not exist, then we do one round of exploratory testing.

So, for this first, we will be exploring the application in all possible ways, understanding the flow of the application,
preparing a test document and then testing the application, this approach is known as exploratory testing.

When we use exploratory testing

We will use this testing for the following aspects:

o When the requirement is missing

o Early iteration is required

o The testing team has the experienced testers when we have a critical application, and new testers entered
into the team.

For example, to test any software or the application, first, we will perform unit, integration, and system testing.

So if we want to understand any application first, we will perform unit or component testing, suppose the
application is having a login page having many elements, and we will understand each part and doing the component
testing, but actually, we are doing the exploratory testing because we are exploring the application.

Suppose we have many modules in the application, and we are trying to do some integration scenarios.

Indirectly we are just doing exploratory testing while performing the integration testing.

And, even if we are performing system testing, indirectly, we are performing exploratory testing because here we
are also understanding and exploring the application.

Why the requirement is missing

The requirement is missing because of the following reasons:

If the project is very old, the test engineer can't understand each scenario from the starting, and it might happen
that the requirements will be missing.

For example, in each company, we don't see any fast process which means, we cannot expect the release to be done
in just one month, and the product should be delivered in very less duration of time.
 UNIT 3 : Software Testing Basics
Many companies are still in the development phase for a particular product from the last 6 to 12 years.

Suppose one company has a 15-year-old project, and they hired a new test engineer now. The new test engineer
faces many difficulties in understanding every scenario or requirement from scratch or starting because he/she is
new with the application.

In that case, what test engineer will do with software that is 15 years old?

So firstly, he/she will take the application and start exploring the application. Once the test engineer starts using the
application, he/she will get to know how the application is working. And, this process is nothing but exploratory
testing.

How to perform exploratory testing

To perform exploratory testing, first, we will start using the application and understand the requirement of the
application from the person who has a good product knowledge such as senior test engineer, and developers.

Then we will explore the application and write the necessary document, and this document is sent to the domain
expert, and they will go through the document.

And we can test the application based on our knowledge, and taking the help of the competitive product, which is
already launched in the market.

Types of exploratory testing

Exploratory testing can be divided into three parts, which are as follows:

o Freestyle

o Strategy based

o Scenario-based

Freestyle

In freestyle testing, we did not follow any rules, there is no maximum coverage, and we will explore the application
just like Adhoc testing.

If we want to get friendly with the software and checks the other test engineer's works, we can use freestyle
exploratory testing.

Strategy based

ADVERTISEMENT

ADVERTISEMENT

Strategy based exploratory testing can be performed with the help of multiple testing techniques such as risk-based,
boundary value analysis, and equivalence partitioning.

It is done by the experienced tester and who is using the application for the longest time because he/she is known
the application very much.

Scenario-based

Scenario-based exploratory testing is performed with the help of multiple scenarios such as end-to-end, test
scenarios, and real user scenarios.

The test engineer can find defects and also checks various set of possibilities for the multiple scenarios with their
application knowledge while they were exploring the application.

Advantages and Disadvantages of Exploratory Testing

 UNIT 3 : Software Testing Basics
Advantages

Following are some benefits of exploratory testing:

o If the test engineer using the exploratory testing, he/she may get a critical bug early because, in this testing,
we need less preparation.

o In this testing, we can also find those bugs which may have been missed in the test cases.

o This testing can be used to test the new features, whereas, for the existing functionality, we will use the
regression testing if we have less time to test the application.

o For the test engineer, this testing requires a lot of concentration to explore the application.

Disadvantages

Following are the disadvantages of exploratory testing:

o Time Consuming
It is a time taking process because we don't know the requirement, and which feature has to be tested first
because we are just exploring the application.

o The test engineer will misunderstand the feature as a bug.

For example, suppose we have one login page and requirement says we have to provide the necessary
details like username, password, and employee id then click on the login button.
But while performing exploratory testing, we only provide the details of username, password, and then click
on the login button, but we have not entered the employee id. Since we don't have the requirement, and
doing exploratory testing, that's why we feel that the employee id component is a bug, but it is a feature.

o Bugs can be misunderstood as a feature

For example, suppose we have one registration page where we have to provide details like the username,
password, mobile number, and the email id.
And the requirement says that when we are providing the mobile number and email id, the same code will
be sent to the registered email id and mobile number to verify whether it is correct or not.
But when we are performing exploratory testing on the registration page and provide all the details (user
name, password, mobile number, and email id), the code will only be sent to our mobile number, not to the
email id.
It is happening because the requirement is missing, and we will be misunderstood that this bug is a feature,
and we never come to that this is a bug.

Visual testing

Visual testing is used to examine what happened at the point of software failure by defining the data in such a way
that the developer can quickly identify the reason of failure, and the information is expressed clearly so that any
other developer can utilize this information.

Visual testing aims to show actual problem rather than just to describe it, remarkably it increases understanding and
clarity so that the problem can be solved quickly.
 UNIT 3 : Software Testing Basics
The general meaning of visual is optical means what we can see. Therefore, visual testing requires the video
recording of the entire process. It captures everything that happens at the time of system testing in video format.
Tester gives a picture in a picture webcam and audio commentary from microphones as an input value.

Visual Inspection System

System for visual inspection consists of a high-quality video camera for collecting data and software and computer to
analyze data. The video camera is used to capture a picture of the object during the testing process. These object
pictures are sent to a computer via a frame grabber.

The computer has software that analyze the pictures and decide whether the object fails or passes the inspection.

The conditions under which the video testing system works necessarily well controlled and easy to maintain testing
persistence.

Visual testing offers a number of advantages. It increases the quality of communication drastically because testers
can optically present the problem to the developer as opposed to describing it in written document form. The
developer has all the required evidence of a test failure so, the focus is only on the cause of the failure and how to fix
it.

Some remarkable advantages and disadvantages are given below:

Advantages of Visual Testing

o Visual testing is cheap because information is recorded in video form. So, we don't need to replicate the
information in any other form. It saves money.

o Visual testing provides portability. A tester can provide video to any other tester if the type of software is
same. So, in the case of system failure, we don't loss the data.

o Visual testing saves the time of testing as if once the testing process is done and saved in visual form so, we
do not need to test software again. Developer can identify the defect by seeing the video.

o Visual testing requires the minimum number of special skills.

o Visual testing requires minimum part preparation because there is a need to find only the reason for system
failure.

Disadvantages of Visual Testing:

o Visual testing is suitable only for the surface which can be visible so, need to arrange suitable surface.

o Visual testing cannot detect hidden defects; it can detect only larger defects.

o To record clear visible video lighting must be well implemented.

o It follows only rules does not emulate human inspections.

o Scratches and cracks can create misinterpretation.

o Visual testing does not provide component variations on the product if there is variation in software
components it cannot be tested via visual testing.
 UNIT 3 : Software Testing Basics
Summary

Visual testing is used when we test software with easily detectable defects and do not allow component variations.

Acceptance testing

Acceptance testing is formal testing based on user requirements and function processing. It determines whether the
software is conforming specified requirements and user requirements or not. It is conducted as a kind of Black Box
testing where the number of required users involved testing the acceptance level of the system. It is the fourth and
last level of software testing.

User acceptance testing (UAT) is a type of testing, which is done by the customer before accepting the final product.
Generally, UAT is done by the customer (domain expert) for their satisfaction, and check whether the application is
working according to given business scenarios, real-time scenarios.

In this, we concentrate only on those features and scenarios which are regularly used by the customer or mostly user
scenarios for the business or those scenarios which are used daily by the end-user or the customer.

However, the software has passed through three testing levels (Unit Testing, Integration Testing, System Testing) But
still there are some minor errors which can be identified when the system is used by the end user in the actual
scenario.

Acceptance testing is the squeezing of all the testing processes that have done previously.

Note:

It is done in the separate environment at the customer place, which is known as the UAT environment. The user
acceptance testing is done by a different team called as domain expert who is known to the application.

Generally, small companies do not have a domain expert because there is no frequent changes happen in the
application.

Reason behind Acceptance Testing

Once the software has undergone through Unit Testing, Integration Testing and System Testing so, Acceptance
Testing may seem redundant, but it is required due to the following reasons.

o During the development of a project if there are changes in requirements and it may not be communicated
effectively to the development team.

o Developers develop functions by examining the requirement document on their own understanding and may
not understand the actual requirements of the client.

o There's maybe some minor errors which can be identified only when the system is used by the end user in
the actual scenario so, to find out these minor errors, acceptance testing is essential.

Note:
Once we collect the requirement from the customer and done the coding process completely then the test engineer
starts all different types of testing until the application becomes stable.
 UNIT 3 : Software Testing Basics

Once the application is bug-free, we handover it to the customer, no customer accept the application blindly before
using it. Hence, they do one round of testing for their satisfaction, which is known as user acceptance testing.

Who performs user acceptance testing?

The acceptance testing can be performed by different persons in different cases.

For example, the blue-dart company gives the requirement to TCS for developing the application, and the TCS will
accept the needs and agree to deliver the application in the two releases as we can see in the below image:

On August 10, the test manager tells the project manager that there is a critical bug in the application, and that will
take another four days to fix it.

But the project manager said we have to deliver the software within a given time. It takes another 30 days to fix the
defect, or otherwise, we will have to pay the penalty (fine) for each day after the given release date. Is this the real
situation? NO, let us see three different cases and understand who perform the acceptance testing.

Case1

In this, we will discuss how the acceptance testing is performed, and here the test engineer will do the acceptance
testing.

Mostly, the actual flow for testing the application will be seen in the above image, but here it is little difference, as
we know where the end-to-end testing or system testing ends and the acceptance testing will proceed. To
understand this scenario, follow the below process:

The blue-dart provides the requirements, and TCS develops the application and performs all the testing and
handover to the blue-dart company.

Now the question arises the blue-dart will use the application as soon they get it from TCS? NO, the blue dart
company has a group of test engineers after they get the software, and this team will start testing the application,
and this end-to-end testing is done at the customer environment, which is called the User Acceptance Testing.

Let us see the difference between TCS test engineers and Blue-dart Engineers:
 UNIT 3 : Software Testing Basics
In TCS, the tester will perform the functional testing, integration testing, and system testing and whereas in Blue-
dart, the tester will do only the end-to-end or system testing, which is known as acceptance testing.

The difference between end-to-end testing at TCS and blue-dart is as follows:

o The blue-dart test engineer is the one who gave the requirements

o The blue-dart engineer understands the product well

o The blue-dart engineer is a domain expert.

o They test the real-time data on the application.

To understand this, we can see the below example, or if we have the application format is like this:

When the application is given to blue-dart test engineers, and they will perform testing and the application should
generate a text message "Parcel 1 invoice Id created." It was not mentioned in the requirement, or it is there, and
TCS does not fix it. Then fine(penalty) counts for TCS from that only, and whereas the test engineers at TCS will not
knowing this, due to that, we can see the difference between the testing done at TCS and Blue-dart.

Case2

In this case, we will see how the Employee is becoming end-users and performing acceptance testing.

The application is developed and tested at the TCS environment and then sent to blue-dart. And in the Blue-dart,
they have fewer test engineers, so they can't do acceptance testing. So for this, out of 300 employees of blue-dart,
they will provide the application to the 30 employees and install the application to their systems and ask them to
start using the application and find any defect or issues.

Now 30 employees will do the dummy implementation, which means they provide the data into the application and
also written that data manually. And here, the employee becomes the end-user and also identify the bugs and issues
while using the application.

These issues are verified against the requirements, and now the fine is charged for TCS (sometimes the penalty is
charged on an hourly basis). If the identified bug is not as per requirement, then blue-dart can go for the Request
 UNIT 3 : Software Testing Basics
For Enhancement [REF] and Change Request [CR].

Where Request for enhancement means that if the blue-dart feels that a particular module can be improved and
developed in a better way, and then they can send the Customer Requirement Specification [CRS] as REF and TCS
will follow the CRS and also make sure to do the necessary changes.

And the Change Request means, if the requirement has not been specified accurately, then blue-dart provides the
exact needs and Request for changes.

Therefore, the acceptance testing can also be defined as end-to-end testing, which can be done by the engineers
who are working in the client environment. Here, they take real-time scenarios and check whether the application is
working fine or not, and also we can make real-time business scenarios because the end-user knows how the
business flow works.

Case3

In this case, if the blue-dart customers become the end-users.

Here, the application is developed and tested and implemented at a blue-dart production server, and n-numbers of
users start using the application, which is in the first release. While using the application, the blue-dart comes up
with more number of features and enhancements, which is sent with the CRS to the TCS after that TCS will do the
further changes in modules and sent it back to the blue-dart.

Hence, what is happing here, the application was developed when the requirement is collected by blue-dart from
their end-users and customers.

The numbers of releases depend on the following facts:

o Difficulty of modules

o The number of modules.

o How the new module affects the old module.

Hotfix: In the production environment, whenever the customer identify the critical bug, we will do the following

o The developers fix the bugs.

o Small teams of test engineers will test the software.

o Re-install the application on the client environment.

o The client starts using the new software.

This entire process is known as a hotfix, and it can be done in a few hours or one day.

For example: If the significant module, suppose the Login module itself is not working at the production server, then
the client will send it immediately for fixing it, and that has to be done as soon as possible.

Short release

Between two major releases, this is a short release of improvements, and it happens when the client needs some
small features to change on an urgent basis.

For example, if we have 60 developers, where the ten developers will come out, and out of 40 test engineers, the 3
test engineers will come out, and they develop and test the application. And before adding it to the production
server, the customer does one short round of acceptance testing.
 UNIT 3 : Software Testing Basics
Steps to Perform Acceptance Testing

Requirement Analysis:

In this step, the testing team analyzes requirement document to find out the objective of the developed software.
Test planning accomplished by using requirement document, Process Flow Diagrams, System Requirements
Specification, Business Use Cases, Business Requirements Document and Project Charter.

Test Plan Creation:

Test Plan Creation outlines the whole strategy of the testing process. This strategy is used to ensure and verify
whether the software is conforming specified requirements or not.

Test Case Designing:

This step includes the creation of test cases based on test plan documents. Test cases should be designed in a way
that can cover most of the acceptance testing scenario.

Test Case Execution:

Test Case Execution includes execution of test cases by using appropriate input values. The testing team collects
input values from the end user then all test cases are executed by both tester and end user to make sure software is
working correctly in the actual scenario.

Confirmation of objectives:

After successful completion of all testing processes, testing team confirms that the software application is bug-free
and it can be delivered to the client.

Tools used in Acceptance Testing

Acceptance Testing can be done by using several tools; some are given below:

done by using several tools; some are given below:

Watir:

Acceptance testing uses this tool for the execution of automated browser-based test cases. It uses Ruby language for
the inter-process communication.
 UNIT 3 : Software Testing Basics
Fitness tool:

This tool is used to enter input values and generate test cases automatically. The user needs to input values, these
values used by the tool to execute test cases and to produce output. It uses Java language for the inter-process
communication. This tool makes it easy to create test cases as well as record them in the form of a table.

Advantages of Acceptance Testing

o It increases the satisfaction of clients as they test application itself.

o The quality criteria of the software is defined in an early phase so that the tester has already decided the
testing points. It gives a clear view to testing strategy.

o The information gathered through acceptance testing used by stakeholders to better understand the
requirements of the targeted audience.

o It improves requirement definition as client tests requirement definition according to his needs.

Disadvantages of Acceptance Testing

According to the testing plan, the customer has to write requirements in their own words and by themselves but

a. Customers are not willing to do that; it defeats the whole point of acceptance testing.

b. If test cases are written by someone else, the customer does not understand them, so tester has to perform
the inspections by themselves only.

If the process is done in this manner, it destroys the existence of the Acceptance Testing.

Alpha Testing Introduction

Alpha testing is conducted in the organization and tested by a representative group of end-users at the developer's
side and sometimes by an independent team of testers.

Alpha testing is simulated or real operational testing at an in-house site. It comes after the unit testing, integration
testing, etc. Alpha testing used after all the testing are executed.

It can be a white box, or Black-box testing depends on the requirements - particular lab environment and simulation
of the actual environment required for this testing.
 UNIT 3 : Software Testing Basics

What is the alpha testing process?

Alpha testing follows the following process:

1. Requirement Review: Review the design of the specification and functional requirement

2. Test Development: Test development is base on the outcome of the requirement review. Develop the test
cases and test plan.

3. Test case design: Execute the test plan and test cases.

4. Logging Defects: Logging the identified and detected bug found in the application.

5. Bug Fixation: When all the bugs are identified and logged, then there is a need to fix the bug.

6. Retesting: When all the issues are solved, and fixed retesting is done.

What are the phases of alpha testing?

Alpha testing ensures that the software performs flawlessly and does not impact the reputation of the organization;
the company implements final testing in the form of alpha testing. This testing executed into two phases.
 UNIT 3 : Software Testing Basics

There are two phases of alpha testing.

First Phase: In-house developers of software engineers do the first phase of testing. In this phase, the tester used
hardware debugger or hardware aided debugger to catches the bugs quickly. During the alpha testing, a tester finds
a lot of bugs, crashes, missing features, and docs.

Second Phase: The second phase involves the quality assurance staff performs the alpha testing by involving black
box and white box techniques.

When to perform alpha testing?

Alpha testing is user acceptance testing. Alpha testing performed once the product has gone through stages of
testing and prepared for release. It is executing before beta testing, which is also a part of acceptance testing and
can define as field testing. During this testing, we can make changes in the software to improve its quality and
functionality. Alpha testing done from the developer's site where independent developers can monitor and record
user experience and make necessary changes to enhance the performance.

What are the reasons to perform Alpha Testing?

Alpha testing is the final stage of the testing. Alpha testing is an essential and popular testing technique that helps
the team to deliver quality and useful software. This testing performed before the release of the product. Alpha
testing can define as the first round of independent testing that ensures that the software run as per the
requirement plan.
 UNIT 3 : Software Testing Basics
Reasons for alpha testing are:

o Refines the software product by finding and rectifying bugs that weren't discovered through previous tests.

o Alpha testing allows the team to test the software in a real-world environment.

o One of the reasons to do alpha testing is to ensure the success of the software product.

o Alpha testing validates the quality, functionality of the software, and effectiveness of the software before it
released in the real world.

What are the features of Alpha Testing?

o Alpha testing is a type of acceptance testing.

o Alpha testing is happening at the stage of the completion of the software product.

o Alpha testing is in the labs where we provide a specific and controlled environment.

o Alpha testing is in-house testing, which is performed by the internal developers and testers within the
organization.

o There is not any involvement of the public.

o Alpha testing helps to gain confidence in the user acceptance of the software product.

o With the help of black box and white box technique, we can achieve the alpha testing.

o Alpha testing ensures the maximum possible quality of the software before releasing it to market or client
for beta testing.

o Developers perform alpha testing at developer's site; it enables the developer to record the error with the
ease to resolve found bugs quickly.

o Alpha testing is doing after the unit testing, integration testing, system testing but before the beta testing.

o Alpha testing is for testing the software application, products, and projects.

What are the advantages of Alpha Testing?

Advantages of alpha testing are:

o One of the benefits of alpha testing is it reduces the delivery time of the project.

o It provides a complete test plan and test cases.

o Free the team member for another project.

o Every feedback helps to improve software quality.

o It provides a better observation of the software's reliability and accountability.

What are the disadvantages of Alpha Testing?

Disadvantages of alpha testing are:

o Alpha testing does not involve in-depth testing of the software.

o The difference between the tester's tests the data for testing the software and the customer's data from
their perspective may result in the discrepancy in the software functioning.

o The lab environment is used to simulate the real environment. But still, the lab cannot furnish all the
requirement of the real environment such as multiple conditions, factors, and circumstances.
 UNIT 3 : Software Testing Basics
Wrap Up:

Every software product needs to undergo a vital methodology before going into a highly competitive market. Alpha
testing is one of the vital testing. It needs to be considered by going through the functionality of the software and
achieve the confidence in its user acceptance for the real environment, before releasing it into the market.

What is Beta Testing?

Beta testing is a type of User Acceptance Testing among the most crucial testing, which performed before the
release of the software. Beta Testing is a type of Field Test. This testing performs at the end of the software testing
life cycle. This type of testing can be considered as external user acceptance testing. It is a type of salient testing.
Real users perform this testing. This testing executed after the alpha testing. In this the new version, beta testing is
released to a limited audience to check the accessibility, usability, and functionality, and more.

o Beta testing is the last phase of the testing, which is carried out at the client's or customer's site.

What are the features of beta testing?

Testing of the product performs by the real users of the software application in the real environment. Beta version of
the software is released to a restricted number of end-users to obtain the feedback of the product quality. Beta
testing reduces the risk of failure and provides the quality of the product through customer validation. It is the final
testing before shipping the product to the customers. Beta testing obtains direct feedback from the customers. It
helps in testing to test the product in the customer's environment.

Features of beta testing are:

o Beta testing used in a real environment at the user's site. Beta testing helps in providing the actual position
of the quality.

o Testing performed by the client, stakeholder, and end-user.

o Beta testing always is done after the alpha testing, and before releasing it into the market.

o Beta testing is black-box testing.

o Beta testing performs in the absence of tester and the presence of real users

o Beta testing is performed after alpha testing and before the release of the final product.

o Beta testing generally is done for testing software products like utilities, operating systems, and applications,
etc.

What is a beta version of the software?

The beta version of the software is delivered to a restricted number of users to accept their feedback and
suggestions on quality improvement. Hence, there are two types of beta version:

1) Closed beta version: Closed beta version, also known as a private beta, it is released to a group of selected and
invited people. Those people will test the software and evaluate their features and specifications. This beta version
represents the software which is capable of delivering value, but it is not ready to be used by everyone. Because it
shows the issues like lack of documentation or missing vital features.
 UNIT 3 : Software Testing Basics

2) Open beta version: Open beta is also known as a public beta. The open beta opened to the public. Any user as a
tester can assess the beta version to provide the relevant feedback and reviews. Open beta version improves the
quality of the final release. This version helps to find the various undetected errors and issues.

The beta testing process orients this beta version.

What is the lifecycle of Beta Testing?

A group of end-users performs beta testing. This process can't execute without any strategy or test plan. Before the
testers, the end-user executes this type of testing.

The process of beta testing follows the following steps:

1. Planning: Like another testing process, beta testing also supports proper planning. In this stage, the team
prepares a testing strategy and defines the goal of testing. In this case, the team establishes the need of
users for testing, duration, and necessary details related to the process.

2. Participant Recruitment: This is the second stage of the beta process in which the team recruits a group of
selected end-users for testing. This group can change as per the requirement of the organization and the
product.

3. Product Launch: When a team of users (testers) recruited. The beta version of the product is launched or
installed at the client or user side, and users will test the product for quality assurance.

4. Collect and Evaluate Feedback: When the testing finished, developers will collect the feedback provided by
the testers and evaluate it. In the end, based on the feedback, issues, and bugs are fixed and resolved by the
responsible individual team.

5. Closure: When all the problems fixed and the organization meets the exit criteria, beta testing achieved, and
the rewards offered to the testing team.
 UNIT 3 : Software Testing Basics
What are the types of beta testing?

Beta testing has six types. Each type has different aspects of the software. All these help developers to improve the
quality of the software and allow them to deliver a product that offers excellent user experience. Here are the
different types of beta testing:

1. Open Beta Testing: Open beta testing involves testing the software product by a large number of people
before the final release. The organization decides to make a software product open to the public before
releasing the product. Open Beta includes the extensive participation of the public to use and evaluate
software product accordingly.
Users report the bug to the organization, along with a suggestion to improve the quality of the software.

2. Closed Beta Testing: Opposite to the open beta testing. Closed beta testing performed by the selective and
limited number of persons. The organization recruits these. In this testing software product is not open to
the public.

3. Traditional Beta Testing: In this testing, a software product delivered to the target market, and the feedback
from the users collected. This type of testing assistance the beta testing, the quality of the software is
improved, and developers can make the changes.

4. Public Beta Testing: This type of testing is similar to open testing. Public beta testing also allows the product
is delivering to the end-users worldwide, with the aid of various online channels available in the world. From
this, the feedback and evaluated data also collected and based on the requirement changes, and the
development team implements modifications.

5. Technical Beta Testing: Technical beta testing is also an essential type of beta testing. This testing involves
delivering the software product to the internal groups of the organization. However, the data and feedback
provided by the employees of the organization.

6. Focused Beta Testing: This type of testing focused on monitoring and evaluating a specific feature or
component of the software. In focused beta testing, the software released to the market and user's
experience assessed and collected to make the required changes.

7. Post-Release Beta Testing: In this testing, the product delivered to the market for the use of the end-users.
Their feedback, reactions, and experience are collect for the future release of the software.

When to perform Beta Testing?

Acceptance testing is the final phase of the testing, which combines both alpha and beta testing to ensure that the
product released flawlessly. Beta testing performed at the user's end. This testing always performed after the alpha
testing, but before the product released to the market. In this stage, the product is expected to be 90% to 95%
completed.

Any product undergoing to beta test should be reviewed for the entire checklist before launching it.

Some of them are:

o All the component of the product is ready to start this testing.

o Documentation which is going to end-user should be kept ready - Setup, installation, usage, Uninstallation
should be in detail.

o The product management team should review that all the functionality is in good condition.

o Procedure to collect bugs, feedback, etc. should be identified before publishing it.
 UNIT 3 : Software Testing Basics
What are the stakeholders and participants in the Beta Testing?

The product management, quality management, and user experience teams are the stakeholder in beta testing, and
they closely monitor every move of the phase.

The real users who use the product are the participants.

Beta test strategy

o Business objective for the product.

o Beta test plan

o The testing approach followed by participants.

o Tools used to detect bugs, measure productivity, collect feedback.

o When and how to end this testing phase?

What is a Beta Test plan?

A beta test plan can be written in many ways,

Objective: We should have to mention the aim of the project why there is a need for beta testing even after
performing the internal testing.

Scope: In this plan, we should mention the areas to be tested or not.

Test Approach: We should have to mention clearly that the testing is in the deep, what to focus on - functionality,
UI, response, etc.

Schedule: We have to specify, clearly the start and ending date with time, number of cycles, and duration per cycle.

Tools: Bug logging tools and the usage of the machines should identify.

Budget: Incentive of the bugs based on the severity.

Feedback: Collecting feedback and evaluating methods.

o Identify and review the entry and exit criteria.

What are the entry criteria for Beta Testing?

o Sign off the document from alpha testing.

o Beta version of the software should ready.

o The environment should be ready to release the software application to the public.

o To capture the real-time faults environment should be ready.

What are the exit criteria for Beta Testing?

o All the major and minor issues resolved.

o The feedback report should prepare.

o The delivery of beta test summary report.

 UNIT 3 : Software Testing Basics
What are the advantages of Beta Testing?

Beta testing performed at the end of the software testing lifecycle. Beta testing offers numerous benefits to testers,
software developer, as well as the users. In the assistance of this type of testing, it enables developers, testers to
test the product before its release in the market. The

1. Beta testing focuses on the customer's satisfaction.

2. It helps to reduce the risk of product failure via user validations.

3. Beta testing helps to get direct feedback from users.

4. It helps to detect the defect and issues in the system, which is overlooked and undetected by the team of
software testers.

5. Beta testing helps the user to install, test, and send feedback regarding the developed software.

What are the disadvantages of Beta Testing?

Disadvantages of beta testing is:

1. In this type of testing, a software engineer has no control over the process of the testing, as the users in the
real-world environment perform it.

2. This testing can be a time-consuming process and can delay the final release of the product.

3. Beta testing does not test the functionality of the software in depth as software still in development.

4. It is a waste of time and money to work on the feedback of the users who do not use the software
themselves properly.

Wrap Up

Keeping in mind the characteristics of beta testing can be concluded that beta testing may be considered desirable
for the organization. Beta testing provides the feedback of the real-users, which helps improve the software quality
before the product released in the market.

Black box testing

Black box testing is a technique of software testing which examines the functionality of software
without peering into its internal structure or coding. The primary source of black box testing is a
specification of requirements that is stated by the customer.

In this method, tester selects a function and gives input value to examine its functionality, and checks
whether the function is giving expected output or not. If the function produces correct output, then
it is passed in testing, otherwise failed. The test team reports the result to the development team
and then tests the next function. After completing testing of all functions if there are severe
problems, then it is given back to the development team for correction.
 UNIT 3 : Software Testing Basics
Generic steps of black box testing
o The black box test is based on the specification of requirements, so it is examined in the beginning.
o In the second step, the tester creates a positive test scenario and an adverse test scenario by selecting
valid and invalid input values to check that the software is processing them correctly or incorrectly.
o In the third step, the tester develops various test cases such as decision table, all pairs test, equivalent
division, error estimation, cause-effect graph, etc.
o The fourth phase includes the execution of all test cases.
o In the fifth step, the tester compares the expected output against the actual output.
o In the sixth and final step, if there is any flaw in the software, then it is cured and tested again.

Test procedure
The test procedure of black box testing is a kind of process in which the tester has specific knowledge
about the software's work, and it develops test cases to check the accuracy of the software's
functionality.

It does not require programming knowledge of the software. All test cases are designed by
considering the input and output of a particular function.A tester knows about the definite output
of a particular input, but not about how the result is arising. There are various techniques used in
black box testing for testing like decision table technique, boundary value analysis technique, state
transition, All-pair testing, cause-effect graph technique, equivalence partitioning technique, error
guessing technique, use case technique and user story technique. All these techniques have been
explained in detail within the tutorial.

Test cases
Test cases are created considering the specification of the requirements. These test cases are
generally created from working descriptions of the software including requirements, design
parameters, and other specifications. For the testing, the test designer selects both positive test
scenario by taking valid input values and adverse test scenario by taking invalid input values to
determine the correct output. Test cases are mainly designed for functional testing but can also be
used for non-functional testing. Test cases are designed by the testing team, there is not any
involvement of the development team of software.
 UNIT 3 : Software Testing Basics
Techniques Used in Black Box Testing
Decision Table Decision Table Technique is a systematic approach where various input combinations
Technique and their respective system behavior are captured in a tabular form. It is appropriate
for the functions that have a logical relationship between two and more than two
inputs.

Boundary Value Boundary Value Technique is used to test boundary values, boundary values are those
Technique that contain the upper and lower limit of a variable. It tests, while entering boundary
value whether the software is producing correct output or not.

State Transition State Transition Technique is used to capture the behavior of the software application
Technique when different input values are given to the same function. This applies to those types
of applications that provide the specific number of attempts to access the application.

All-pair Testing All-pair testing Technique is used to test all the possible discrete combinations of
Technique values. This combinational method is used for testing the application that uses
checkbox input, radio button input, list box, text box, etc.

Cause-Effect Cause-Effect Technique underlines the relationship between a given result and all the
Technique factors affecting the result.It is based on a collection of requirements.

Equivalence Equivalence partitioning is a technique of software testing in which input data divided
Partitioning into partitions of valid and invalid values, and it is mandatory that all partitions must
Technique exhibit the same behavior.

Error Guessing Error guessing is a technique in which there is no specific method for identifying the
Technique error. It is based on the experience of the test analyst, where the tester uses the
experience to guess the problematic areas of the software.

Use Case Use case Technique used to identify the test cases from the beginning to the end of
Technique the system as per the usage of the system. By using this technique, the test team
creates a test scenario that can exercise the entire software based on the functionality
of each function from start to end.

White Box Testing

The box testing approach of software testing consists of black box testing and white box testing. We are discussing
here white box testing which also known as glass box is testing, structural testing, clear box testing, open box
testing and transparent box testing. It tests internal coding and infrastructure of a software focus on checking of
predefined inputs against expected and desired outputs. It is based on inner workings of an application and revolves
around internal structure testing. In this type of testing programming skills are required to design test cases. The
primary goal of white box testing is to focus on the flow of inputs and outputs through the software and
strengthening the security of the software.
 UNIT 3 : Software Testing Basics
The term 'white box' is used because of the internal perspective of the system. The clear box or white box or
transparent box name denote the ability to see through the software's outer shell into its inner workings.

Developers do white box testing. In this, the developer will test every line of the code of the program. The
developers perform the White-box testing and then send the application or the software to the testing team, where
they will perform the black box testing and verify the application along with the requirements and identify the bugs
and sends it to the developer.

The developer fixes the bugs and does one round of white box testing and sends it to the testing team. Here, fixing
the bugs implies that the bug is deleted, and the particular feature is working fine on the application.

Here, the test engineers will not include in fixing the defects for the following reasons:

o Fixing the bug might interrupt the other features. Therefore, the test engineer should always find the bugs,
and developers should still be doing the bug fixes.

o If the test engineers spend most of the time fixing the defects, then they may be unable to find the other
bugs in the application.

The white box testing contains various tests, which are as follows:

o Path testing

o Loop testing

o Condition testing

o Testing based on the memory perspective

o Test performance of the program

Path testing

In the path testing, we will write the flow graphs and test all independent paths. Here writing the flow graph implies
that flow graphs are representing the flow of the program and also show how every program is added with one
another as we can see in the below image:

And test all the independent paths implies that suppose a path from main() to function G, first set the parameters
and test if the program is correct in that particular path, and in the same way test all other paths and fix the bugs.

Loop testing

In the loop testing, we will test the loops such as while, for, and do-while, etc. and also check for ending condition if
working correctly and if the size of the conditions is enough.
 UNIT 3 : Software Testing Basics
For example: we have one program where the developers have given about 50,000 loops.

1. {

2. while(50,000)

3. ……

4. ……

5. }

We cannot test this program manually for all the 50,000 loops cycle. So we write a small program that helps for all
50,000 cycles, as we can see in the below program, that test P is written in the similar language as the source code
program, and this is known as a Unit test. And it is written by the developers only.

1. Test P

2. {

3. ……

4. …… }

As we can see in the below image that, we have various requirements such as 1, 2, 3, 4. And then, the developer
writes the programs such as program 1,2,3,4 for the parallel conditions. Here the application contains the 100s line
of codes.

The developer will do the white box testing, and they will test all the five programs line by line of code to find the
bug. If they found any bug in any of the programs, they will correct it. And they again have to test the system then
this process contains lots of time and effort and slows down the product release time.

Now, suppose we have another case, where the clients want to modify the requirements, then the developer will do
the required changes and test all four program again, which take lots of time and efforts.

These issues can be resolved in the following ways:

In this, we will write test for a similar program where the developer writes these test code in the related language as
the source code. Then they execute these test code, which is also known as unit test programs. These test programs
linked to the main program and implemented as programs.
 UNIT 3 : Software Testing Basics

Therefore, if there is any requirement of modification or bug in the code, then the developer makes the adjustment
both in the main program and the test program and then executes the test program.

Condition testing

In this, we will test all logical conditions for both true and false values; that is, we will verify for
both if and else condition.

For example:

1. if(condition) - true

2. {

3. …..

4. ……

5. ……

6. }

7. else - false

8. {

9. …..

10. ……

11. ……

12. }

The above program will work fine for both the conditions, which means that if the condition is accurate, and then
else should be false and conversely.

Testing based on the memory (size) perspective

The size of the code is increasing for the following reasons:

o The reuse of code is not there: let us take one example, where we have four programs of the same
application, and the first ten lines of the program are similar. We can write these ten lines as a discrete
 UNIT 3 : Software Testing Basics
function, and it should be accessible by the above four programs as well. And also, if any bug is there, we can
modify the line of code in the function rather than the entire code.

o The developers use the logic that might be modified. If one programmer writes code and the file size is up to
250kb, then another programmer could write a similar code using the different logic, and the file size is up to
100kb.

o The developer declares so many functions and variables that might never be used in any portion of the
code. Therefore, the size of the program will increase.

For example,

1. Int a=15;

2. Int b=20;

3. String S= "Welcome";

4. ….

5. …..

6. …..

7. ….

8. …..

9. Int p=b;

10. Create user()

11. {

12. ……

13. ……

14. ….. 200's line of code

15. }

In the above code, we can see that the integer a has never been called anywhere in the program, and also the
function Create user has never been called anywhere in the code. Therefore, it leads us to memory consumption.

We cannot remember this type of mistake manually by verifying the code because of the large code. So, we have a
built-in tool, which helps us to test the needless variables and functions. And, here we have the tool called Rational
purify.
 UNIT 3 : Software Testing Basics

Suppose we have three programs such as Program P, Q, and R, which provides the input to S. And S goes into the
programs and verifies the unused variables and then gives the outcome. After that, the developers will click on
several results and call or remove the unnecessary function and the variables.

This tool is only used for the C programming language and C++ programming language; for another language, we
have other related tools available in the market.

o The developer does not use the available in-built functions; instead they write the full features using their
logic. Therefore, it leads us to waste of time and also postpone the product releases.

Test the performance (Speed, response time) of the program

The application could be slow for the following reasons:

o When logic is used.

o For the conditional cases, we will use or & and adequately.

o Switch case, which means we cannot use nested if, instead of using a switch case.

As we know that the developer is performing white box testing, they understand that the code is running slow, or
the performance of the program is also getting deliberate. And the developer cannot go manually over the program
and verify which line of the code is slowing the program.
 UNIT 3 : Software Testing Basics
To recover with this condition, we have a tool called Rational Quantify, which resolves these kinds of issues
automatically. Once the entire code is ready, the rational quantify tool will go through the code and execute it. And
we can see the outcome in the result sheet in the form of thick and thin lines.

Here, the thick line specifies which section of code is time-consuming. When we double-click on the thick line, the
tool will take us to that line or piece of code automatically, which is also displayed in a different color. We can
change that code and again and use this tool. When the order of lines is all thin, we know that the presentation of
the program has enhanced. And the developers will perform the white box testing automatically because it saves
time rather than performing manually.

Test cases for white box testing are derived from the design phase of the software development lifecycle. Data flow
testing, control flow testing, path testing, branch testing, statement and decision coverage all these techniques used
by white box testing as a guideline to create an error-free software.

White box testing follows some working steps to make testing manageable and easy to understand what the next
task to do. There are some basic steps to perform white box testing.

Generic steps of white box testing

o Design all test scenarios, test cases and prioritize them according to high priority number.

o This step involves the study of code at runtime to examine the resource utilization, not accessed areas of the
code, time taken by various methods and operations and so on.

o In this step testing of internal subroutines takes place. Internal subroutines such as nonpublic methods,
interfaces are able to handle all types of data appropriately or not.

o This step focuses on testing of control statements like loops and conditional statements to check the
efficiency and accuracy for different data inputs.

o In the last step white box testing includes security testing to check all possible security loopholes by looking
at how the code handles security.

Reasons for white box testing

o It identifies internal security holes.

o To check the way of input inside the code.

o Check the functionality of conditional loops.

o To test function, object, and statement at an individual level.

Advantages of White box testing

o White box testing optimizes code so hidden errors can be identified.

o Test cases of white box testing can be easily automated.

o This testing is more thorough than other testing approaches as it covers all code paths.

o It can be started in the SDLC phase even without GUI.

 UNIT 3 : Software Testing Basics
Disadvantages of White box testing

o White box testing is too much time consuming when it comes to large-scale programming applications.

o White box testing is much expensive and complex.

o It can lead to production error because it is not detailed by the developers.

o White box testing needs professional programmers who have a detailed knowledge and understanding of
programming language and implementation.

Techniques Used in White Box Testing

Data Flow Data flow testing is a group of testing strategies that examines the control flow of programs in
Testing order to explore the sequence of variables according to the sequence of events.

Control Flow Control flow testing determines the execution order of statements or instructions of the program
Testing through a control structure. The control structure of a program is used to develop a test case for
the program. In this technique, a particular part of a large program is selected by the tester to set
the testing path. Test cases represented by the control graph of the program.

Branch Branch coverage technique is used to cover all branches of the control flow graph. It covers all the
Testing possible outcomes (true and false) of each condition of decision point at least once.

Statement Statement coverage technique is used to design white box test cases. This technique involves
Testing execution of all statements of the source code at least once. It is used to calculate the total number
of executed statements in the source code, out of total statements present in the source code.

Decision This technique reports true and false outcomes of Boolean expressions. Whenever there is a
Testing possibility of two or more outcomes from the statements like do while statement, if statement and
case statement (Control flow statements), it is considered as decision point because there are two
outcomes either true or false.

Difference between white-box testing and black-box testing

Following are the significant differences between white box testing and black box testing:

White-box testing Black box testing

The developers can perform white box testing. The test engineers perform the black box testing.

To perform WBT, we should have an understanding To perform BBT, there is no need to have an understanding
of the programming languages. of the programming languages.

In this, we will look into the source code and test the In this, we will verify the functionality of the application
logic of the code. based on the requirement specification.

In this, the developer should know about the In this, there is no need to know about the internal design
internal design of the code. of the code.
 UNIT 3 : Software Testing Basics
Debugging

To launch an application into the market, it is very necessary to cross-check it multiple times so as to deliver an
error-free product.

When we talk about delivering a bug-free product, then our main concern is all about customer satisfaction because
if you are application is not up to the mark, then eventually it will demolish the company's reputation in the market.

In this article, we are going to see what makes debugging stand out of the queue and how it is different from
software testing.

We will be discussing the following topics:

o What is Debugging

o Why do we need debugging?

o Steps involved in debugging

o Debugging strategies

o Tools required to debug

What is Debugging?

In the development process of any software, the software program is religiously tested, troubleshot, and maintained
for the sake of delivering bug-free products. There is nothing that is error-free in the first go.

So, it's an obvious thing to which everyone will relate that as when the software is created, it contains a lot of errors;
the reason being nobody is perfect and getting error in the code is not an issue, but avoiding it or not preventing it, is
an issue!

All those errors and bugs are discarded regularly, so we can conclude that debugging is nothing but a process of
eradicating or fixing the errors contained in a software program.

Debugging works stepwise, starting from identifying the errors, analyzing followed by removing the errors.
Whenever a software fails to deliver the result, we need the software tester to test the application and solve it.

Since the errors are resolved at each step of debugging in the software testing, so we can conclude that it is a
tiresome and complex task regardless of how efficient the result was.

Why do we need Debugging?

Debugging gets started when we start writing the code for the software program. It progressively starts continuing in
the consecutive stages to deliver a software product because the code gets merged with several other programming
units to form a software product.
 UNIT 3 : Software Testing Basics
Following are the benefits of Debugging:

o Debugging can immediately report an error condition whenever it occurs. It prevents hampering the result
by detecting the bugs in the earlier stage, making software development stress-free and smooth.

o It offers relevant information related to the data structures that further helps in easier interpretation.

o Debugging assist the developer in reducing impractical and disrupting information.

o With debugging, the developer can easily avoid complex one-use testing code to save time and energy in
software development.

Steps involved in Debugging

Following are the different steps that are involved in debugging:

1. Identify the Error: Identifying an error in a wrong may result in the wastage of time. It is very obvious that
the production errors reported by users are hard to interpret, and sometimes the information we receive is
misleading. Thus, it is mandatory to identify the actual error.

2. Find the Error Location: Once the error is correctly discovered, you will be required to thoroughly review the
code repeatedly to locate the position of the error. In general, this step focuses on finding the error rather
than perceiving it.

3. Analyze the Error: The third step comprises error analysis, a bottom-up approach that starts from the
location of the error followed by analyzing the code. This step makes it easier to comprehend the errors.
Mainly error analysis has two significant goals, i.e., evaluation of errors all over again to find existing bugs
and postulating the uncertainty of incoming collateral damage in a fix.

4. Prove the Analysis: After analyzing the primary bugs, it is necessary to look for some extra errors that may
show up on the application. By incorporating the test framework, the fourth step is used to write automated
tests for such areas.

5. Cover Lateral Damage: The fifth phase is about accumulating all of the unit tests for the code that requires
modification. As when you run these unit tests, they must pass.

6. Fix & Validate: The last stage is the fix and validation that emphasizes fixing the bugs followed by running all
the test scripts to check whether they pass.
 UNIT 3 : Software Testing Basics
Debugging Strategies

o For a better understanding of a system, it is necessary to study the system in depth. It makes it easier for the
debugger to fabricate distinct illustrations of such systems that are needed to be debugged.

o The backward analysis analyzes the program from the backward location where the failure message has
occurred to determine the defect region. It is necessary to learn the area of defects to understand the
reason for defects.

o In the forward analysis, the program tracks the problem in the forward direction by utilizing the breakpoints
or print statements incurred at different points in the program. It emphasizes those regions where the
wrong outputs are obtained.

o To check and fix similar kinds of problems, it is recommended to utilize past experiences. The success rate of
this approach is directly proportional to the proficiency of the debugger.

Debugging Tools

The debugging tool can be understood as a computer program that is used to test and debug several other
programs. Presently, there are many public domain software such as gdb and dbx in the market, which can be
utilized for debugging. These software offers console-based command-line interfaces. Some of the automated
debugging tools include code-based tracers, profilers, interpreters, etc.

Here is a list of some of the widely used debuggers:

o Radare2

o WinDbg

o Valgrind

Radare2

Radare2 is known for its reverse engineering framework as well as binary analysis. It is made up of a small set of
utilities, either utilized altogether or independently from the command line. It is also known as r2.

It is constructed around disassembler for computer software for generating assembly language source code from
machine-executable code. It can support a wide range of executable formats for distinct architectures of processors
and operating systems.

WinDbg

WinDbg is a multipurpose debugging tool designed for Microsoft Windows operating system. This tool can be used
to debug the memory dumps created just after the Blue Screen of Death that further arises when a bug check is
issued. Besides, it is also helpful in debugging the user-mode crash dumps, which is why it is called post-mortem
debugging.

Valgrind

The Valgrind exist as a tool suite that offers several debugging and profiling tools to facilitate users in making faster
and accurate program. Memcheck is one of its most popular tools, which can successfully detect memory-related
errors caused in C and C++ programs as it may crash the program and result in unpredictable behavior.
 UNIT 4: Project Management
The Management Spectrum | 4 P’s in Software Project Planning

For properly building a product, there’s a very important concept that we all should know in software project
planning while developing a product. There are 4 critical components in software project planning which are known
as the 4P’s namely:

 Product

 Process

 People

 Project

These components play a very important role in your project that can help your team meet its goals and objective.
Now, Let’s dive into each of them a little in detail to get a better understanding:

 People
The most important component of a product and its successful implementation is human resources. In
building a proper product, a well-managed team with clear-cut roles defined for each person/team will lead
to the success of the product. We need to have a good team in order to save our time, cost, and effort. Some
assigned roles in software project planning are project manager, team leaders, stakeholders, analysts, and
other IT professionals. Managing people successfully is a tricky process which a good project manager can
do.

 Product
As the name inferred, this is the deliverable or the result of the project. The project manager should clearly
define the product scope to ensure a successful result, control the team members, as well technical hurdles
that he or she may encounter during the building of a product. The product can consist of both tangible or
intangible such as shifting the company to a new place or getting a new software in a company.
 UNIT 4: Project Management
 Process
In every planning, a clearly defined process is the key to the success of any product. It regulates how the
team will go about its development in the respective time period. The Process has several steps involved
like, documentation phase, implementation phase, deployment phase, and interaction phase.

 Project
The last and final P in software project planning is Project. It can also be considered as a blueprint of process.
In this phase, the project manager plays a critical role. They are responsible to guide the team members to
achieve the project’s target and objectives, helping & assisting them with issues, checking on cost and
budget, and making sure that the project stays on track with the given deadlines.

Short note on Project Scheduling

A schedule in your project’s time table actually consists of sequenced activities and milestones that are needed to be
delivered under a given period of time.

Project schedule simply means a mechanism that is used to communicate and know about that tasks are needed
and has to be done or performed and which organizational resources will be given or allocated to these tasks and in
what time duration or time frame work is needed to be performed. Effective project scheduling leads to success of
project, reduced cost, and increased customer satisfaction. Scheduling in project management means to list out
activities, deliverables, and milestones within a project that are delivered. It contains more notes than your average
weekly planner notes. The most common and important form of project schedule is Gantt chart.

Process :
The manager needs to estimate time and resources of project while scheduling project. All activities in project must
be arranged in a coherent sequence that means activities should be arranged in a logical and well-organized manner
for easy to understand. Initial estimates of project can be made optimistically which means estimates can be made
when all favorable things will happen and no threats or problems take place.

The total work is separated or divided into various small activities or tasks during project schedule. Then, Project
manager will decide time required for each activity or task to get completed. Even some activities are conducted and
performed in parallel for efficient performance. The project manager should be aware of fact that each stage of
project is not problem-free.

Problems arise during Project Development Stage :

 People may leave or remain absent during particular stage of development.

 Hardware may get failed while performing.

 Software resource that is required may not be available at present, etc.

 UNIT 4: Project Management
The project schedule is represented as set of chart in which work-breakdown structure and dependencies within
various activities are represented. To accomplish and complete project within a given schedule, required resources
must be available when they are needed. Therefore, resource estimation should be done before starting
development.

Resources required for Development of Project :

 Human effort

 Sufficient disk space on server

 Specialized hardware

 Software technology

 Travel allowance required by project staff, etc.

Advantages of Project Scheduling :

There are several advantages provided by project schedule in our project management:

 It simply ensures that everyone remains on same page as far as tasks get completed, dependencies, and
deadlines.

 It helps in identifying issues early and concerns such as lack or unavailability of resources.

 It also helps to identify relationships and to monitor process.

 It provides effective budget management and risk mitigation.

Short note on Reactive and Proactive RCA

Root Cause Analysis (RCA) is one of the best methods to identify main cause or root cause of problems or events in
very systematic way or process. RCA is based on the idea that for effective management, we need to find out way to
prevent arising or occurring problems.

Each one needs to understand that if they want to solve or eliminate any problem, it is essential to go to the root
cause of the problem and then eliminate problems so that they can reduce or control the reoccurrence of the
problem. For organizations that want to improve and grow continuously, it is very essential to identify the root cause
although it is tough to do so, it is essential. RCA can also be used to modify or change core processes and issues in
such way that prevents future problems.

Reactive and Proactive RCA :

The main question that arises is whether RCA is reactive or proactive? Some people think that RCA is only required
to solve problems or failures that have already occurred. But, it’s not true. One should know that RCA can be both
i.e. reactive and proactive as given below –
 UNIT 4: Project Management
1. Reactive RCA :
The main question that arises in reactive RCA is “What went wrong?”. Before investigating or identifying the root
cause of failure or defect, failure needs to be in place or should be occurred already. One can only identify the root
cause and perform the analysis only when problem or failure had occurred that causes malfunctioning in the system.
Reactive RCA is a root cause analysis that is performed after the occurrence of failure or defect.

It is simply done to control, implemented to reduce the impact and severity of defect that has occurred. It is also
known as reactive risk management. It reacts quickly as soon as problem occurs by simply treating symptoms. RCA is
generally reactive but it has the potential to be proactive. RCA is reactive at initial and it can only be proactive if one
addresses and identifies small things too that can cause problem as well as exposes hidden causes of the problem.

Advantages :

 Helps one to prioritize tasks according to its severity and then resolve it.

 Increases teamwork and their knowledge.

Disadvantages :

 Sometimes, resolving equipment after failure can be more costly than preventing failure from an
occurrence.

 Failed equipment can cause greater damage to system and interrupts production activities.

2. Proactive RCA :
The main question that arises in proactive RCA is “What could go wrong?”. RCA can also be used proactively to
mitigate failure or risk. The main importance of RCA can be seen when it is applied to events that have not occurred
yet. Proactive RCA is a root cause analysis that is performed before any occurrence of failure or defect. It is simply
done to control, implemented to prevent defect from its occurrence. As both reactive and proactive RCAs are is
important, one should move from reactive to proactive RCA.

It is better to prevent issues from its occurrence rather than correcting it after its occurrence. In simple words,
Prevention is better than correction. Here, prevention action is considered as proactive and corrective action is
considered as reactive. It is also known as proactive risk management. It identifies the root cause of problem to
eliminate it from reoccurring. With help of proactive RCA, we can identify the main root cause that leads to the
occurrence of problem or failure, or defect. After knowing this, we can take various measures and implement actions
to prevent these causes from the occurrence.

Advantages :

 Future chances of failure occurrence can be minimized.

 Reduce overall cost required to resolve failure by simply preventing failure from an occurrence.

 Increases overall productivity by minimizing chances of interruption due to failure.

Disadvantages :

 Sometimes, preventing equipment from failure can be more costly than resolving failure after occurrence.

 Many resources and tools required to prevent failure from an occurrence that can affect the overall cost.

 Requires highly skilled technicians to perform maintenance tasks.

 UNIT 4: Project Management
System configuration management – Software Engineering

Whenever software is built, there is always scope for improvement and those improvements bring changes in
picture. Changes may be required to modify or update any existing solution or to create a new solution for a
problem. Requirements keep on changing on a daily basis so we need to keep on upgrading our systems based on
the current requirements and needs to meet desired outputs. Changes should be analyzed before they are made to
the existing system, recorded before they are implemented, reported to have details of before and after, and
controlled in a manner that will improve quality and reduce error. This is where the need for System Configuration
Management comes. System Configuration Management (SCM) is an arrangement of exercises that controls change
by recognizing the items for change, setting up connections between those things, making/characterizing
instruments for overseeing diverse variants, controlling the changes being executed in the current framework,
inspecting and revealing/reporting on the changes made. It is essential to control the changes in light of the fact that
if the changes are not checked legitimately then they may wind up undermining a well-run programming. In this
way, SCM is a fundamental piece of all project management activities. Processes involved in SCM – Configuration
management provides a disciplined environment for smooth control of work products. It involves the following
activities:

1. Identification and Establishment – Identifying the configuration items from products that compose
baselines at given points in time (a baseline is a set of mutually consistent Configuration Items, which has
been formally reviewed and agreed upon, and serves as the basis of further development). Establishing
relationships among items, creating a mechanism to manage multiple levels of control and procedure for the
change management system.

2. Version control – Creating versions/specifications of the existing product to build new products with the
help of the SCM system. A description of the version is given below:
 UNIT 4: Project Management
3. Suppose after some changes, the version of configuration object changes from 1.0 to 1.1. Minor corrections
and changes result in versions 1.1.1 and 1.1.2, which is followed by a major update that is object 1.2. The
development of object 1.0 continues through 1.3 and 1.4, but finally, a noteworthy change to the object
results in a new evolutionary path, version 2.0. Both versions are currently supported.

4. Change control – Controlling changes to Configuration items (CI). The change control process is explained in
Figure below:

A
change request (CR) is submitted and evaluated to assess technical merit, potential side effects, overall
impact on other configuration objects and system functions, and the projected cost of the change. The
results of the evaluation are presented as a change report, which is used by a change control board (CCB) —
a person or group who makes a final decision on the status and priority of the change. An engineering
change Request (ECR) is generated for each approved change. Also CCB notifies the developer in case the
change is rejected with proper reason. The ECR describes the change to be made, the constraints that must
be respected, and the criteria for review and audit. The object to be changed is “checked out” of the project
database, the change is made, and then the object is tested again. The object is then “checked in” to the
database and appropriate version control mechanisms are used to create the next version of the software.
 UNIT 4: Project Management
5. Configuration auditing – A software configuration audit complements the formal technical review of the
process and product. It focuses on the technical correctness of the configuration object that has been
modified. The audit confirms the completeness, correctness and consistency of items in the SCM system and
track action items from the audit to closure.

5. Reporting – Providing accurate status and current configuration data to developers, tester, end users,
customers and stakeholders through admin guides, user guides, FAQs, Release notes, Memos, Installation
Guide, Configuration guide etc .

System Configuration Management (SCM) is a software engineering practice that focuses on managing the
configuration of software systems and ensuring that software components are properly controlled, tracked, and
stored. It is a critical aspect of software development, as it helps to ensure that changes made to a software system
are properly coordinated and that the system is always in a known and stable state.

SCM involves a set of processes and tools that help to manage the different components of a software system,
including source code, documentation, and other assets. It enables teams to track changes made to the software
system, identify when and why changes were made, and manage the integration of these changes into the final
product.

The key objectives of SCM are to:

1. Control the evolution of software systems: SCM helps to ensure that changes to a software system are
properly planned, tested, and integrated into the final product.

2. Enable collaboration and coordination: SCM helps teams to collaborate and coordinate their work, ensuring
that changes are properly integrated and that everyone is working from the same version of the software
system.

3. Provide version control: SCM provides version control for software systems, enabling teams to manage and
track different versions of the system and to revert to earlier versions if necessary.

4. Facilitate replication and distribution: SCM helps to ensure that software systems can be easily replicated
and distributed to other environments, such as test, production, and customer sites.

5. SCM is a critical component of software development, and effective SCM practices can help to improve the
quality and reliability of software systems, as well as increase efficiency and reduce the risk of errors.

The main advantages of SCM are:

1. Improved productivity and efficiency by reducing the time and effort required to manage software changes.

2. Reduced risk of errors and defects by ensuring that all changes are properly tested and validated.

3. Increased collaboration and communication among team members by providing a central repository for
software artifacts.

4. Improved quality and stability of software systems by ensuring that all changes are properly controlled and
managed.

Cleanroom Testing – Software Engineering

Cleanroom Testing was pioneered by IBM. This kind of testing depends heavily on walkthroughs, inspection, and
formal verification. The programmers don’t seem to be allowed to check any of their code by corporal punishment
the code apart from doing a little syntax testing employing a compiler. The computer code development philosophy
relies on avoiding computer code defects by employing a rigorous examination method. the target of this computer
code is that of the zero-defect computer code.
 UNIT 4: Project Management
What is Cleanroom Testing?

The name ‘CLEAN ROOM’ was derived from the analogy with semiconductor fabrication units. In these units (clean
rooms), defects area unit avoided by producing within the ultra-clean atmosphere.

1. During this reasonable development, inspections to ascertain the consistency of the parts with their
specifications have replaced unit testing.

2. This technique reportedly produces documentation and code that’s extra reliable and fixable than various
development methods relying heavily on code execution-based testing.

Objectives of Cleanroom Testing

1. Defect Prevention: Software requirements and design are mathematically specified through the use of
formal methods. By using incremental development, errors are found and fixed early in the software
development lifecycle, stopping them from spreading to later stages.

2. Verification and Validation: It places a strong emphasis on both validation and verification. Validation
verifies that the program fulfills user needs and expectations, while verification uses formal methodologies
and thorough inspections to ensure that the product fits its stated criteria.

3. Improvement and Control of Processes: The strategy involves controlling the software development process
through quantitative management that makes use of metrics and statistical methods. One of the main
principles is continuous improvement, which focuses on finding and improving opportunities for
improvement through data-driven decision-making.

4. Customer satisfaction: End users participate in the cleanroom testing process to make sure the software
meets their needs.

5. Cost-Effective Quality Assurance: To identify cost-effective strategies for producing high-quality software,
cleanroom testing integrates cost-benefit assessments.

Characteristics of the Cleanroom Testing

1. Formal specification: The computer code to be developed is formally given. A state-transition model that
shows system responses to stimuli is employed to precise the specification.

2. Incremental development: The computer code is partitioned off into increments that area unit developed
and valid on an individual basis mistreatment the white room method. These increments area unit given,
with client input, as Associate in Nursing early stage within the method.

3. Structured programming: Only a restricted range of management and information abstraction constructs
area units are used. The program development method is the method of stepwise refinement of the
specification.

4. Static verification: The developed computer code is statically verified in mistreatment rigorous computer
code inspections. there’s no unit or module testing method for code parts.

5. Statistical testing of the system: The integrated computer code increment is tested statistically to work out
its responsibility. These applied mathematics tests area unit supported the operational profile that is
developed in parallel with the system specification.
 UNIT 5: Software Quality Management& Estimation
Software Quality – Software Engineering

Traditionally, a high-quality product is outlined in terms of its fitness of purpose. That is, a high-quality product will
specifically be what the users need to try. For code merchandise, the fitness of purpose is typically taken in terms of
satisfaction of the wants arranged down within the SRS document. Though “fitness of purpose” could be a
satisfactory definition of quality for some merchandise like an automobile, a table fan, a grinding machine, etc. – for
code merchandise, “fitness of purpose” isn’t a completely satisfactory definition of quality.

What is Software Quality?

Software Quality shows how good and reliable a product is. To convey an associate degree example, think about
functionally correct software. It performs all functions as laid out in the SRS document. But, it has an associate
degree virtually unusable program. even though it should be functionally correct, we tend not to think about it to be
a high-quality product.

Another example is also that of a product that will have everything that the users need but has an associate degree
virtually incomprehensible and not maintainable code. Therefore, the normal construct of quality as “fitness of
purpose” for code merchandise isn’t satisfactory.

Factors of Software Quality

The modern read of high-quality associates with software many quality factors like the following:

1. Portability: A software is claimed to be transportable, if it may be simply created to figure in several package
environments, in several machines, with alternative code merchandise, etc.

2. Usability: A software has smart usability if completely different classes of users (i.e. knowledgeable and
novice users) will simply invoke the functions of the merchandise.

3. Reusability: A software has smart reusability if completely different modules of the merchandise will simply
be reused to develop new merchandise.

4. Correctness: Software is correct if completely different needs as laid out in the SRS document are properly
enforced.

5. Maintainability: A software is reparable, if errors may be simply corrected as and once they show up, new
functions may be simply added to the merchandise, and therefore the functionalities of the merchandise
may be simply changed, etc

6. Reliability. Software is more reliable if it has fewer failures. Since software engineers do not deliberately
plan for their software to fail, reliability depends on the number and type of mistakes they make. Designers
can improve reliability by ensuring the software is easy to implement and change, by testing it thoroughly,
and also by ensuring that if failures occur, the system can handle them or can recover easily.

7. Efficiency. The more efficient software is, the less it uses of CPU-time, memory, disk space, network
bandwidth, and other resources. This is important to customers in order to reduce their costs of running the
software, although with today’s powerful computers, CPU time, memory and disk usage are less of a concern
than in years gone by.

Software Quality Management System

Software Quality Management System contains the methods that are used by the authorities to develop products
having the desired quality.

Managerial Structure

Quality System is responsible for managing the structure as a whole. Every Organization has a managerial structure.
 UNIT 5: Software Quality Management& Estimation
Individual Responsibilities

Each individual present in the organization must have some responsibilities that should be reviewed by the top
management and each individual present in the system must take this seriously.

Quality System Activities

The activities which each quality system must have been

1. Project Auditing.

2. Review of the quality system.

3. It helps in the development of methods and guidelines.

Evolution of Quality Management System

Quality Systems are basically evolved over the past some years. The evolution of a Quality Management System is a
four-step process.

1. The main task of quality control is to detect defective devices, and it also helps in finding the cause that leads
to the defect. It also helps in the correction of bugs.

2. Quality Assurance helps an organization in making good quality products. It also helps in improving the
quality of the product by passing the products through security checks.

3. Total Quality Management(TQM) checks and assures that all the procedures must be continuously improved
regularly through process measurements.
 UNIT 5: Software Quality Management& Estimation
Evolution of Quality Management System

Software Quality Assurance – Software Engineering

Software Quality Assurance (SQA) is simply a way to assure quality in the software. It is the set of activities which
ensure processes, procedures as well as standards are suitable for the project and implemented correctly.

Software Quality Assurance is a process which works parallel to development of software. It focuses on improving
the process of development of software so that problems can be prevented before they become a major issue.
Software Quality Assurance is a kind of Umbrella activity that is applied throughout the software process.

Generally, the quality of the software is verified by the third-party organization like international standard
organizations.

Software Quality Assurance (SQA) encompasses

 SQA process

 specific quality assurance and quality control tasks (including technical reviews and a multitiered testing
strategy)

 effective software engineering practice (methods and tools)

 control of all software work products and the changes made to them

 a procedure to ensure compliance with software development standards (when applicable)

 measurement and reporting mechanisms

Elements Of Software Quality Assurance:

1. Standards: The IEEE, ISO, and other standards organizations have produced a broad array of software
engineering standards and related documents. The job of SQA is to ensure that standards that have been
adopted are followed, and all work products conform to them.

2. Reviews and audits: Technical reviews are a quality control activity performed by software engineers for
software engineers. Their intent is to uncover errors. Audits are a type of review performed by SQA
personnel (people employed in an organization) with the intent of ensuring that quality guidelines are being
followed for software engineering work.

3. Testing: Software testing is a quality control function that has one primary goal—to find errors. The job of
SQA is to ensure that testing is properly planned and efficiently conducted for primary goal of software.

4. Error/defect collection and analysis: SQA collects and analyzes error and defect data to better understand
how errors are introduced and what software engineering activities are best suited to eliminating them.

5. Change management: SQA ensures that adequate change management practices have been instituted.

6. Education: Every software organization wants to improve its software engineering practices. A key
contributor to improvement is education of software engineers, their managers, and other stakeholders. The
SQA organization takes the lead in software process improvement which is key proponent and sponsor of
educational programs.

7. Security management: SQA ensures that appropriate process and technology are used to achieve software
security.

8. Safety: SQA may be responsible for assessing the impact of software failure and for initiating those steps
required to reduce risk.

9. Risk management: The SQA organization ensures that risk management activities are properly conducted
and that risk-related contingency plans have been established.
 UNIT 5: Software Quality Management& Estimation
Software quality assurance focuses on:

 software’s portability

 software’s usability

 software’s reusability

 software’s correctness

 software’s maintainability

 software’s error control

Software Quality Assurance has:

1. A quality management approach

2. Formal technical reviews

3. Multi testing strategy

4. Effective software engineering technology

5. Measurement and reporting mechanism

Major Software Quality Assurance Activities:

1. SQA Management Plan: Make a plan for how you will carry out the SQA throughout the project. Think about
which set of software engineering activities are the best for project. check level of SQA team skills.

2. Set The Check Points: SQA team should set checkpoints. Evaluate the performance of the project on the
basis of collected data on different check points.

3. Measure Change Impact: The changes for making the correction of an error sometimes re introduces more
errors keep the measure of impact of change on project. Reset the new change to check the compatibility of
this fix with whole project.

4. Multi testing Strategy: Do not depend on a single testing approach. When you have a lot of testing
approaches available use them.

5. Manage Good Relations: In the working environment managing good relations with other teams involved in
the project development is mandatory. Bad relation of SQA team with programmers team will impact
directly and badly on project. Don’t play politics.

6. Managing Reports and Records: Document and share QA activities (test cases, defects, client changes) for
future reference and stakeholder alignment.

Benefits of Software Quality Assurance (SQA):

1. SQA produces high quality software.

2. High quality application saves time and cost.

3. SQA is beneficial for better reliability.

4. SQA is beneficial in the condition of no maintenance for a long time.

5. High quality commercial software increase market share of company.

6. Improving the process of creating software.

7. Improves the quality of the software.

 UNIT 5: Software Quality Management& Estimation
8. It cuts maintenance costs. Get the release right the first time, and your company can forget about it and
move on to the next big thing. Release a product with chronic issues, and your business bogs down in a
costly, time-consuming, never-ending cycle of repairs.

Disadvantage of SQA:

There are a number of disadvantages of quality assurance. Some of them include adding more resources, employing
more workers to help maintain quality and so much more.

Software Quality Assurance

What is Quality?

Quality defines to any measurable characteristics such as correctness, maintainability, portability, testability,
usability, reliability, efficiency, integrity, reusability, and interoperability.

There are two kinds of Quality:

Quality of Design: Quality of Design refers to the characteristics that designers specify for an item. The grade of
materials, tolerances, and performance specifications that all contribute to the quality of design.

Quality of conformance: Quality of conformance is the degree to which the design specifications are followed during
manufacturing. Greater the degree of conformance, the higher is the level of quality of conformance.

Backward Skip 10sPlay VideoForward Skip 10s

Software Quality: Software Quality is defined as the conformance to explicitly state functional and performance
requirements, explicitly documented development standards, and inherent characteristics that are expected of all
professionally developed software.

Quality Control: Quality Control involves a series of inspections, reviews, and tests used throughout the software
process to ensure each work product meets the requirements place upon it. Quality control includes a feedback loop
to the process that created the work product.

Quality Assurance: Quality Assurance is the preventive set of activities that provide greater confidence that the
project will be completed successfully.

Quality Assurance focuses on how the engineering and management activity will be done?

As anyone is interested in the quality of the final product, it should be assured that we are building the right product.

It can be assured only when we do inspection & review of intermediate products, if there are any bugs, then it is
debugged. This quality can be enhanced.

Importance of Quality

We would expect the quality to be a concern of all producers of goods and services. However, the distinctive
characteristics of software and in particular its intangibility and complexity, make special demands.
 UNIT 5: Software Quality Management& Estimation
Increasing criticality of software: The final customer or user is naturally concerned about the general quality of
software, especially its reliability. This is increasing in the case as organizations become more dependent on their
computer systems and software is used more and more in safety-critical areas. For example, to control aircraft.

The intangibility of software: This makes it challenging to know that a particular task in a project has been
completed satisfactorily. The results of these tasks can be made tangible by demanding that the developers produce
'deliverables' that can be examined for quality.

Accumulating errors during software development: As computer system development is made up of several steps
where the output from one level is input to the next, the errors in the earlier ?deliverables? will be added to those in
the later stages leading to accumulated determinable effects. In general the later in a project that an error is found,
the more expensive it will be to fix. In addition, because the number of errors in the system is unknown, the
debugging phases of a project are particularly challenging to control.

Software Quality Assurance

Software quality assurance is a planned and systematic plan of all actions necessary to provide adequate confidence
that an item or product conforms to establish technical requirements.

A set of activities designed to calculate the process by which the products are developed or manufactured.

SQA Encompasses

ADVERTISEMENT

ADVERTISEMENT

o A quality management approach

o Effective Software engineering technology (methods and tools)

o Formal technical reviews that are tested throughout the software process

o A multitier testing strategy

o Control of software documentation and the changes made to it.

o A procedure to ensure compliances with software development standards

o Measuring and reporting mechanisms.

ADVERTISEMENT

SQA Activities

Software quality assurance is composed of a variety of functions associated with two different constituencies ? the
software engineers who do technical work and an SQA group that has responsibility for quality assurance planning,
record keeping, analysis, and reporting.

ADVERTISEMENT

Following activities are performed by an independent SQA group:

1. Prepares an SQA plan for a project: The program is developed during project planning and is reviewed by all
stakeholders. The plan governs quality assurance activities performed by the software engineering team and
the SQA group. The plan identifies calculation to be performed, audits and reviews to be performed,
standards that apply to the project, techniques for error reporting and tracking, documents to be produced
by the SQA team, and amount of feedback provided to the software project team.

2. Participates in the development of the project's software process description: The software team selects a
process for the work to be performed. The SQA group reviews the process description for compliance with
 UNIT 5: Software Quality Management& Estimation
organizational policy, internal software standards, externally imposed standards (e.g. ISO-9001), and other
parts of the software project plan.

3. Reviews software engineering activities to verify compliance with the defined software process: The SQA
group identifies, reports, and tracks deviations from the process and verifies that corrections have been
made.

4. Audits designated software work products to verify compliance with those defined as a part of the
software process: The SQA group reviews selected work products, identifies, documents and tracks
deviations, verify that corrections have been made, and periodically reports the results of its work to the
project manager.

5. Ensures that deviations in software work and work products are documented and handled according to a
documented procedure: Deviations may be encountered in the project method, process description,
applicable standards, or technical work products.

6. Records any noncompliance and reports to senior management: Non- compliance items are tracked until
they are resolved.

Quality Assurance v/s Quality control

Quality Assurance Quality Control

Quality Assurance (QA) is the set of actions including Quality Control (QC) is described as the processes
facilitation, training, measurement, and analysis needed to and methods used to compare product quality to
provide adequate confidence that processes are established requirements and applicable standards, and the
and continuously improved to produce products or services actions are taken when a nonconformance is
that conform to specifications and are fit for use. detected.

QA is an activity that establishes and calculates the processes QC is an activity that demonstrates whether or not
that produce the product. If there is no process, there is no the product produced met standards.
role for QA.

QA helps establish process QC relates to a particular product or service

QA sets up a measurement program to evaluate processes QC verified whether particular attributes exist, or
do not exist, in a explicit product or service.

QA identifies weakness in processes and improves them QC identifies defects for the primary goals of
correcting errors.

Quality Assurance is a managerial tool. Quality Control is a corrective tool.

Verification is an example of QA. Validation is an example of QC.

 UNIT 5: Software Quality Management& Estimation
Six Sigma in Software Engineering

Six Sigma is the process of producing high and improved quality output. This can be done in two phases –
identification and elimination. The cause of defects is identified and appropriate elimination is done which reduces
variation in whole processes. A six sigma method is one in which 99.99966% of all the products to be produced have
the same features and are of free from defects.

Characteristics of Six Sigma:

The Characteristics of Six Sigma are as follows:

1. Statistical Quality Control:

Six Sigma is derived from the Greek Letter ? which denote Standard Deviation in statistics. Standard
Deviation is used for measuring the quality of output.

2. Methodical Approach:
The Six Sigma is a systematic approach of application in DMAIC and DMADV which can be used to improve
the quality of production. DMAIC means for Design-Measure- Analyze-Improve-Control. While DMADV
stands for Design-Measure-Analyze-Design-Verify.

3. Fact and Data-Based Approach:

The statistical and methodical method shows the scientific basis of the technique.
 UNIT 5: Software Quality Management& Estimation

4. Project and Objective-Based Focus:

The Six Sigma process is implemented to focus on the requirements and conditions.

5. Customer Focus:
The customer focus is fundamental to the Six Sigma approach. The quality improvement and control
standards are based on specific customer requirements.

6. Teamwork Approach to Quality Management:

The Six Sigma process requires organizations to get organized for improving quality.

Six Sigma Methodologies:

Two methodologies used in the Six Sigma projects are DMAIC and DMADV.

 DMAIC is used to enhance an existing business process. The DMAIC project methodology has five phases:

1. Define

2. Measure

3. Analyze

4. Improve

5. Control
 UNIT 5: Software Quality Management& Estimation
 DMADV is used to create new product designs or process designs. The DMADV project methodology also has
five phases:

1. Define

2. Measure

3. Analyze

4. Design

5. Verify

Software Engineering – Hardware Reliability vs Software Reliability

Reliability in software is software that has no failure and works in a special time period with a special environment.
Hardware reliability is the probability of the absence of any hardware-related system malfunction for a given mission
on the other hand software reliability is the probability that the software will provide a failure-free operation in a
fixed environment for a fixed interval of time. The article focuses on discussing the difference between Hardware
Reliability and Software Reliability.

Hardware Reliability

Hardware reliability is the probability that the ability of the hardware to perform its function for some period of
time. It may change during certain periods such as initial burn-in or the end of useful life.

 It is expressed as Mean Time Between Failures (MBTF).

 Hardware faults are mostly physical faults.

 Thorough testing of all components cuts down on the number of faults.

 Hardware failures are mostly due to wear and tear.

 It follows the Bathtub curve principle for testing failure.

 UNIT 5: Software Quality Management& Estimation

Software Reliability

Software reliability is the probability that the software will operate failure-free for a specific period of time in a
specific environment. It is measured per some unit of time.

 Software Reliability starts with many faults in the system when first created.

 After testing and debugging enter a useful life cycle.

 Useful life includes upgrades made to the system which bring about new faults.

 The system needs to then be tested to reduce faults.

 Software reliability cannot be predicted from any physical basis, since it depends completely on the human
factors in design.
 UNIT 5: Software Quality Management& Estimation
Hardware Reliability vs Software Reliability

Features Hardware Reliability Software Reliability

Failures are caused due to defects in design, Failures are caused due to defects in
Source of Failure production, and maintenance. design.

Failure occurs due to physical deterioration in In software reliability, there is no wear

Wear and Tear wear and tear. and tear.

Deterioration In this prior deterioration warning about In this no prior deterioration warning
Warning failure. about failure.

The bathtub curve is used for failure rates There is no Bathtub curve for failure
Failure Curve apply. rates.

Is Failure Time-
In this failures are time-dependent. In this failures are not time-dependent.
dependent?

In this reliability can not be predicted

In this reliability can be predicted from design.
Reliability Prediction from design.

Reliability The complexity of hardware reliability is very The complexity of software reliability is
Complexity high. low.

External Hardware reliability is related to External environment conditions do not

Environment Impact environmental conditions. affect software reliability.

Reliability Reliability can’t be improved through Reliability can be improved through

Improvement redundant of hardware. redundancy of software.

Repairs can be made that make hardware No equivalent preventive maintenance

Maintenance more reliable through maintenance. for software.
 UNIT 5: Software Quality Management& Estimation
ISO 9000 Certification in Software Engineering

The International organization for Standardization is a world wide federation of national standard bodies.
The International standards organization (ISO) is a standard which serves as a for contract between independent
parties. It specifies guidelines for development of quality system.

Quality system of an organization means the various activities related to its products or services. Standard of ISO
addresses to both aspects i.e. operational and organizational aspects which includes responsibilities, reporting etc.
An ISO 9000 standard contains set of guidelines of production process without considering product itself.

ISO 9000 Certification

Why ISO Certification required by Software Industry?

There are several reasons why software industry must get an ISO certification. Some of reasons are as follows :

 This certification has become a standards for international bidding.

 It helps in designing high-quality repeatable software products.

 It emphasis need for proper documentation.

 It facilitates development of optimal processes and totally quality measurements.

Features of ISO 9001 Requirements :

 Document control –
All documents concerned with the development of a software product should be properly managed and
controlled.

 Planning –
Proper plans should be prepared and monitored.

 Review –
For effectiveness and correctness all important documents across all phases should be independently
checked and reviewed .

 Testing –
The product should be tested against specification.

 Organizational Aspects –
Various organizational aspects should be addressed e.g., management reporting of the quality team.
 UNIT 5: Software Quality Management& Estimation
Advantages of ISO 9000 Certification :
Some of the advantages of the ISO 9000 certification process are following :

 Business ISO-9000 certification forces a corporation to specialize in “how they are doing business”. Each
procedure and work instruction must be documented and thus becomes a springboard for continuous
improvement.

 Employees morale is increased as they’re asked to require control of their processes and document their
work processes

 Better products and services result from continuous improvement process.

 Increased employee participation, involvement, awareness and systematic employee training are reduced
problems.

Shortcomings of ISO 9000 Certification :

Some of the shortcoming of the ISO 9000 certification process are following :

 ISO 9000 does not give any guideline for defining an appropriate process and does not give guarantee for
high quality process.

 ISO 9000 certification process have no international accreditation agency exists.

McCall’s Quality Model

McCall’s Software Quality Model was introduced in 1977. This model is incorporated with many attributes, termed
as software factors, which influence software. The model distinguishes between two levels of quality attributes:

 Quality Factors

 Quality Criteria

Quality Factors: The higher-level quality attributes which can be accessed directly are called quality factors. These
attributes are external attributes. The attributes at this level are given more importance by the users and managers.

Quality Criteria: The lower or second-level quality attributes that can be accessed either subjectively or objectively
are called Quality Criteria. These attributes are internal attributes. Each quality factor has many second-level of
quality attributes or quality criteria.

Example: The usability quality factor is divided into operability, training, communicativeness, input/output volume,
and input/output rate. This model classifies all software requirements into 11 software quality factors. The 11
factors are organized into three product quality factors: Product Operation, Product Revision, and Product
Transition.

Factors of Product Quality

Below are the factors of Product Quality, that are discussed in detail.

Product Operation

It includes five software quality factors, which are related to the requirements that directly affect the operation of
the software such as operational performance, convenience, ease of usage, and correctness. These factors help in
providing a better user experience.

 Correctness: The extent to which software meets its requirements specification.

 Efficiency: The number of hardware resources and code the software, needs to perform a function.

 Integrity: The extent to which the software can control an unauthorized person from accessing the data or
software.
 UNIT 5: Software Quality Management& Estimation
 Reliability: The extent to which software performs its intended functions without failure.

 Usability: The extent of effort required to learn, operate and understand the functions of the software.

Product Revision

It includes three software quality factors, which are required for testing and maintenance of the software. They
provide ease of maintenance, flexibility, and testing effort to support the software to be functional according to the
needs and requirements of the user in the future.

 Maintainability: The effort required to detect and correct an error during the maintenance phase.

 Flexibility: The effort needed to improve an operational software program.

 Testability: The effort required to verify software to ensure that it meets the specified requirements.

Product Transition

It includes three software quality factors, that allow the software to adapt to the change of environments in the new
platform or technology from the previous.

 Portability: The effort required to transfer a program from one platform to another.

 Re-usability: The extent to which the program’s code can be reused in other applications.

 Interoperability: The effort required to integrate two systems with one another.

Cost Estimation Models in Software Engineering

Cost estimation

simply means a technique that is used to find out the cost estimates. The cost estimate is the financial spend that is
done on the efforts to develop and test software in

Software Engineering

. Cost estimation models are some mathematical algorithms or parametric equations that are used to estimate the
cost of a product or a project. Various techniques or models are available for cost estimation, also known as Cost
Estimation Models as shown below :

1. Empirical Estimation Technique – Empirical estimation is a technique or model in which empirically derived
formulas are used for predicting the data that are a required and essential part of the software project
planning step. These techniques are usually based on the data that is collected previously from a project and
also based on some guesses, prior experience with the development of similar types of projects, and
assumptions. It uses the size of the software to estimate the effort. In this technique, an educated guess of
project parameters is made. Hence, these models are based on common sense. However, as there are many
activities involved in empirical estimation techniques, this technique is formalized. For example Delphi
technique and Expert Judgement technique.
 UNIT 5: Software Quality Management& Estimation
2. Heuristic Technique – Heuristic word is derived from a Greek word that means “to discover”. The heuristic
technique is a technique or model that is used for solving problems, learning, or discovery in the practical
methods which are used for achieving immediate goals. These techniques are flexible and simple for taking
quick decisions through shortcuts and good enough calculations, most probably when working with complex
data. But the decisions that are made using this technique are necessary to be optimal. In this technique, the
relationship among different project parameters is expressed using mathematical equations. The popular
heuristic technique is given by Constructive Cost Model (COCOMO). This technique is also used to increase
or speed up the analysis and investment decisions.

3. Analytical Estimation Technique – Analytical estimation is a type of technique that is used to measure work.
In this technique, firstly the task is divided or broken down into its basic component operations or elements
for analyzing. Second, if the standard time is available from some other source, then these sources are
applied to each element or component of work. Third, if there is no such time available, then the work is
estimated based on the experience of the work. In this technique, results are derived by making certain basic
assumptions about the project. Hence, the analytical estimation technique has some scientific
basis. Halstead’s software science is based on an analytical estimation model.

Other Cost Estimation Models are:

1. Function Point Analysis (FPA): This technique counts the number and complexity of functions that a piece of
software can perform to determine how functional and sophisticated it is. The effort needed for
development, testing and maintenance can be estimated using this model.

2. Putnam Model: This model is a parametric estimation model that estimates effort, time and faults by taking
into account the size of the the programme, the expertise of the development team and other project-
specific characteristics.

3. Price-to-Win Estimation: Often utilized in competitive bidding, this model is concerned with projecting the
expenses associated with developing a particular software project in order to secure a contract. It involves
looking at market dynamics and competitors.

4. Models Based on Machine Learning: Custom cost estimating models can be built using machine learning
techniques including neural networks, regression analysis and decision trees. These models are based on
past project data. These models are flexible enough to adjust to changing data and project-specific features.

5. Function Points Model (IFPUG): A standardized technique for gauging the functionality of software using
function points is offered by the International Function Point Users Group (IFPUG). It is employed to
calculate the effort required for software development and maintenance.

What is Project Plan?

Once a project is found to be possible, computer code project managers undertake project design. Project designing
is undertaken and completed even before any development activity starts. Project designing consists of subsequent
essential activities: Estimating the subsequent attributes of the project:

 Project size: What’s going to be the downside quality in terms of the trouble and time needed to develop
the product?

 Cost: What proportion is it reaching to value to develop the project?

 Duration: How long is it to reach design plate amended development?

 Effort: What proportion of effort would be required?

The effectiveness of the following design activities relies on the accuracy of those estimations.

 planning force and alternative resources

 workers organization and staffing plans

 UNIT 5: Software Quality Management& Estimation
 Risk identification, analysis, and abatement designing

 Miscellaneous arrangements like quality assurance plans, configuration, management arrangements, etc.

Precedence ordering among project planning activities:

The different project-connected estimates done by a project manager have already been mentioned. The below
diagram shows the order in which vital project coming up with activities is also undertaken. It may be simply
discovered that size estimation is the 1st activity. It’s conjointly the foremost basic parameter supported that all
alternative coming up with activities square measure dispensed, alternative estimations like the estimation of effort,
cost, resource, and project length also are vital elements of the project coming up with.

Sliding Window Planning:

Project designing needs utmost care and a spotlight since commitment to unrealistic time and resource estimates
ends in schedule slippage. Schedule delays will cause client discontent and adversely affect team morale. It will even
cause project failure. However, project designing could be a difficult activity. particularly for giant comes, it’s pretty
much troublesome to create correct plans. A region of this issue is thanks to the fact that the correct parameters,
the scope of the project, project workers, etc. might be amended throughout the project. So as to beat this
drawback, generally project managers undertake project design little by little. Designing a project over a variety of
stages protects managers from creating huge commitments too early. This method of staggered designing is thought
of as window designing. Within the window technique, beginning with the associate initial setup, the project is
planned additional accurately in sequential development stages. At the beginning of a project, project managers
have incomplete information concerning the main points of the project. Their info base step by step improves
because the project progresses through completely different phases. When the completion of each section, the
project managers will set up every ulterior section accurately and with increasing levels of confidence.

Types of Feasibility Study in Software Project Development

Feasibility Study in Software Engineering is a study to evaluate feasibility of proposed project or system. Feasibility
study is one of stage among important four stages of Software Project Management Process. As name suggests
feasibility study is the feasibility analysis or it is a measure of the software product in terms of how much beneficial
product development will be for the organization in a practical point of view. Feasibility study is carried out based on
many purposes to analyze whether software product will be right in terms of development, implantation,
contribution of project to the organization etc.

Types of Feasibility Study

The feasibility study mainly concentrates on below five mentioned areas. Among these Economic Feasibility Study is
most important part of the feasibility analysis and Legal Feasibility Study is less considered feasibility analysis.
 UNIT 5: Software Quality Management& Estimation
1. Technical Feasibility: In Technical Feasibility current resources both hardware software along with required
technology are analyzed/assessed to develop project. This technical feasibility study gives report whether
there exists correct required resources and technologies which will be used for project development. Along
with this, feasibility study also analyzes technical skills and capabilities of technical team, existing technology
can be used or not, maintenance and up-gradation is easy or not for chosen technology etc.

2. Operational Feasibility: In Operational Feasibility degree of providing service to requirements is analyzed

along with how much easy product will be to operate and maintenance after deployment. Along with this
other operational scopes are determining usability of product, Determining suggested solution by software
development team is acceptable or not etc.

3. Economic Feasibility: In Economic Feasibility study cost and benefit of the project is analyzed. Means under
this feasibility study a detail analysis is carried out what will be cost of the project for development which
includes all required cost for final development like hardware and software resource required, design and
development cost and operational cost and so on. After that it is analyzed whether project will be beneficial
in terms of finance for organization or not.

4. Legal Feasibility: In Legal Feasibility study project is analyzed in legality point of view. This includes analyzing
barriers of legal implementation of project, data protection acts or social media laws, project certificate,
license, copyright etc. Overall it can be said that Legal Feasibility Study is study to know if proposed project
conform legal and ethical requirements.

5. Schedule Feasibility: In Schedule Feasibility Study mainly timelines/deadlines is analyzed for proposed
project which includes how many times teams will take to complete final project which has a great impact
on the organization as purpose of project may fail if it can’t be completed on time.

6. Cultural and Political Feasibility: This section assesses how the software project will affect the political
environment and organizational culture. This analysis takes into account the organization’s culture and how
the suggested changes could be received there, as well as any potential political obstacles or internal
opposition to the project. It is essential that cultural and political factors be taken into account in order to
execute projects successfully.

7. Market Feasibility: This refers to evaluating the market’s willingness and ability to accept the suggested
software system. Analyzing the target market, understanding consumer wants and assessing possible rivals
are all part of this study. It assists in identifying whether the project is in line with market expectations and
whether there is a feasible market for the good or service being offered.

8. Resource Feasibility: This method evaluates if the resources needed to complete the software project
successfully are adequate and readily available. Financial, technological and human resources are all taken
into account in this study. It guarantees that sufficient hardware, software, trained labor and funding are
available to complete the project successfully.

Aim of Feasibility Study

 The overall objective of the organization are covered and contributed by the system or not.

 The implementation of the system be done using current technology or not.

 Can the system be integrated with the other system which are already exist

Feasibility Study Process

The below steps are carried out during entire feasibility analysis.

1. Information assessment: It assesses the original project concept and establishes the main aims and
objectives.
 UNIT 5: Software Quality Management& Estimation
2. Information collection: It collects the necessary information and data required to evaluate the project’s
many components.

3. Report writing: It produces an in-depth feasibility report that details the analysis and results.

4. General information: It gives a summary of the main points discussed in the report on the feasibility study.

Need of Feasibility Study

Feasibility study is so important stage of Software Project Management Process as after completion of feasibility
study it gives a conclusion of whether to go ahead with proposed project as it is practically feasible or to stop
proposed project here as it is not right/feasible to develop or to think/analyze about proposed project again.

Along with this Feasibility study helps in identifying risk factors involved in developing and deploying system and
planning for risk analysis also narrows the business alternatives and enhance success rate analyzing different
parameters associated with proposed project development.

What is Problem Decomposition?

If a computer system is a multiprocessing system, then a single problem/program must be divided into subproblems
in order to assign them to the processors. In order to perform this task a technique, Problem decomposition is used.
It is the process of decomposing a problem/program into multiple subproblems/subprograms. It is the basic building
block of Parallel Computing.

Decomposition is needed because a problem needs to be divided into different tasks and then mapped to the
processors, whereas a task is a subproblem resulting from the decomposition of a problem.

Techniques for Problem Decomposition

In order to decompose a problem/program, the following techniques can be used by a computer:

 Recursive Decomposition: This technique of decomposition is a general-purpose technology that can be

used to decompose any sort of problem in computation. It works basically on the basis of the “Divide and
Conquer” principle, which basically divides a problem into subproblems (Divide) and then assign them to
different processors (Conquer). A simple example is the sorting of an array using the Quick Sort Algorithm,
which basically divides the array into simplest units and then processes them in order to sort them in
ascending or descending order.

 Data Decomposition: This technique of decomposition is again general purpose. It divides the data in the
program into parts and then assigns them to instructions(tasks). Data Decomposition can be considered in a
matrix multiplication problem. Let say we have two matrices A and B, and their product is stored in another
matrix C.

Matrix A: Matrix B: Matrix C:

A1 A2 B1 B2 C1 C2
A3 A3 B3 B4 C3 C4

So, by data decomposition following tasks will be generated to get the product of A and B, and storing the new
matrix in C.
Task 1: C1= A1*B1
Task 2: C2= A2*B3
Task 3: C3= A3*B2
Task 4: C4= A4*B4

Now, these tasks will be assigned to four processors.

 Explorative Decomposition: This technique of decomposition is a special-purpose technique, it will be used

for a certain types of problems. A problem will be decomposed using explorative decomposition, if by
 UNIT 5: Software Quality Management& Estimation
decomposing it a search space is acquired, from where every element (subproblem) is processed by the
processors. An example of this type of decomposition is used in Puzzle games, where we have a search space
and we have to check the position of every part of the puzzle, to solve it.

 Speculative Decomposition: This technique is again a special-purpose technique. In this technique, the
problem is divided and assigned to the processors without any investigation or research, whether the
decision made is correct or wrong (speculative). Its best example is a program comprising of nested if. In a
program, if an if statement contains another if, and the program is already decomposed and the lines of
code are assigned to multiple processors without even checking the conditions, the processors will run both
the if statement and its inner if, but after some time when the condition is checked, e.g. false and the
decision is made, then the other if statement will also be discarded. Its limitation is that it doesn’t work on
the basis of correct decision making, it just divides and maps to the processors, but it is faster than other
decomposition techniques.

COCOMO Model-Software Engineering

COCOMO-II is the revised version of the original Cocomo (Constructive Cost Model) and was developed at the
University of Southern California. It is the model that allows one to estimate the cost, effort, and schedule when
planning a new software development activity.

Sub-Models of COCOMO Model

COCOMO Sub-models

1. End User Programming

Application generators are used in this sub-model. End user write the code by using these application generators.
For Example, Spreadsheets, report generator, etc.

2. Intermediate Sector

COCOMO Intermediate Sector

 UNIT 5: Software Quality Management& Estimation
 Application Generators and Composition Aids: This category will create largely prepackaged capabilities for
user programming. Their product will have many reusable components. Typical firms operating in this sector
are Microsoft, Lotus, Oracle, IBM, Borland, Novell.

 Application Composition Sector: This category is too diversified and to be handled by prepackaged
solutions. It includes GUI, Databases, domain specific components such as financial, medical or industrial
process control packages.

 System Integration: This category deals with large scale and highly embedded systems.

3. Infrastructure Sector

This category provides infrastructure for the software development like Operating System, Database Management
System, User Interface Management System, Networking System, etc.

Stages of COCOMO II

Stages of COCOMO

1. Stage-I

It supports estimation of prototyping. For this it uses Application Composition Estimation Model. This model is used
for the prototyping stage of application generator and system integration.

2. Stage-II

It supports estimation in the early design stage of the project, when we less know about it. For this it uses Early
Design Estimation Model. This model is used in early design stage of application generators, infrastructure, system
integration.

3. Stage-III

It supports estimation in the post architecture stage of a project. For this it uses Post Architecture Estimation Model.
This model is used after the completion of the detailed architecture of application generator, infrastructure, system
integration.