Software engineering and project management

Importance
Q. 1 What is a Software?
In a computer system, the software is basically a set of instructions or
commands that tell a computer what to do. In other words, the software is a
computer program that provides a set of instructions to execute a user’s
commands and tell the computer what to do. For example like MS-
Word, MS-Excel, PowerPoint, etc.
Types of Software
It is a collection of data that is given to the computer to complete a particular
task. The chart below describes the types of software:
Above is the diagram of types of software. Now we will briefly describe each
type and its subtypes:
• System Software
• Operating System
• Language Processor
• Device Driver
• Application Software
• General Purpose Software
• Customize Software
• Utility Software

System Software
System software is software that directly operates the computer
hardware and provides the basic functionality to the users as well as to the
other software to operate smoothly. Or in other words, system software
basically controls a computer’s internal functioning and also controls
hardware devices such as monitors, printers, and storage devices, etc. It is
like an interface between hardware and user applications, it helps them to
communicate with each other because hardware understands machine
language(i.e. 1 or 0) whereas user applications are work in human-readable
languages like English, Hindi, German, etc. so system software converts the
human-readable language into machine language and vice versa.

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.
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 (AI) software
makes use of nonnumeric algorithms to solve complex problems.
Application within this area include robotics, pattern recognition,
game playing

What is Software Engineering?

Software Engineering is the process of designing, developing, testing, and
maintaining software. It is a systematic and disciplined approach to
software development that aims to create high-quality, reliable, and
maintainable software.
1. Software engineering includes a variety of techniques, tools, and
methodologies, including requirements analysis, design, testing,
and maintenance.
2. It is a rapidly evolving field, and new tools and technologies are
constantly being developed to improve the software development
process.
3. By following the principles of software engineering and using the
appropriate tools and methodologies, software developers can
create high-quality, reliable, and maintainable software that meets
the needs of its users.
4. Software Engineering is mainly used for large projects based on
software systems rather than single programs or applications.
 5. The main goal of Software Engineering is to develop software
applications for improving quality, budget, and time efficiency.
6. Software Engineering ensures that the software that has to be built
should be consistent, correct, also on budget, on time, and within
the required requirements.

Key Principles of Software Engineering

1. Modularity: Breaking the software into smaller, reusable
components that can be developed and tested independently.
2. Abstraction: Hiding the implementation details of a component
and exposing only the necessary functionality to other parts of the
software.
3. Encapsulation: Wrapping up the data and functions of an object
into a single unit, and protecting the internal state of an object from
external modifications.
4. Reusability: Creating components that can be used in multiple
projects, which can save time and resources.
5. Maintenance: Regularly updating and improving the software to fix
bugs, add new features, and address security vulnerabilities.
6. Testing: Verifying that the software meets its requirements and is
free of bugs.
7. Design Patterns: Solving recurring problems in software design by
providing templates for solving them.
8. Agile methodologies: Using iterative and incremental
development processes that focus on customer satisfaction, rapid
delivery, and flexibility.
9. Continuous Integration & Deployment: Continuously integrating
the code changes and deploying them into the production
environment.
Main Attributes of Software Engineering
Software Engineering is a systematic, disciplined, quantifiable study and
approach to the design, development, operation, and maintenance of a
software system. There are four main Attributes of Software Engineering.
1. Efficiency: It provides a measure of the resource requirement of a
software product efficiently.
2. Reliability: It assures that the product will deliver the same results
when used in similar working environment.
3. Reusability: This attribute makes sure that the module can be used
in multiple applications.
4. Maintainability: It is the ability of the software to be modified,
repaired, or enhanced easily with changing requirements.

Objectives of Software Engineering

1. Maintainability: It should be feasible for the software to evolve to
meet changing requirements.
2. Efficiency: The software should not make wasteful use of
computing devices such as memory, processor cycles, etc.
3. Correctness: A software product is correct if the different
requirements specified in the SRS Document have been correctly
implemented.
4. Reusability: A software product has good reusability if the
different modules of the product can easily be reused to develop
new products.
5. Testability: Here software facilitates both the establishment of test
criteria and the evaluation of the software concerning those criteria.
6. Reliability: It is an attribute of software quality. The extent to
which a program can be expected to perform its desired function,
over an arbitrary time period.
7. Portability: In this case, the software can be transferred from one
computer system or environment to another.
 8. Adaptability: In this case, the software allows differing system
constraints and the user needs to be satisfied by making changes
to the software.
9. Interoperability: Capability of 2 or more functional units to process
data cooperatively.

Advantages of Software Engineering

• Improved Quality: By established software engineering principles
and techniques, the software can be developed with fewer bugs and
higher reliability.
• Increased Productivity: Using modern tools and methodologies can
streamline the development process, allowing developers to be more
productive and complete projects faster.
• Better Maintainability: Software that is designed and developed
using sound software engineering practices is easier to maintain and
update over time.
• Reduced Costs: By identifying and addressing potential problems
early in the development process, software engineering can help to
reduce the cost of fixing bugs and adding new features later on.
• Increased Customer Satisfaction: By involving customers in
the development process and developing software that meets
their needs, software engineering can help to increase customer
satisfaction.
• Better Team Collaboration: By using Agile methodologies
and continuous integration, software engineering allows for
better collaboration among development teams.
• Better Scalability: By designing software with scalability in mind,
software engineering can help to ensure that software can handle an
increasing number of users and transactions.
• Better Security: By following the Software Development Life Cycle
(SDLC) and performing security testing, software engineering can
help to prevent security breaches and protect sensitive data.

Disadvantages of Software Engineering

• High upfront costs: Implementing a systematic and disciplined
approach to software development can be resource-intensive and
require a significant investment in tools and training.
• Limited flexibility: software engineering principles and
methodologies can be rigid and may limit the ability to quickly adapt
to changing requirements.
• Bureaucratic: Software Engineering can create an environment that is
bureaucratic, with a lot of processes and paperwork, which may slow
down the development process.
• Complexity: With the increase in the number of tools and
methodologies, software engineering can be complex and difficult to
navigate.
• Limited creativity: The focus on structure and process can
stifle creativity and innovation among developers.
• High learning curve: The development process can be complex, and
it requires a lot of learning and training, which can be challenging for
new developers.
• High dependence on tools: Software engineering heavily depends on
the tools, and if the tools are not properly configured or are not
compatible with the software, it can cause issues.
• High maintenance: The software engineering process requires regular
maintenance to ensure that the software is running efficiently, which
can be costly and time-consuming.
Software Process

• A process is a collection of activities, actions and tasks that are

performed
• When some work product is to be created.
• It is not a rigid prescription for how to build computer software.
• It is an adaptable approach that enables the people doing the work
to pick and Choose the appropriate set of work actions and tasks.
• Purpose of process is to deliver software in a timely manner and
with sufficient Quality to satisfy those who have sponsored its
creation and those who will use It.
• Establishing a process is a key starting point for every software
development project.
• A process organizes the work on a software product into distinct
phases.
• A process provides a structure of expected activities and work,(gives
plan)
• Tasks are the small, manageable units of work for the project. They
are the building blocks for completing an activity, finishing a phase,
and ultimately completing a process.

Components of Software
There are three main components of the software:

Program: A computer program is a list of instructions that tell a

computer what to do.
Documentation: Source information about the product contained in
design documents, detailed code comments, etc.
Operating Procedures: Set of step-by-step instructions compiled by
an organization to help workers carry out complex routine
operations.
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.

Advantages of Software Development Framework

A Software Development Framework offers numerous benefits that
streamline the software development process and enhance the quality and
efficiency of the final product. Here are some key advantages:
1. Increased Productivity: Frameworks provide pre-built components
and tools, allowing developers to focus on specific application logic
rather than reinventing the wheel.
 2. Consistent Quality: By following best practices and standardized
processes, frameworks help ensure consistent code quality and
structure across the project.
3. Reduced Development Time: With ready-to-use templates and
libraries, developers can significantly cut down on the time needed
to build applications from scratch.
4. Better Maintainability: A structured framework makes the
codebase more organized and easier to understand, which
simplifies maintenance and updates.
5. Enhanced Security: Frameworks often include built-in security
features and follow industry best practices, reducing the risk of
vulnerabilities.
6. Scalability: Frameworks are designed to handle growth, making it
easier to scale applications as user demand increases.
Dis-advantages of Software Development Framework
While Software Development Frameworks offer several advantages, they
also come with certain drawbacks that developers and organizations should
consider:
1. Learning Curve: Frameworks often have a steep learning curve,
requiring developers to invest time and effort in understanding the
framework’s architecture, conventions, and best practices.
2. Restrictions: Some frameworks impose constraints and limitations
on how developers can design and implement certain features,
potentially limiting flexibility and creativity.
3. Complexity Overhead: In some cases, frameworks introduce
unnecessary complexity, especially for smaller or simpler projects,
which can lead to over-engineering.
4. Performance Overhead: Using a framework may introduce
additional layers of abstraction and overhead, which can impact the
performance of the application, particularly in resource-intensive
environments.
5. Vendor Lock-in: Depending heavily on a specific framework can
lead to vendor lock-in, making it challenging to switch to
alternative technologies or frameworks in the future.
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.

• Communication: By communication, customer requirement gathering

is done. Communication
with consumers and stakeholders to determine the system’s
objectives and the software’s
requirements.
• Planning: Establish engineering work plan, describes technical risk,
lists resources requirements,
work produced and defines work schedule.
• 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
• 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
• 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.

What is the Capability Maturity Model (CMM)

Capability Maturity Model (CMM) was developed by the Software
Engineering Institute (SEI) at Carnegie Mellon University in 1987. It is not a
software process model. It is a framework that is used to analyze the
approach and techniques followed by any organization to develop software
products. It also provides guidelines to enhance further the maturity of the
process used to develop those software products.
It is based on profound feedback and development practices adopted by the
most successful organizations worldwide. This model describes a strategy
for software process improvement that should be followed by moving
through 5 different levels. Each level of maturity shows a process capability
level. All the levels except level 1 are further described by Key Process
Areas (KPA).
Importance of Capability Maturity Model
• Optimization of Resources: CMM helps businesses make the best
use of all of their resources, including money, labor, and time.
Organizations can improve the effectiveness of resource allocation
by recognizing and getting rid of unproductive practices.
• Comparing and Evaluating: A formal framework for benchmarking
and self-evaluation is offered by CMM. Businesses can assess their
maturity levels, pinpoint their advantages and disadvantages, and
compare their performance to industry best practices.
 • Management of Quality: CMM emphasizes quality management
heavily. The framework helps businesses apply best practices for
quality assurance and control, which raises the quality of their
goods and services.
• Enhancement of Process: CMM gives businesses a methodical
approach to evaluate and enhance their operations. It provides a
road map for gradually improving processes, which raises
productivity and usefulness.
• Increased Output: CMM seeks to boost productivity by simplifying
and optimizing processes. Organizations can increase output and
efficiency without compromising quality as they go through the
CMM levels.

Levels of Capability Maturity Model (CMM)

There are 5 levels of Capability Maturity Models.
Level-1: Initial
• No KPIs defined.
• Processes followed are Adhoc and immature and are not well
defined.
• Unstable environment for software development.
• No basis for predicting product quality, time for completion, etc.
• Limited project management capabilities, such as no systematic
tracking of schedules, budgets, or progress.
• We have limited communication and coordination among team
members and stakeholders.
• No formal training or orientation for new team members.
• Little or no use of software development tools or automation.
• Highly dependent on individual skills and knowledge rather than
standardized processes.
• High risk of project failure or delays due to a lack of process control
and stability.
Level-2: Repeatable
• Focuses on establishing basic project management policies.
• Experience with earlier projects is used for managing new similar-
natured projects.
• Project Planning- It includes defining resources required, goals,
constraints, etc. for the project. It presents a detailed plan to be
followed systematically for the successful completion of good-
quality software.
• Configuration Management- The focus is on maintaining the
performance of the software product, including all its components,
for the entire lifecycle.
• Requirements Management- It includes the management of
customer reviews and feedback which result in some changes in
the requirement set. It also consists of accommodation of those
modified requirements.
 • Subcontract Management- It focuses on the effective
management of qualified software contractors i.e. it manages the
parts of the software developed by third parties.
• Software Quality Assurance- It guarantees a good quality
software product by following certain rules and quality standard
guidelines while developing.
Level-3: Defined
• At this level, documentation of the standard guidelines and
procedures takes place.
• It is a well-defined integrated set of project-specific software
engineering and management processes.
• Peer Reviews: In this method, defects are removed by using
several review methods like walkthroughs, inspections, buddy
checks, etc.
• Intergroup Coordination: It consists of planned interactions
between different development teams to ensure efficient and
proper fulfillment of customer needs.
• Organization Process Definition: Its key focus is on the
development and maintenance of standard development
processes.
• Organization Process Focus: It includes activities and practices
that should be followed to improve the process capabilities of an
organization.
• Training Programs: It focuses on the enhancement of knowledge
and skills of the team members including the developers and
ensuring an increase in work efficiency.
Level-4: Managed
• At this stage, quantitative quality goals are set for the organization
for software products as well as software processes.
• The measurements made help the organization to predict the
product and process quality within some limits defined
quantitatively.
 • Software Quality Management: It includes the establishment of
plans and strategies to develop quantitative analysis and
understanding of the product’s quality.
• Quantitative Management: It focuses on controlling the project
performance quantitatively.
Level-5: Optimizing
• This is the highest level of process maturity in CMM and focuses on
continuous process improvement in the organization using
quantitative feedback.
• The use of new tools, techniques, and evaluation of software
processes is done to prevent the recurrence of known defects.
• Process Change Management: Its focus is on the continuous
improvement of the organization’s software processes to improve
productivity, quality, and cycle time for the software product.
• Technology Change Management: It consists of the identification
and use of new technologies to improve product quality and
decrease product development time.
• Defect Prevention It focuses on the identification of causes of
defects and prevents them from recurring in future projects by
improving project-defined processes.

What is the SDLC 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.
This classical waterfall model is simple and idealistic. It is important
because most other Types of Software Development Life Cycle
Models are a derivative of this.
The Waterfall Model is useful in situations where the project
requirements are well-defined and the project goals are clear.
Phases of Waterfall Model
Classical Waterfall Model divides the life cycle into a set of phases. The
development process can be considered as a sequential flow in the waterfall.
The different sequential phases of the classical waterfall model are follow:

.
1. Requirements Analysis and Specification
Requirement Analysis and specification phase aims to understand the exact
requirements of the customer and document them properly. This phase
consists of two different activities.
1. 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).
2. 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.
2. Design
The goal of this Software Design 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).
• High-Level Design (HLD): This phase focuses on outlining the
broad structure of the system. It highlights the key components
and how they interact with each other, giving a clear overview of
the system’s architecture.
• Low-Level Design (LLD): Once the high-level design is in place,
this phase zooms into the details. It breaks down each component
into smaller parts and provides specifics about how each part will
function, guiding the actual coding process.
3. Development
In the Development Phase software design is translated into source code
using any suitable programming language. Thus each designed module is
coded. The unit testing phase aims to check whether each module is working
properly or not.
• In this phase, developers begin writing the actual source code
based on the designs created earlier.
• The goal is to transform the design into working code using the
most suitable programming languages.
• Unit tests are often performed during this phase to make sure that
each component functions correctly on its own.
4. Testing and Deployment
1. 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 several 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 performs acceptance testing to determine whether to
accept the delivered software or reject it.
2. Deployment: Once the software has been thoroughly tested, it’s time to
deploy it to the customer or end-users. This means making the software
ready and available for use, often by moving it to a live or staging
environment.
During this phase, we also focus on helping users get comfortable with the
software by providing training, setting up necessary environments, and
ensuring everything is running smoothly. The goal is to make sure the
system works as expected in real-world conditions and that users can start
using it without any hitches.
5. Maintenance
In Maintenance Phase 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 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.
Features of Waterfall Model
Following are the features of the waterfall model:
 1. Sequential Approach: The waterfall model involves a sequential
approach to software development, where each phase of the
project is completed before moving on to the next one.
2. Document-Driven: The waterfall model depended on
documentation to ensure that the project is well-defined and the
project team is working towards a clear set of goals.
3. Quality Control: The waterfall model places a high emphasis on
quality control and testing at each phase of the project, to ensure
that the final product meets the requirements and expectations of
the stakeholders.
4. Rigorous Planning: The waterfall model involves a careful
planning process, where the project scope, timelines, and
deliverables are carefully defined and monitored throughout the
project lifecycle.

Importance of Waterfall Model

Following are the importance of waterfall model:
1. Clarity and Simplicity: The linear form of the Waterfall Model
offers a simple and unambiguous foundation for project
development.
2. Clearly Defined Phases: The Waterfall Model phases each have
unique inputs and outputs, guaranteeing a planned development
with obvious checkpoints.
3. Documentation: A focus on thorough documentation helps with
software comprehension, maintenance, and future growth.
4. Stability in Requirements: Suitable for projects when the
requirements are clear and stable, reducing modifications as the
project progresses.
5. Resource Optimization: It encourages effective task-focused work
without continuously changing contexts by allocating resources
according to project phases.
6. Relevance for Small Projects: Economical for modest projects with
simple specifications and minimal complexity.
Advantages of 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: The 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: The classical Waterfall model has very clear and
well-understood milestones.
• Properly Documented: Processes, actions, and results are very
well documented.
• Reinforces Good Habits: The 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.

Disadvantages of Waterfall Model

The Classical Waterfall Model suffers from various shortcomings 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 the 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.

Applications of Waterfall Model

Here are some application of SDLC 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.

SDLC V-Model – Software Engineering

The SDLC V-Model is a Types of Software Development Life Cycle
(SDLC), which is used in Software Development process. In V-Model is the
extension of the Traditional Software Development Model.

It is creating a Structure like the “V” which includes the different phases
which we are discussing here in detailed manner.
V-model in Software Development Life Cycle (SDLC) is a method in that
include the testing and validation alongside each development phase.
It is based on the idea of a “V” shape, with the two legs of the “V”
representing the progression of the Software Development
Process from Requirements Gathering and analysis to design,
implementation, testing, and maintenance.
Phases of SDLC V-Model
The V-Model, which includes the Verification and Validation it is a
structural approach to the software development. The following is the
different Phases of V-Model of the SDLC.

V-Model Verification Phases

This is where the process begins. The first step is to gather and understand
the customer’s needs for the software. The goal is to define the scope of the
project clearly to make sure everyone is on the same page.
It involves a static analysis technique (review) done without executing code.
It is the process of evaluation of the product development phase to find
whether specified requirements are met.
There are several Verification phases in the V-Model:
1. Business Requirement Analysis
This is the first step of the designation of the development cycle where
product requirement needs to be cured from the customer’s perspective. in
these phases include proper communication with the customer to
understand the requirements of the customers.
These are the very important activities that need to be handled properly, as
most of the time customers do not know exactly what they want

2. System Design
In this phase, the overall structure of the software is planned out. The team
develops both the high-level design (how the system will be structured)
and detailed design (how the individual components will work).
Design of the system will start when the overall we are clear with the
product requirements, and then need to design the system completely.

3. Architectural Design
In this stage, architectural specifications are comprehended and designed.
Usually, several technical approaches are put out, and the ultimate choice is
made after considering both the technical and financial viability. The system
architecture is further divided into modules that each handle a distinct
function. Another name for this is High-Level Design (HLD).
At this point, the exchange of data and communication between the internal
modules and external systems are well understood and defined.

4. Module Design
This phase, known as Low-Level Design (LLD), specifies the comprehensive
internal design for every system module. Compatibility between the design
and other external systems as well as other modules in the system
architecture is crucial. Unit tests are a crucial component of any
development process since they assist in identifying and eradicating the
majority of mistakes and flaws at an early stage. .

5. Coding Phase
The Coding step involves writing the code for the system modules that
were created during the Design phase. The system and architectural
requirements are used to determine which programming language is most
appropriate.
The coding standards and principles are followed when performing the
coding. Before the final build is checked into the repository, the code
undergoes many code reviews and is optimized for optimal performance.

V-Model Validation Phases

It involves dynamic analysis techniques (functional, and non-functional), and
testing done by executing code. Validation is the process of evaluating the
software after the completion of the development phase to determine
whether the software meets the customer’s expectations and requirements.

1. Unit Testing
In Unit testing, unit Test Plans are developed during the module design
phase. These Unit Test Plans are executed to eliminate bugs in code or unit
level.
2. Integration testing
After completion of unit testing Integration testing is performed. In
integration testing, the modules are integrated and the system is tested.
Integration testing is performed in the Architecture design phase. This test
verifies the communication of modules among themselves.
3. System Testing
System testing tests the complete application with its functionality, inter-
dependency, and communication. It tests the functional and non-functional
requirements of the developed application.
4. User Acceptance Testing (UAT)
User Acceptance Testing (UAT) is performed in a user environment that
resembles the production environment. UAT verifies that the delivered
system meets the user’s requirement and the system is ready for use in the
real world
When to Use of V-Model?
• Traceability of Requirements: The V-Model proves beneficial in
situations when it’s imperative to create precise traceability
between the requirements and their related test cases.
• Complex Projects: The V-Model offers a methodical way to
manage testing activities and reduce risks related to integration
and interface problems for projects with a high level of complexity
and interdependencies among system components.
• Waterfall-Like Projects: Since the V-Model offers an approachable
structure for organizing, carrying out, and monitoring testing
activities at every level of development, it is appropriate for
projects that use a sequential approach to development, much like
the waterfall model.
• Safety-Critical Systems: These systems are used in the aerospace,
automotive, and healthcare industries. They place a strong
emphasis on rigid verification and validation procedures, which
help to guarantee that essential system requirements are fulfilled
and that possible risks are found and eliminated early in the
development process.

Advantages of V-Model
• This is a highly disciplined model and Phases are completed one at
a time.
• V-Model is used for small projects where project requirements are
clear.
• Simple and easy to understand and use.
• This model focuses on verification and validation activities early in
the life cycle thereby enhancing the probability of building an
error-free and good quality product.
• It enables project management to track progress accurately.
• Clear and Structured Process: The V-Model provides a clear and
structured process for software development, making it easier to
understand and follow.
 • Emphasis on Testing: The V-Model places a strong emphasis on
testing, which helps to ensure the quality and reliability of the
software.
• Improved Traceability: The V-Model provides a clear link between
the requirements and the final product, making it easier to trace
and manage changes to the software.
• Better Communication: The clear structure of the V-Model helps to
improve communication between the customer and the
development team

Disadvantages of V-Model
• The V-Model is a linear and sequential model, which can make it
difficult to adapt to changing requirements or unexpected events.
• The V-Model can be time-consuming, as it requires a lot of
documentation and testing.
• High risk and uncertainty.
• It is not good for complex and object-oriented projects.
• It is not suitable for projects where requirements are not clear and
contain a high risk of changing.
• This model does not support iteration of phases.
• It does not easily handle concurrent events.
• The V-Model places a strong emphasis on documentation, which
can lead to an overreliance on documentation at the expense of
actual development work.

Incremental process model

The Incremental model is a software Development approach which is used
to breakdown the project into smaller and easily manageable parts. In these
each part will goes through Requirement, Design, Testing phases and
Implementation phase. The overall process continue until we got the
complete System.
Phases of Incremental Model
The phases of Incremental model is divided into the four parts which is
Requirement, Design, Testing phases and Implementation phase. In those
phase, the process continues until we got the expected output at the end.

1. Requirement Analysis: The first step in the Incremental Model is

understanding what the software needs to do. The team gathers the
requirements from the product experts and clearly defines the system’s
functional needs. This phase is important because it sets the foundation for
everything else in the development process.
2. Design & Development: Next, the team focuses on designing how the
software will function and starts developing it. They work on adding new
features and making sure the system works as expected. The design and
development steps go hand-in-hand to build the functionality of the
software.
3. Testing: Once a feature is developed, it goes through testing. The testing
phase checks how the software performs, including both new and existing
features. The team uses different testing methods to make sure everything
is working correctly.
4. Implementation: This phase involves writing the final code based on the
design and development steps. After testing the functionality, the team
verify that everything is working as planned. By the end of this phase, the
product is gradually improved and updated until it becomes the final
working version.

When to use the Incremental Process Model

• When the requirements are well-defined and clear.
• If the project having the long development timeline.
• When the software development team is not highly skilled or
experienced yet.
• If the customer needs a quick product release.
• When you want to develop the most important features first.
Advantages of the Incremental 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 the 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 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.

Evolutionary Process Model

The evolutionary model is based on the concept of making an initial product
and then evolving the software product over time with iterative and
incremental approaches with proper feedback. In this type of model, the
product will go through several iterations and come up when the final
product is built through multiple iterations. The development is carried out
simultaneously with the feedback during the development.

Types of Evolutionary Process Models

1. Iterative Model
2. Incremental Model
3. Spiral Model
Iterative Model
In the iterative model first, we take the initial requirements then we enhance
the product over multiple iterations until the final product gets ready. In every
iteration, some design modifications were made and some changes in
functional requirements is added. The main idea behind this approach is to
build the final product through multiple iterations that result in the final
product being almost the same as the user wants with fewer errors and the
performance, and quality would be high.
Incremental Model
In the incremental model, we first build the project with basic features and
then evolve the project in every iteration, it is mainly used for large projects.
The first step is to gather the requirements and then perform analysis,
design, code, and test and this process goes the same over and over again
until our final project is ready.

Spiral Model
The spiral model is a combination of waterfall and iterative models and in
this, we focused on risk handling along with developing the project with the
incremental and iterative approach, producing the output quickly as well as
it is good for big projects. The software is created through multiple iterations
using a spiral approach. Later on, after successive development the final
product will develop, and the customer interaction is there so the chances of
error get reduced.
Advantages of the Evolutionary Process Model
1. During the development phase, the customer gives feedback
regularly because the customer’s requirement gets clearly
specified.
2. After every iteration risk gets analyzed.
3. Suitable for big complex projects.
4. The first build gets delivered quickly as it used an iterative and
incremental approach.
5. Enhanced Flexibility: The iterative nature of the model allows for
continuous changes and refinements to be made, accommodating
changing requirements effectively.
6. Risk Reduction: The model’s emphasis on risk analysis during each
iteration helps in identifying and mitigating potential issues early in
the development process.
7. Adaptable to Changes: Since changes can be incorporated at the
beginning of each iteration, it is well-suited for projects with
evolving or uncertain requirements.
8. Customer Collaboration: Regular customer feedback throughout
the development process ensures that the end product aligns more
closely with the customer’s needs and expectations.
Disadvantages of the Evolutionary Process Model
1. It is not suitable for small projects.
2. The complexity of the spiral model can be more than the other
sequential models.
3. The cost of developing a product through a spiral model is high.
4. roject Management Complexity: The iterative nature of the model
can make project management and tracking more complex
compared to linear models.
5. Resource Intensive: The need for continuous iteration and
customer feedback demands a higher level of resources, including
time, personnel, and tools.
6. Documentation Challenges: Frequent changes and iterations can
lead to challenges in maintaining accurate and up-to-date
documentation.
 7. Potential Scope Creep: The flexibility to accommodate changes
can sometimes lead to an uncontrolled expansion of project scope,
resulting in scope creep.
8. Initial Planning Overhead: The model’s complexity requires a
well-defined initial plan, and any deviations or adjustments can be
time-consuming and costly.

What is the concurrent development model?

The concurrent development model is a model in software engineering
where more than one phase in a project is under development at any one
time instead of one phase at a time. This model supports the concept of
concurrency in that design, code, test and another related phase occur
simultaneously. They include minimizing development time, encouraging
effective interaction between development teams, and increasing the
versatility of the resulting product due to the possibility of feedback at any
step of the cycle.

Features of the Concurrent Development Model

Parallel Workflow: Several phases start and run concurrently like the
design phase, development phase, and the testing phase allowing
completion of a project more expediently.
Real-time Communication: Everyone gets repeated feedback hence the
team works and solutions together to ensure the common goal is
achieved.
Flexibility: Stakeholders can incorporate new changes and improvements
easily since one phase operates in tangent to another.
Iterative Development: The model is also suitable for iterative activities in
which input and testing are received continually, and prototypes are
revised.
Reduced Time-to-Market: The work is divided between the tasks and
stages, making the project faster since many tasks are done concurrently.
Types of Concurrent Development Model
Here are the types of Concurrent Development Model:

Waterfall Model
The Waterfall Model is a linear and sequential model of software
development since each phase has to be finished before continuing to the
next phase. It is a sequential process, which involves requirement, design,
implementation, testing, deployment and maintenance. One phase can be
said to be dependent on the other next phase, and there is little mirroring
between phases. It is valuable for projects where the requirements for the
project are pretty much set, and they are not reasonable to change during
the process.

Prototype Model
A prototype Model is a model of integrated software development where
first a prototype or an initial model of the wanted system is created and
then tested and modified according to the users’ feedback. This facilitates
requirements understanding in cycles so that stakeholders are able to
envision what is to be delivered in the latter stages. It goes through a
number of design changes before it is concluded as the model solution.

Spiral Model
The Spiral Model is a model of software development that is based on the
risk-management concept and, in turn, is an elaboration upon the
Waterfall and Prototype models of the software development. It permits
iterative improvement through one or more spirals (iterations), each
consisting of design, risk assessment, design development, and review.
Frequent incremental changes mean that each cycle develops a better
system when evaluated by the users and its risk profile, which makes it
very adaptable, and ideal for large projects with many sub-projects.

Stages in the Concurrent Development Model

• System Requirements Gathering: The first involves defining the
project manager the general requirements concerning the project. As
opposed to such models where requirements cannot be changed
through recessive phases, requirements, in general, can be modified
here and now.
• Design and Prototyping: Design is concurrent with other phases for
example the coding and testing phase. Distinct facets of design such
as architectural and system are made and checked at the same time
by using and integrating feedback.
• Development and Coding: Development teams attend to different
modules altogether, writing a certain code for features that will be
developed in parallel with design and testing teams. This
concurrency is useful for the implementation of changes and
feedback in the design phase.
• Integration and Testing: Testing is approached as an agile process
and it is done in parallel to development. Every module is tested
throughout the development allowing the developer to see the
output and pick any error that may be present. Continuous
integration is used here to ensure that the system does not get
disrupted each time new features are included.
• Deployment and Maintenance: The deployment occurs gradually and
the components are launched at different intervals. Maintenance is
also continuous since information gathered from the live system will
then be used for the further enhancement of the system in parallel
with other parallel activities.

Benefits of the Concurrent Development Model

 • Reduced Development Time: This is compounded by the fact that
several stages are carried out concurrently, which in turn speeds up
the delivery of the project, and therefore the products.
• Improved Collaboration: Separation of tasks in phases like design-
phase/code-phase/test-phase makes teams work together, which
results in increased levels of communication within a development
phase.
• Early Detection of Issues: When testing, it is combined with
development so that problems that are found are fixed early on and
do not have to wait for a later stage.
• Flexibility and Adaptability: There is an option of giving feedback as
the development continues hence can be easily modified to correct
any requirement or market condition in the process.
• Enhanced Product Quality: The feedback and the updates later on in
the process ensure that the final product is enhanced to the required
standard.
• Parallel Progress: When multiple teams are involved, each
proceeding independently on one part of the project, it means that
there will be more work done in less time meaning the best use of
resources.
• Reduced Risk: The general applicability of testing and the
practicality in applying testing concurrently reduces the temporal
vulnerability of finding show-stopper problems and contributes to
the resolution of project failures.
• Faster Time-to-Market: Product development overlaps mean that
more tasks are handled concurrently and with less lag time, which
puts companies in a better position to get products to the market.

Challenges of the Concurrent Development Model

• Complex Project Management: Simultaneous management of
several projects among cross-functional teams requires complex
skills and resources. Essential things like managing dependencies,
priorities, and communications can be quite challenging.
 • Communication Overload: Due to this, several groups must
communicate incessantly since several teams work concurrently. If
communication between the teams is not adequate or not frequent
enough, it results in conflict hence integration concerns.
• Higher Resource Demand: Simultaneous activity required in
concurrent work may have a desire for greater resources in
manpower, equipment, and facilities, owing to escalating the total
cost of an assignment.
• Difficulty in Managing Dependencies: In the case of multiple
development teams where each team is working on an assigned
module when one team is behind the other by a couple of weeks and
they have produced data inter-modules interfaces become a problem
since it will frustrate the entire development process.
• Increased Complexity in Integration: Incorporating independently
developed modules may sometimes call for some difficulties,
particularly so in instances where the developing teams are working
independently most likely due to asynchrony. You are likely to come
across issues of conflict or even incompatibility when integrating
layers.
• Frequent Requirement Changes: Flexibility can also be seen as a
drawback since changing requirements can be quite problematic if
they are changed too often, potentially causing scope creep in the
process which will make development more difficult.
• Potential for Quality Trade-offs: Working at the same time through
two or more tasks may result in some essential steps being
overlooked or some standards compromised while trying to meet set
deadlines thus lessening the quality of work produced.
• Testing Challenges: There could be a need d for more enhanced
testing tools and frameworks when testing concurrently to ensure
that integration is continuous and that all segments of the system
are end-to-end tested.

Real-World Applications of the Concurrent Development Model

 • Aerospace and Defense: In the aerospace industry for instance,
several are sub-teams working on different aspects of a project such
as the avionics subsystem, the propulsion subsystem and the control
subsystem and these work simultaneously to meet laid down project
deadlines. For example in aircraft or spacecraft design, concurrent
engineering must be employed to guarantee that various systems
complement one another and also come up to safety requirements.
• Automotive Industry: Concurrent engineering in the automotive
industry facilitates the development of multiple components at once
of a vehicle for instance engine, safety systems and interfaces. This
model assists automotive companies in shortening the overall time it
takes to go from a conceptual design to producing the idea.
• Software Development: It is worth to noting that the Concurrent
Development Model is widely applied in agile and DevOps
development methodologies. For instance, development, testing and
deployment may occur independently through a system known as
continuous integration/continuous delivery pipelines. This enables
firms like Google or Amazon to roll out features and update as often
as they wish with a promise of quality.
• Consumer Electronics: Some electronics such as Samsung follow the
concurrent development model in products like smartphones the
hardware, including the chipset, sensors and software, operating
system and applications, are designed and produced at the same
time to arrive in the market as one product by meeting the necessary
deadlines.

Agile process :
Agile Software Development is an iterative and incremental approach
to Software Development that emphasizes the importance of delivering a
working product quickly and frequently. It involves close collaboration
between the development team and the customer to ensure that the
product meets their needs and expectations.
Why is Agile Used?
Agile is used because it helps teams deliver value quickly and continuously.
By prioritizing the delivery of difficult results early in the project, customers
benefit from seeing and using the product sooner, allowing for quick
feedback and adjustments. Agile also encourages teams to focus on what
truly matters, concentrating on tasks that add value and avoiding
unnecessary work.
• Agile as a Mindset: Agile represents a shift in culture that values
adaptability, collaboration, and client happiness. It gives team
members more authority and promotes a cooperative and upbeat
work atmosphere.
• Quick Response to Change: Agile fosters a culture that allows
teams to respond swiftly to constantly shifting priorities and
requirements. This adaptability is particularly useful in sectors of
the economy or technology that experience fast changes.
• Regular Demonstrations: Agile techniques place a strong
emphasis on regular demonstrations of project progress.
Stakeholders may clearly see the project’s status, upcoming
problems, and upcoming new features due to this transparency.
• Cross-Functional Teams: Agile fosters self-organizing, cross-
functional teams that share information effectively, communicate
more effectively and feel more like a unit.
Agile Software Development Process
Agile software development, often just called Agile, focuses on being
flexible and practical when delivering software. Instead of launching
everything at once, Agile delivers small, valuable updates to users over
time. This approach allows teams to adjust and improve the product along
the way, verifying that each update brings real value to the users. It’s all
about making progress in manageable steps and responding quickly to
changes.
1. Requirements Gathering
This is the first step where the development team works closely with the
customer to understand what they really need from the software. The team
listens carefully to the customer’s needs, then sorts and prioritizes these
requirements to make sure the most important features are developed first.
2. Planning
In this stage, the team creates a clear plan for how they’ll build the
software. They decide which features to focus on in each development cycle
(called an iteration). Think of it like mapping out the journey of the project,
so everyone knows what to expect and when things will be delivered.
3. Development
This is where the team starts turning their plan into reality. They work in
short, focused cycles, building small, usable pieces of the product. Each
cycle builds on the last, which helps the team stay on track and get quick
feedback to keep improving.
4. Testing
As the software gets built, it’s also tested to make sure it works properly
and meets the customer’s needs. Testing ensures the product is of high
quality and free from errors, so problems are caught early on before they
become bigger issues.
5. Deployment
Once everything is tested and working as expected, the software is
deployed, which means it’s ready for customers or end-users to start using.
It’s the moment when all the development work comes to life.
6. Maintenance
Even after the software is released, the job isn’t done. The team keeps
maintaining the software, verifying it continues to work well and stays up-
to-date with any new needs or changes from the customer. This keeps the
software relevant and helpful over time.
Agile Software Development is widely used by software development
teams and is considered to be a flexible and adaptable approach to software
development that is well-suited to changing requirements and the fast pace
of software development. Agile is a time-bound, iterative approach to
software delivery that builds software incrementally from the start of the
project, instead of trying to deliver all at once.

Advantages Agile Software Development

• Increased collaboration and communication: Agile Software
Development Methodology emphasize collaboration and
communication among team members, stakeholders, and
customers. This leads to improved understanding, better
alignment, and increased buy-in from everyone involved.
• Flexibility and adaptability: Agile methodologies are designed to
be flexible and adaptable, making it easier to respond to changes
in requirements, priorities, or market conditions. This allows teams
to quickly adjust their approach and stay focused on delivering
value.
• Improved quality and reliability: Agile methodologies place a
strong emphasis on testing, quality assurance, and continuous
improvement. This helps to ensure that software is delivered with
high quality and reliability, reducing the risk of defects or issues
that can impact the user experience.
• Enhanced customer satisfaction: Agile methodologies prioritize
customer satisfaction and focus on delivering value to the
 customer. By involving customers throughout the development
process, teams can ensure that the software meets their needs and
expectations.
• Increased team morale and motivation: Agile methodologies
promote a collaborative, supportive, and positive work
environment. This can lead to increased team morale, motivation,
and engagement, which can in turn lead to better productivity,
higher quality work, and improved outcomes.
• Deployment of software is quicker and thus helps in increasing the
trust of the customer.
• Can better adapt to rapidly changing requirements and respond
faster.
• Helps in getting immediate feedback which can be used to improve
the software in the next increment.
• People – Not Process. People and interactions are given a higher
priority than processes and tools.
• Continuous attention to technical excellence and good design.

Disadvantages Agile Software Development

• Lack of predictability: Agile Development relies heavily on
customer feedback and continuous iteration, which can make it
difficult to predict project outcomes, timelines, and budgets.
• Limited scope control: Agile Development is designed to be
flexible and adaptable, which means that scope changes can be
easily accommodated. However, this can also lead to scope creep
and a lack of control over the project scope.
• Lack of emphasis on testing: Agile Development places a greater
emphasis on delivering working code quickly, which can lead to a
lack of focus on testing and quality assurance. This can result in
bugs and other issues that may go undetected until later stages of
the project.
• Risk of team burnout: Agile Development can be intense and fast-
paced, with frequent sprints and deadlines. This can put a lot of
 pressure on team members and lead to burnout, especially if the
team is not given adequate time for rest and recovery.
• Lack of structure and governance: Agile Development is often less
formal and structured than other development methodologies,
which can lead to a lack of governance and oversight. This can
result in inconsistent processes and practices, which can impact
project quality and outcomes.
• In the case of large software projects, it is difficult to assess the
effort required at the initial stages of the software development life
cycle.
• Agile Development is more code-focused and produces less
documentation.
• Agile development is heavily dependent on the inputs of the
customer. If the customer has ambiguity in his vision of the
outcome, it is highly likely that the project to get off track.
• Face-to-face communication is harder in large-scale organizations.
• Only senior programmers are capable of making the kind of
decisions required during the development process. Hence, it’s a
difficult situation for new programmers to adapt to the
environment.

Advantages of Agile over traditional software development

approaches
1. Increased customer satisfaction: Agile development involves close
collaboration with the customer, which helps to ensure that the
software meets their needs and expectations.
2. Faster time-to-market: Agile development emphasizes the
delivery of working software in short iterations, which helps to get
the software to market faster.
3. Reduced risk: Agile development involves frequent testing and
feedback, which helps to identify and resolve issues early in the
development process.
 4. Improved team collaboration: Agile development emphasizes
collaboration and communication between team members, which
helps to improve productivity and morale.
5. Adaptability to change: Agile Development is designed to be
flexible and adaptable, which means that changes to the project
scope, requirements, and timeline can be accommodated easily.
This can help the team to respond quickly to changing business
needs and market demands.
6. Better quality software: Agile Development emphasizes
continuous testing and feedback, which helps to identify and
resolve issues early in the development process. This can lead to
higher-quality software that is more reliable and less prone to
errors.
7. Increased transparency: Agile Development involves frequent
communication and collaboration between the team and the
customer, which helps to improve transparency and visibility into
the project status and progress. This can help to build trust and
confidence with the customer and other stakeholders.
8. Higher productivity: Agile Development emphasizes teamwork
and collaboration, which helps to improve productivity and reduce
waste. This can lead to faster delivery of working software with
fewer defects and rework.
9. Improved project control: Agile Development emphasizes
continuous monitoring and measurement of project metrics, which
helps to improve project control and decision-making. This can
help the team to stay on track and make data-driven decisions
throughout the development process.

12 Principles of Agile Software Development

There are 12 agile principles mentioned in the Agile Manifesto. Agile
principles are guidelines for flexible and efficient software development.
They emphasize frequent delivery, embracing change, collaboration, and
continuous improvement. The focus is on delivering value, maintaining a
sustainable work pace, and ensuring technical excellence.
These principles include:
1. Ensuring customer satisfaction through the early delivery of
software.
2. Being open to changing requirements in the stages of the
development.
3. Frequently delivering working software with a main focus on
preference for timeframes.
4. Promoting collaboration between business stakeholders and
developers as an element.
5. Structuring the projects around individuals. Providing them with
the necessary environment and support.
6. Prioritizing face to face communication whenever needed.
7. Considering working software as the measure of the progress.
8. Fostering development by allowing teams to maintain a pace
indefinitely.
9. Placing attention on excellence and good design practices.
10. Recognizing the simplicity as crucial factor aiming to maximize
productivity by minimizing the work.
11. Encouraging self organizing teams as the approach to design
and build systems.
12. Regularly reflecting on how to enhance effectiveness and to
make adjustments accordingly.
What is Extreme Programming (XP)?
Extreme Programming (XP) is an Agile software development
methodology that focuses on delivering high-quality software through
frequent and continuous feedback, collaboration, and adaptation. XP
emphasizes a close working relationship between the development team,
the customer, and stakeholders, with an emphasis on rapid, iterative
development and deployment.

Basic Principles of Extreme programming

XP is based on the frequent iteration through which the developers
implement User Stories.
• Coding: The concept of coding which is used in the XP model is
slightly different from traditional coding. Here, the coding activity
includes drawing diagrams (modeling) that will be transformed
into code, scripting a web-based system, and choosing among
several alternative solutions.
• Testing: The XP model gives high importance to testing and
considers it to be the primary factor in developing fault-free
software.
• Listening: The developers need to carefully listen to the customers
if they have to develop good quality software. Sometimes
programmers may not have the depth knowledge of the system to
 be developed. So, the programmers should understand properly
the functionality of the system and they have to listen to the
customers.
• Designing: Without a proper design, a system implementation
becomes too complex, and very difficult to understand the solution,
thus making maintenance expensive. A good design results
elimination of complex dependencies within a system. So, effective
use of suitable design is emphasized.
• Feedback: One of the most important aspects of the XP model is to
gain feedback to understand the exact customer needs. Frequent
contact with the customer makes the development effective.
• Simplicity: The main principle of the XP model is to develop a
simple system that will work efficiently in the present time, rather
than trying to build something that would take time and may never
be used. It focuses on some specific features that are immediately
needed, rather than engaging time and effort on speculations of
future requirements.
• Pair Programming: XP encourages pair programming where two
developers work together at the same workstation. This approach
helps in knowledge sharing, reduces errors, and improves code
quality.
• Continuous Integration: In XP, developers integrate their code into
a shared repository several times a day. This helps to detect and
resolve integration issues early on in the development process.
• Refactoring: XP encourages refactoring, which is the process of
restructuring existing code to make it more efficient and
maintainable. Refactoring helps to keep the codebase clean,
organized, and easy to understand.
• Collective Code Ownership: In XP, there is no individual ownership
of code. Instead, the entire team is responsible for the codebase.
This approach ensures that all team members have a sense of
ownership and responsibility towards the code.
• Planning Game: XP follows a planning game, where the customer
and the development team collaborate to prioritize and plan
development tasks. This approach helps to ensure that the team is
 working on the most important features and delivers value to the
customer.
• On-site Customer: XP requires an on-site customer who works
closely with the development team throughout the project. This
approach helps to ensure that the customer’s needs are
understood and met, and also facilitates communication and
feedback.

Applications of Extreme Programming (XP)

Some of the projects that are suitable to develop using the XP model are
given below:
• Small projects: The XP model is very useful in small projects
consisting of small teams as face-to-face meeting is easier to
achieve.
• Projects involving new technology or Research projects: This
type of project faces changing requirements rapidly and technical
problems. So XP model is used to complete this type of project.
• Web development projects: The XP model is well-suited for web
development projects as the development process is iterative and
requires frequent testing to ensure the system meets the
requirements.
• Collaborative projects: The XP model is useful for collaborative
projects that require close collaboration between the development
team and the customer.
• Projects with tight deadlines: The XP model can be used in
projects that have a tight deadline, as it emphasizes simplicity and
iterative development.
• Projects with rapidly changing requirements: The XP model is
designed to handle rapidly changing requirements, making it
suitable for projects where requirements may change frequently.
• Projects where quality is a high priority: The XP model places a
strong emphasis on testing and quality assurance, making it a
suitable approach for projects where quality is a high priority.
XP, and other agile methods, are suitable for situations where the volume
and space of requirements change are high and where requirement risks are
considerable.

Life Cycle of Extreme Programming (XP)

The Extreme Programming Life Cycle consist of five phases:

1. Planning: The first stage of Extreme Programming is planning.

During this phase, clients define their needs in concise descriptions
known as user stories. The team calculates the effort required for
each story and schedules releases according to priority and effort.
2. Design: The team creates only the essential design needed for
current user stories, using a common analogy or story to help
everyone understand the overall system architecture and keep the
design straightforward and clear.
3. Coding: Extreme Programming (XP) promotes pair programming
i.e. wo developers work together at one workstation, enhancing
code quality and knowledge sharing. They write tests before
coding to ensure functionality from the start (TDD), and frequently
integrate their code into a shared repository with automated tests
to catch issues early.
 4. Testing: Extreme Programming (XP) gives more importance to
testing that consist of both unit tests and acceptance test. Unit
tests, which are automated, check if specific features work
correctly. Acceptance tests, conducted by customers, ensure that
the overall system meets initial requirements. This continuous
testing ensures the software’s quality and alignment with customer
needs.
5. Listening: In the listening phase regular feedback from customers
to ensure the product meets their needs and to adapt to any
changes.

Values of Extreme Programming (XP)

There are five core values of Extreme Programming (XP)

1.Communication: The essence of communication is for information

and ideas to be exchanged amongst development team members
so that everyone has an understanding of the system requirements
and goals. Extreme Programming (XP) supports this by allowing
open and frequent communication between members of a team.
 2. Simplicity: Keeping things as simple as possible helps reduce
complexity and makes it easier to understand and maintain the
code.
3. Feedback: Feedback loops which are constant are among testing
as well as customer involvements which helps in detecting
problems earlier during development.
4. Courage: Team members are encouraged to take risks, speak up
about problems, and adapt to change without fear of
repercussions.
5. Respect: Every member’s input or opinion is appreciated which
promotes a collective way of working among people who are
supportive within a certain group.
Advantages of Extreme Programming (XP)
• Slipped schedules: Timely delivery is ensured through slipping
timetables and doable development cycles.
• Misunderstanding the business and/or domain − Constant contact
and explanations are ensured by including the client on the team.
• Canceled projects: Focusing on ongoing customer engagement
guarantees open communication with the consumer and prompt
problem-solving.
• Staff turnover: Teamwork that is focused on cooperation provides
excitement and goodwill. Team spirit is fostered by
multidisciplinary cohesion.
• Costs incurred in changes: Extensive and continuing testing
ensures that the modifications do not impair the functioning of the
system. A functioning system always guarantees that there is
enough time to accommodate changes without impairing ongoing
operations.
• Business changes: Changes are accepted at any moment since
they are seen to be inevitable.
• Production and post-delivery defects: the unit tests to find and
repair bugs as soon as possible.

SCRUM :
Scrum is an agile framework used for project management, particularly in
software development, where teams collaborate to deliver products
incrementally. It focuses on breaking down work into short, iterative periods
called sprints, and using empirical knowledge and continuous learning to
adapt to changing requirements. Scrum is also inspired by the rugby scrum,
where teams work together to move the ball forward.

Here's a more detailed look:

Core Principles of Scrum:

• Empiricism: Scrum relies on experience and observation to make decisions.
• Transparency: Everyone has access to the information they need to make
informed decisions.
• Inspection: Regularly reviewing progress and identifying potential problems.
• Adaptation: Adjusting plans and strategies based on inspection and feedback.

Key Roles in Scrum:

• Product Owner: Represents the stakeholders and prioritizes the backlog.
• Scrum Master: Facilitates the Scrum process, removes impediments, and
ensures the team is following best practices.
• Development Team: Cross-functional team responsible for building the product
increment.

Scrum Events:
• Sprint:
A time-boxed iteration (typically 1-4 weeks) where a team delivers a valuable
increment of the product.
• Sprint Planning:
The team selects items from the Product Backlog to work on during the sprint.
• Daily Scrum:
A short (15-minute) meeting where the team discusses progress, identifies
impediments, and coordinates their work.
• Sprint Review:
The team demonstrates the completed Increment to stakeholders and gathers
feedback.
• Sprint Retrospective:
The team reflects on the sprint, identifies areas for improvement, and plans for the
next sprint.

Scrum Artifacts:
• Product Backlog: A prioritized list of features and requirements for the product.
• Sprint Backlog: A list of items from the Product Backlog that the team will work
on during the current sprint.
• Increment: The valuable, potentially shippable product that is delivered at the end
of each sprint.

What are Functional Requirements?

These are the requirements that the end user specifically demands as basic
facilities that the system should offer. All these functionalities need to be
necessarily incorporated into the system as a part of the contract.
• These are represented or stated in the form of input to be given to
the system, the operation performed and the output expected.
• They are the requirements stated by the user which one can see
directly in the final product, unlike the non-functional
requirements.
Examples:
• What are the features that we need to design for this system?
• What are the edge cases we need to consider, if any, in our design?

What are Non-Functional Requirements?

These are the quality constraints that the system must satisfy according to
the project contract. The priority or extent to which these factors are
implemented varies from one project to another. They are also called non-
behavioral requirements. They deal with issues like:
• Portability
• Security
• Maintainability
• Reliability
• Scalability
• Performance
• Reusability
• Flexibility
Examples:
• Each request should be processed with the minimum latency?
• System should be highly valuable.

Examples of Functional and Non-functional Requirements

Let’s consider a couple of examples to illustrate both types of requirements:

1. Online Banking System

1. Functional Requirements:
• Users should be able to log in with their username and password.
• Users should be able to check their account balance.
• Users should receive notifications after making a transaction.
2. Non-functional Requirements:
• The system should respond to user actions in less than 2 seconds.
• All transactions must be encrypted and comply with industry
security standards.
• The system should be able to handle 100 million users with
minimal downtime.

2. Food Delivery App

1. Functional Requirements
• Users can browse the menu and place an order.
• Users can make payments and track their orders in real time.
2. Non-functional Requirements:
• The app should load the restaurant menu in under 1 second.
• The system should support up to 50,000 concurrent orders during
peak hours.
• The app should be easy to use for first-time users, with an intuitive
interface.

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. To guarantee the effective creation of a software product, the
requirements engineering process entails several tasks that help in
understanding, recording, and managing the demands of stakeholders.

1. Feasibility Study
2. Requirements elicitation
3. Requirements specification
4. Requirements for verification and validation
5. Requirements management
1. Feasibility Study
The feasibility study mainly concentrates on below five mentioned
areas below. Among these Economic Feasibility Study is the most
important part of the feasibility analysis and the Legal Feasibility
Study is less considered feasibility analysis.
1. Technical Feasibility: In Technical Feasibility current
resources both hardware software along required
technology are analyzed/assessed to develop the project.
This technical feasibility study reports whether there are
correct required resources and technologies that will be
used for project development. Along with this, the
feasibility study also analyzes the technical skills and
capabilities of the technical team, whether existing
technology can be used or not, whether maintenance and
up-gradation are easy or not for the chosen technology,
etc.
2. Operational Feasibility: In Operational Feasibility degree
of providing service to requirements is analyzed along
with how easy the product will be to operate and maintain
after deployment. Along with this other operational
scopes are determining the usability of the product,
Determining suggested solution by the software
development team is acceptable or not, etc.
3. Economic Feasibility: In the Economic Feasibility study
cost and benefit of the project are analyzed. This means
under this feasibility study a detailed analysis is carried
out will be cost of the project for development which
includes all required costs for final development hardware
and software resources required, design and development
costs operational costs, and so on. After that, it is analyzed
whether the project will be beneficial in terms of finance
for the organization or not.
4. Legal Feasibility: In legal feasibility, the project is ensured
to comply with all relevant laws, regulations, and
standards. It identifies any legal constraints that could
impact the project and reviews existing contracts and
agreements to assess their effect on the project’s
execution. Additionally, legal feasibility considers issues
 related to intellectual property, such as patents and
copyrights, to safeguard the project’s innovation and
originality.
5. Schedule Feasibility: In schedule feasibility, the project
timeline is evaluated to determine if it is realistic and
achievable. Significant milestones are identified, and
deadlines are established to track progress effectively.
Resource availability is assessed to ensure that the
necessary resources are accessible to meet the project
schedule. Furthermore, any time constraints that might
affect project delivery are considered to ensure timely
completion. This focus on schedule feasibility is crucial for
the successful planning and execution of a project.
2. 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 the same type, standards, 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.
Several techniques 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.
3. 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.
Several types of requirements 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.
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.
4. 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.

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

Activities 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 promptly.
 5. Monitoring and reporting: This involves monitoring the progress
of the development process and reporting on the status of the
requirements.

Advantages of Requirements Engineering Process

• 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 an 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 of Requirements Engineering Process
• 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
• It 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.
 • 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.

What is Software Prototyping?

Software Prototyping Model is a software development methodology that
involves creating an initial prototype of the software product before
developing the final product.
• A prototype can be a limited-functionality software performance
model.
• The prototype does not always contain the exact logic used in the
specific software application and is an additional effort to be
considered when estimating effort.
• Prototyping is used to allow users to evaluate and test developer
proposals before they are implemented.
• It also aids in understanding the user-specific requirements that
will not be considered by the developer during product design.
Prototyping Model Phases:
Prototyping Model has six SDLC phases as follows
Step-1: Requirements gathering and analysis :
Requirement analysis is the first step in developing a prototyping model.
During this phase, the system’s desires are precisely defined. During the
method, system users are interviewed to determine what they expect from
the system.
Step-2: Quick design :
The second phase could consist of a preliminary design or a quick design.
During this stage, the system’s basic design is formed. However, it is not a
complete design. It provides the user with a quick overview of the system.
The rapid design aids in the development of the prototype.
Step-3: Build a Prototype :
During this stage, an actual prototype is intended to support the knowledge
gained from quick design. It is a small low-level working model of the
desired system.
Step-4: Initial user evaluation :
The proposed system is presented to the client for preliminary testing at
this stage. It is beneficial to investigate the performance model’s strengths
and weaknesses. Customer feedback and suggestions are gathered and
forwarded to the developer.
Step-5: Refining prototype :
If the user is dissatisfied with the current model, you may want to improve
the type that responds to user feedback and suggestions. When the user is
satisfied with the upgraded model, a final system based on the approved
final type is created.
Step-6: Implement Product and Maintain :
The final system was fully tested and distributed to production after it was
developed to support the original version. To reduce downtime and prevent
major failures, the programmer is run on a regular basis.
Types of Prototyping Model:
Four types of Prototyping models are :
1. Rapid Throwaway prototypes
2. Evolutionary prototype
3. Incremental prototype
4. Extreme prototype
1. Rapid Throwaway Prototype :
The preliminary requirement is used for quick throwaway. It is quickly
developed to show how the need will appear visually. Customer feedback
aids in the movement of demand change, and the prototype is re-created
until the need is basic. As a result, the upgraded version is rejected and
cannot be the last accepted type. This programme aids in the testing of
ideas and the rapid response to customer needs.
2. Evolutionary Prototyping :
It assists you in avoiding both time and effort waste. This is due to the fact
that performing a specific type from the start of each method of
communication can be time-consuming. This model is useful for a project
that involves the use of an unknown replacement technology. It is also used
in high-end projects where each feature must be tested only once. It’s
useful when the need isn’t stable or isn’t clearly understood at the start.
3. Incremental Prototyping :
The final product is decimated into small prototypes and developed
individually in incremental prototyping. The various prototypes are
eventually combined into a single product. This method is useful for
reducing feedback time between the user and, consequently, the application
development team.
4. Extreme Prototyping :
The extreme prototyping method is commonly used in web development. It
is divided into three stages that must be completed in order.
1. The HTML format contains a basic prototype of the current page.
 2. A prototype services layer will allow you to simulate data
processes.
3. The services are built and integrated into the final prototype.
Software Prototyping Application :
Software prototyping is extremely beneficial in the development of systems
that require a high level of user interaction, such as online applications.
Systems that require users to fill out forms or view various screens before
data is processed can benefit greatly from prototyping in order to convey
the exact look and feel even before the software is developed. Prototyping
is usually not an option for software that involves a large amount of
information processing and the majority of the functionality is internal with
little programme. Prototype development can be an additional overhead in
such projects and should necessitate a significant amount of additional
effort.
Advantages of Software Prototyping :
• Users help to shape the future. As a result, errors can be
discovered during the first stage of the software development
process.
• Prototyping is also considered a risk reduction function because it
allows non-existent performance to be seen, lowering the risk of
failure.
• Assists team members in effectively communicating.
• Customer satisfaction exists, and he can feel the product from the
start.
• There will be no risk of software loss.
• Quick user feedback aids in the development of better software
solutions.
Disadvantages of Software Prototyping :
• Prototyping is a time-consuming and labor-intensive process.
• The cost of creating a specific type of waste is completely wasted
because the prototype is eventually discarded.
• Prototyping may result in an overabundance of change requests.
• Customers may be unwilling to commit to the iteration cycle for an
extended period of time.
 • During each customer test, there may be too many variations in
software requirements.
• Poor documentation as a result of changing customer needs.
Uses of Software Prototyping Model :
Some of the uses of the software prototyping model include:
1. Requirements gathering: The prototyping model is useful for
gathering and refining requirements for a software product. By
creating a prototype, developers can get feedback from end-users
and stakeholders, which helps to ensure that the software product
meets their needs and requirements.
2. User testing: The prototyping model is useful for testing the
usability and functionality of the software product. By creating a
prototype, developers can get feedback from end-users, which
helps to identify any issues or concerns before the final product is
developed.
3. Risk reduction: The prototyping model can help to reduce the risk
of developing a software product that does not meet the needs of
end-users or stakeholders. By creating a prototype, developers can
identify issues and refine the design before the final product is
developed, which reduces the risk of costly rework and delays.
4. Faster development: The prototyping model can help to speed up
the development process. By creating a prototype, developers can
get feedback and refine the design quickly, which helps to reduce
the time and effort required to develop the final product.
5. Cost reduction: The prototyping model can help to reduce the
overall cost of software development. By identifying issues and
refining the design early on in the development process,
developers can reduce the risk of costly rework and delays, which
can ultimately save time and reduce costs.

Issues of Software Prototyping Model :

1. Incomplete requirements: The prototyping model is designed to
help refine requirements through feedback from end-users.
However, if the initial requirements are incomplete or inaccurate,
 the prototype may not fully meet the needs of the end-users or
stakeholders.
2. Scope creep: Because the prototyping model encourages user
feedback and refinement, it can be susceptible to scope creep. This
can occur when new features or requirements are added to the
project, which can lead to delays and increased costs.
3. Increased development costs: While the prototyping model can
help to reduce the overall cost of software development, it can also
increase costs in the short term. This is because the creation of
prototypes requires time and effort, which can add to the
development costs.
4. Technical debt: The prototyping model can also lead to technical
debt if the prototype is not properly designed or documented. This
can create issues down the line when the final product is
developed, which can lead to delays and increased costs.
5. Lack of scalability: The prototyping model may not be suitable for
large or complex software projects. This is because the focus on
rapid prototyping and user feedback may not be sufficient to
address the complexities of a larger project.

Software documentation :
Software documentation is a written piece of text that is often
accompanied by a software program. This makes the life of all the
members associated with the project easier. It may contain anything from
API documentation, build notes or just help content. It is a very critical
process in software development. It’s primarily an integral part of any
computer code development method.

Types Of Software Documentation:

• Requirement Documentation: It is the description of how the software
shall perform and which environment setup would be appropriate to
 have the best out of it. These are generated while the software is
under development and is supplied to the tester groups too.
• Architectural Documentation: Architecture documentation is a special
type of documentation that concerns the design. It contains very little
code and is more focused on the components of the system, their
roles, and working. It also shows the data flow throughout the
system.
• Technical Documentation: These contain the technical aspects of the
software like API, algorithms, etc. It is prepared mostly for software
developers.
• End-user Documentation: As the name suggests these are made for
the end user. It contains support resources for the end user.

Principles of Software Documentation:

While writing or contributing into any software documentation, one must
keep in mind the following set of 7-principles :

1. Write from reader’s point of view:

It’s important to keep in mind the targeted audience that will be learning,
and working through the software’s documentation to understand and
implement the fully functional robust software application and even the
ones who will be learning for the purpose of using the software. So, while
writing a documentation it becomes very crucial to use the simplest
language & domain related specific languages and terminologies. The
structure of the documentation should be organized in a clearly viewable,
navigable and understandable format.
• If there’s a lot of content, you can organize it in the glossary part at
the end of the document.
• List down synonyms, antonyms and difficult terminologies used.

2. Avoid unnecessary repetition:

While the idea of hyperlinking and backlinking may seem redundant at the
moment, but it aids in avoiding the need of redundancy. The back-end
database stores every piece of information as an individual unit and displays
it in various different variety of context so redundancy at any point will not
be maintainable and is considered a bad practice.
3. Avoid ambiguity:
Documentation contains a lot of information regarding the versatile
functionalities of the software system, every part of it must be written with
clear and precise knowledge while avoiding any conflicting information that
might cause confusion to the reader. For example, if one terminology is used
in different set of context than it must be explicitly defined what it means so
to avoid any miscommunication. This aspect of the software documentation
is very important to avoid any kind of conflicting knowledge between the
stakeholders, developers and the maintainers.
4. Follow a certain standard organization:
In order to maintain the professionalism, accuracy, and precision of the
document a certain set of principles must be followed taking reference from
other software documentations that would aid in organizing and structuring
the content of the documentation in a much productive and organized way.
5. Record a Rationale
Rationale contains a comprehensive understanding of why a certain design
or development decision was made. This part of our documentation is
written & maintained by the developer or the designer itself for justification
and verification for later needs. Rationale can be mentioned in the start or
the end of the document although typically, it’s in the start of the document.
6. Keep the documentation updated but to an extent
This principle applies to the maintainers of the documentation of the
software, because updates are made to the software on frequent intervals.
The updates may contain some bug fixes, new feature addition or previous
functionality maintenance. The maintainer of the documentation must only
add the valuable content and avoid anything that doesn’t fit and irrelevant
for that particular time.
7. Review documentation
The documentation consists of too many web-pages collectively holding a
large chunk of information that’s serving a sole purpose – educate and
spread knowledge to anyone who is trying to understand or implement the
software. While working with a lot of information it is important ta take
feedback from senior architects and make any necessary changes aligning
the documentation with its sole purpose depending on the type of
documentation.
Advantages of software documentation
• The presence of documentation helps in keeping the track of all
aspects of an application and also improves the quality of the
software product.
• The main focus is based on the development, maintenance, and
knowledge transfer to other developers.
• Helps development teams during development.
• Helps end-users in using the product.
• Improves overall quality of software product
• It cuts down duplicative work.
• Makes easier to understand code.
• Helps in establishing internal coordination in work.
Disadvantages of software documentation
• The documenting code is time-consuming.
• The software development process often takes place under time
pressure, due to which many times the documentation updates
don’t match the updated code.
• The documentation has no influence on the performance of an
application.
• Documenting is not so fun, it’s sometimes boring to a certain
extent.

What is Requirement Elicitation?

The process of investigating and learning about a system’s requirements
from users, clients, and other stakeholders is known as requirements
elicitation. Requirements elicitation in software engineering is perhaps the
most difficult, most error-prone, and most communication-intensive
software development.
Requirement Elicitation can be successful only through an effective
customer-developer partnership. It is needed to know what the users
require.
Requirements elicitation involves the identification, collection, analysis,
and refinement of the requirements for a software system.
Requirement Elicitation is a critical part of the software development life
cycle and is typically performed at the beginning of the project.
Requirements elicitation involves stakeholders from different areas of the
organization, including business owners, end-users, and technical experts.
The output of the requirements elicitation process is a set of clear, concise,
and well-defined requirements that serve as the basis for the design and
development of the software system.
Requirements elicitation is difficult because just questioning users and
customers about system needs may not collect all relevant requirements,
particularly for safety and dependability.
Interviews, surveys, user observation, workshops, brainstorming, use
cases, role-playing, and prototyping are all methods for eliciting
requirements.

Importance of Requirements Elicitation

• Compliance with Business Objectives: The process of elicitation

guarantees that the software development endeavors are in
harmony with the wider company aims and objectives.
Comprehending the business context facilitates the development of
a solution that adds value for the company.
• User Satisfaction: It is easier to create software that fulfills end
users’ needs and expectations when they are involved in the
requirements elicitation process. Higher user pleasure and
acceptance of the finished product are the results of this.
• Time and Money Savings: Having precise and well-defined
specifications aids in preventing miscommunication and rework
 during the development phase. As a result, there will be cost
savings and the project will be completed on time.
• Compliance and Regulation Requirements: Requirements elicitation
is crucial for projects in regulated industries to guarantee that the
software conforms with applicable laws and norms. In industries like
healthcare, finance, and aerospace, this is crucial.
• Traceability and Documentation: Throughout the software
development process, traceability is based on well-documented
requirements. Traceability helps with testing, validation, and
maintenance by ensuring that every part of the software can be
linked to a particular requirement.

Requirements Elicitation Activities:

Requirements elicitation includes the subsequent activities. A few of
them are listed below:

Knowledge of the overall area where the systems are applied.

The details of the precise customer problem where the system is going to
be applied must be understood.
Interaction of system with external requirements.
Detailed investigation of user needs.
Define the constraints for system development.
Requirements Elicitation Methods
There are several requirements elicitation methods. A few of them are
listed below:
1. Interviews
The objective of conducting an interview is to understand the customer’s
expectations of the software.
It is impossible to interview every stakeholder hence representatives from
groups are selected based on their expertise and credibility. Interviews may
be open-ended or structured.
1. In open-ended interviews, there is no pre-set agenda. Context-free
questions may be asked to understand the problem.
2. In a structured interview, an agenda of fairly open questions is
prepared. Sometimes a proper questionnaire is designed for the
interview.
2. Brainstorming Sessions
• Brainstorming Sessions is a group technique
• It is intended to generate lots of new ideas hence providing a
platform to share views
• A highly trained facilitator is required to handle group bias and
conflicts.
 • Every idea is documented so that everyone can see it.
• Finally, a document is prepared which consists of the list of
requirements and their priority if possible.
3. Facilitated Application Specification Technique
Its objective is to bridge the expectation gap – the difference between what
the developers think they are supposed to build and what customers think
they are going to get. A team-oriented approach is developed for
requirements gathering. Each attendee is asked to make a list of objects
that are:
1. Part of the environment that surrounds the system.
2. Produced by the system.
3. Used by the system.
Each participant prepares his/her list, different lists are then combined,
redundant entries are eliminated, the team is divided into smaller sub-teams
to develop mini-specifications and finally, a draft of specifications is written
down using all the inputs from the meeting.
4. Quality Function Deployment
In this technique customer satisfaction is of prime concern, hence it
emphasizes the requirements that are valuable to the customer.
3 types of requirements are identified:
• Normal requirements: In this the objective and goals of the
proposed software are discussed with the customer. For example –
normal requirements for a result management system may be entry
of marks, calculation of results, etc.
• Expected requirements: These requirements are so obvious that
the customer need not explicitly state them. Example – protection
from unauthorized access.
• Exciting requirements: It includes features that are beyond
customer’s expectations and prove to be very satisfying when
present. For example – when unauthorized access is detected, it
should back up and shut down all processes.
5. Use Case Approach
Use Case technique combines text and pictures to provide a better
understanding of the requirements.
The use cases describe the ‘what’, of a system and not ‘how’. Hence, they
only give a functional view of the system.
The components of the use case design include three major things – Actor,
use cases, and use case diagram.
1. Actor: It is the external agent that lies outside the system but
interacts with it in some way. An actor may be a person, machine,
etc. It is represented as a stick figure. Actors can be primary actors
or secondary actors.
• Primary actors: It requires assistance from the system to
achieve a goal.
• Secondary actor: It is an actor from which the system
needs assistance.
2. Use cases: They describe the sequence of interactions between
actors and the system. They capture who(actors) do
what(interaction) with the system. A complete set of use cases
specifies all possible ways to use the system.
3. Use case diagram: A use case diagram graphically represents
what happens when an actor interacts with a system. It captures
the functional aspect of the system.
• A stick figure is used to represent an actor.
• An oval is used to represent a use case.
• A line is used to represent a relationship between an actor
and a use case.
The success of an elicitation technique used depends on the maturity of the
analyst, developers, users, and the customer involved.
Steps of Requirements Elicitation

1. Identify Stakeholders
The first step is to figure out who all the key players are in the project.
These are the people who will either use the product, help develop it, or be
impacted by it. This could include users, developers, project managers, and
customers. It’s important to get everyone involved early on, so you gather
all the necessary input and perspectives when defining the requirements.
2. Gather Requirements
Once you’ve identified the stakeholders, the next step is to gather their
requirements. This means understanding what they need from the system
or product. Requirements can be functional (what the system should do) or
non-functional (how it should perform). You can use different methods like
interviews, surveys, or group discussions to collect all these needs.
3. Prioritize Requirements
Not all requirements are equal in terms of importance. After gathering
them, you’ll need to prioritize which ones should be addressed first. This
helps ensure that the most important features are built into the system first,
especially when resources (like time and budget) are limited. A common
approach is to categorize them into things that are “Must-have,” “Should-
have,” “Could-have,” and “Won’t-have.”
4. Categorize Feasibility
After prioritizing, the next step is to assess how realistic each requirement
is. You’ll categorize them into three groups:
• Achievable: These are requirements that are realistic and can be
done within the available resources (time, budget, etc.).
• Deferred: These requirements are important but can’t be
implemented in this phase. They’ll be put on hold for now with a
clear reason why.
• Impossible: These requirements can’t be done because of technical
or other limitations, and they should be removed from the list.

Features of Requirements Elicitation

1. Stakeholder engagement: Requirements elicitation involves
engaging with stakeholders such as customers, end-users, project
sponsors, and subject-matter experts to understand their needs
and requirements.
2. Gathering information: Requirements elicitation involves gathering
information about the system to be developed, the business
processes it will support, and the end-users who will be using it.
3. Requirement prioritization: Requirements elicitation involves
prioritizing requirements based on their importance to the project’s
success.
4. Requirements documentation: Requirements elicitation involves
documenting the requirements clearly and concisely so that they
can be easily understood and communicated to the development
team.
5. Validation and verification: Requirements elicitation involves
validating and verifying the requirements with the stakeholders to
ensure they accurately represent their needs and requirements.
6. Iterative process: Requirements elicitation is an iterative process
that involves continuously refining and updating the requirements
based on feedback from stakeholders.
 7. Communication and collaboration: Requirements elicitation
involves effective communication and collaboration with
stakeholders, project team members, and other relevant parties to
ensure that the requirements are clearly understood and
implemented.
8. Flexibility: Requirements elicitation requires flexibility to adapt to
changing requirements, stakeholder needs, and project constraints.

Advantages of Requirements Elicitation

1. Clear requirements: Helps to clarify and refine customer
requirements.
2. Improves communication: Improves communication and
collaboration between stakeholders.
3. Results in good quality software: Increases the chances of
developing a software system that meets customer needs.
4. Avoids misunderstandings: Avoids misunderstandings and helps
to manage expectations.
5. Supports the identification of potential risks: Supports the
identification of potential risks and problems early in the
development cycle.
6. Facilitates development of accurate plan: Facilitates the
development of a comprehensive and accurate project plan.
7. Increases user confidence: Increases user and stakeholder
confidence in the software development process.
8. Supports identification of new business opportunities: Supports
the identification of new business opportunities and revenue
streams.

Disadvantages of Requirements Elicitation

1. Time-consuming: It can be time-consuming and expensive.
2. Skills required: Requires specialized skills and expertise.
3. Impacted by changing requirements: This may be impacted by
changing business needs and requirements.
 4. Impacted by other factors: Can be impacted by political and
organizational factors.
5. Lack of commitment from stakeholders: This can result in a lack
of buy-in and commitment from stakeholders.
6. Impacted by conflicting priorities: Can be impacted by conflicting
priorities and competing interests.
7. Sometimes inaccurate requirements: This may result in
incomplete or inaccurate requirements if not properly managed.
8. Increased development cost: This can lead to increased
development costs and decreased efficiency if requirements are not
well-defined.

What is Software Requirement Specification (SRS)?

Software requirement specification (SRS) is a complete document or
description of the requirements of a system or software application. In other
words, “SRS is a document that describes what the features of the
software will be and what its behaviour will be, i.e. how it will perform.”
The advantage of SRS is that it takes less time and effort for developers to
develop software. What SRS is is like the layout of the software which the
user can review and see whether it (SRS) is made according to his needs or
not. We learned about software requirement specification, what it is, now
let us read its features.
Importance of Software Requirements Specification (SRS):
1. Clarity and Understanding:
The SRS provides a common communication channel between stakeholders,
so that everyone agrees as to what the project aims at. It reduces ambiguity
and the risks of misunderstandings among team members in clearly
defining requirements.
2. Basis for Project Planning:
The planning for software development projects must be particularly
detailed. The SRS is the required information for project managers to define
realistic timelines, assign appropriate resources and set milestones. It
provides a basis for planning projects, which allows teams to accurately
estimate costs and schedules.
3. Guidance for Development Teams:
The SRS is used to guide developers in their understanding of the functional
specifications and how the software will be designed. The document offers
an overview of the system architecture, user interfaces and data structures
which enable developers to build a system that meets with client
expectations.
4. Facilitates Testing and Quality Assurance:
SRSs are used as references by quality assurance and testing teams, which
use them to design test cases verifying that the software conforms with
what was specified. Because testing has well-specified requirements, it
becomes much more of a systematic procedure and the chance that an
important functionality is overlooked are reduced.
5. Change Management:
During projects, changes are unavoidable. The SRS thus provides a baseline
from which any proposed changes can be judged. This guarantees that
changes are thoroughly recorded, approved and properly implemented--
without scope creep.
6. Client and Stakeholder Satisfaction:
The SRS is a contract between the development team and their client or
stakeholders. This boosts client satisfaction and trust if the final product
meets what was documented. Moreover, such clear documentation provides
a foundation for resolving disputes or disagreements over the course of
development.
7. Risk Mitigation:
The earlier in the software development life cycle you can spot potential
risks, the better. The SRS helps in risk assessment by specifying
dependencies, constraints and possible risks. This makes the development
process smoother for project managers who can then come up with
strategies to prevent risk.
8. Enhanced Collaboration:
Software development requires collaboration. The SRS has team spirit
Working together with cross-functional teams, it forms a single vision and
shared understanding of the project. As a result, the development process
becomes more integrated and efficient.
Characteristics of Software Requirements Specification (SRS):
• Complete: The SRS should be complete i.e. all the software
requirements should be mentioned in the SRS.
• Correct: It should be correct i.e. it should be according to the needs
of the customer.
• Clear: It should be clear. The requirements of the software should
be clearly declared.
• Accurate: It should have accuracy. If this is not accurate then the
software cannot be developed.
• Consistent: It should be consistent from beginning to end so that
users can easily understand the requirements. And consistency can
be achieved only when there is no contradiction between the two
requirements.
• Verifiable: It should be verifiable. The requirements are verified by
experts and testers.
• Modifiable: All the requirements specified in the SRS document
should be modifiable. This can happen only when the structure of
SRS is balanced.
• Traceable: It should be traceable, that is, each requirement in it
should be identified differently. Each requirement should have its
own identity.
• Testable: It should be testable i.e. it should be capable of being
tested in any way.
• Unambiguous: It can be unambiguous only when all the
requirements have only one meaning. That is, there should be only
one interpretation.

Software Requirement Specification (SRS) Format as the name suggests,

is a complete specification and description of requirements of the software
that need to be fulfilled for the successful development of the software
system. These requirements can be functional as well as non-functional
depending upon the type of requirement. The interaction between different
customers and contractors is done because it is necessary to fully understand

the needs of customers.

Depending upon information gathered after interaction, SRS is developed
which describes requirements of software that may include changes and
modifications that is needed to be done to increase quality of product and to
satisfy customer’s demand.
Introduction
• Purpose of this Document – At first, main aim of why this
document is necessary and what’s purpose of document is
explained and described.
• Scope of this document – In this, overall working and main
objective of document and what value it will provide to customer is
described and explained. It also includes a description of
development cost and time required.
• Overview – In this, description of product is explained. It’s simply
summary or overall review of product.
General description
In this, general functions of product which includes objective of user, a user
characteristic, features, benefits, about why its importance is mentioned. It
also describes features of user community.
Functional Requirements
In this, possible outcome of software system which includes effects due to
operation of program is fully explained. All functional requirements which
may include calculations, data processing, etc. are placed in a ranked order.
Functional requirements specify the expected behavior of the system-which
outputs should be produced from the given inputs. They describe the
relationship between the input and output of the system. For each functional
requirement, detailed description all the data inputs and their source, the
units of measure, and the range of valid inputs must be specified.
Interface Requirements
In this, software interfaces which mean how software program
communicates with each other or users either in form of any language, code,
or message are fully described and explained. Examples can be shared
memory, data streams, etc.
Performance Requirements
In this, how a software system performs desired functions under specific
condition is explained. It also explains required time, required memory,
maximum error rate, etc. The performance requirements part of an SRS
specifies the performance constraints on the software system. All the
requirements relating to the performance characteristics of the system must
be clearly specified. There are two types of performance requirements: static
and dynamic. Static requirements are those that do not impose constraint on
the execution characteristics of the system. Dynamic requirements specify
constraints on the execution behaviour of the system.
Design Constraints
In this, constraints which simply means limitation or restriction are specified
and explained for design team. Examples may include use of a particular
algorithm, hardware and software limitations, etc. There are a number of
factors in the client’s environment that may restrict the choices of a designer
leading to design constraints such factors include standards that must be
followed resource limits, operating environment, reliability and security
requirements and policies that may have an impact on the design of the
system. An SRS should identify and specify all such constraints.
Non-Functional Attributes
In this, non-functional attributes are explained that are required by software
system for better performance. An example may include Security, Portability,
Reliability, Reusability, Application compatibility, Data integrity, Scalability
capacity, etc.
Preliminary Schedule and Budget
In this, initial version and budget of project plan are explained which include
overall time duration required and overall cost required for development of
project.
Appendices
In this, additional information like references from where information is
gathered, definitions of some specific terms, acronyms, abbreviations, etc. are
given and explained.
Uses of SRS document
• Development team require it for developing product according to
the need.
• Test plans are generated by testing group based on the describe
external behaviour.
• Maintenance and support staff need it to understand what the
software product is supposed to do.
• Project manager base their plans and estimates of schedule, effort
and resources on it.
• customer rely on it to know that product they can expect.
• As a contract between developer and customer.
• in documentation purpose.

3Ps (people, product and process) :

In software engineering, the “3 Ps” – People, Product, and Process –
represent key areas that must be aligned and managed effectively to
ensure successful project outcomes. These three elements are
interconnected and influence each other, so understanding their roles and
how they relate is crucial for building high-quality software.

1.People:
Definition:
This refers to the human resources involved in the software development
project, including developers, testers, project managers, and stakeholders.
Importance:
People are the most critical asset in software development, and their
skills, experience, and collaboration are essential for building successful
software.
Focus:
Investing in the right people with the right skills, fostering a positive and
collaborative team environment, and providing them with the necessary
tools and support are key to success.

2.Product:
Definition:
This refers to the software being developed and the end result of the
project.
Importance:
The product is what the software development team is building, and its
quality, functionality, and user experience are all critical for its success.
Focus:
Clearly defining the product’s requirements, conducting thorough testing
and quality assurance, and incorporating user feedback throughout the
development process are essential for delivering a successful product.

3.Process:
Definition:
This refers to the methods, procedures, and workflows used to develop
the software.
Importance:
The process is the framework that guides the development team, ensuring
that the project stays on track, and that all aspects of the project are
managed effectively.
Focus:
Choosing the right development methodology (e.g., Agile, Waterfall),
defining clear roles and responsibilities, establishing effective
communication channels, and continuously improving the process are key
to success.

Software project estimation:

What is Project Size Estimation?
Project size estimation is determining the scope and resources required for
the project.
1. It involves assessing the various aspects of the project to estimate
the effort, time, cost, and resources needed to complete the project.
2. Accurate project size estimation is important for effective and
efficient project planning, management, and execution.
Importance of Project Size Estimation
Here are some of the reasons why project size estimation is critical in
project management:
1. Financial Planning: Project size estimation helps in planning the
financial aspects of the project, thus helping to avoid financial
shortfalls.
2. Resource Planning: It ensures the necessary resources are
identified and allocated accordingly.
3. Timeline Creation: It facilitates the development of realistic
timelines and milestones for the project.
4. Identifying Risks: It helps to identify potential risks associated with
overall project execution.
5. Detailed Planning: It helps to create a detailed plan for the project
execution, ensuring all the aspects of the project are considered.
6. Planning Quality Assurance: It helps in planning quality assurance
activities and ensuring that the project outcomes meet the required
standards.
Estimating the Size of the Software
Estimation of the size of the software is an essential part of Software
Project Management. It helps the project manager to further predict the
effort and time that will be needed to build the project. Here are some of
the measures that are used in project size estimation:

1. Lines of Code (LOC)

As the name suggests, LOC counts the total number of lines of source code
in a project. The units of LOC are:
1. KLOC: Thousand lines of code
2. NLOC: Non-comment lines of code
3. KDSI: Thousands of delivered source instruction

Features of Lines of Code (LOC)

• Change Tracking: Variations in LOC as time passes can be tracked to
analyze the growth or reduction of a codebase, providing insights
into project progress.
• Limited Representation of Complexity: Despite LOC provides a
general idea of code size, it does not accurately depict code
complexity. It is possible for two programs having the same LOC to
be incredibly complex.
• Ease of Computation: LOC is an easy measure to obtain because it is
easy to calculate and takes little time.
• Easy to Understand: The idea of expressing code size in terms of
lines is one that stakeholders, even those who are not technically
inclined, can easily understand.
• Lines of Code (LOC) measures the volume of code by counting all
non-comment and non-blank lines, including variable declarations
and statements. It helps track codebase growth and is easy to
compute and understand. However, it does not reflect code
complexity and is best used for comparing projects in the same
language and coding standards.
Advantages of Lines of Code (LOC)
• Effort Estimation: LOC is occasionally used to estimate development
efforts and project deadlines at a high level. Although caution is
necessary, project planning can begin with this.
• Comparative Analysis: High-level productivity comparisons between
several projects or development teams can be made using LOC. It
might provide an approximate figure of the volume of code
generated over a specific time frame.
• Benchmarking Tool: When comparing various iterations of the same
program, LOC can be used as a benchmarking tool. It may bring
information on how modifications affect the codebase’s total size.

Disadvantages of Lines of Code (LOC)

• Challenges in Agile Work Environments: Focusing on initial LOC
estimates may not adequately reflect the iterative and dynamic
nature of development in agile development, as requirements may
change.
• Not Considering Into Account External Libraries: Code from other
libraries or frameworks, which can greatly enhance a project’s overall
usefulness, is not taken into account by LOC.
• Challenges with Maintenance: Higher LOC codebases are larger
codebases that typically demand more maintenance work.

2. Functional Point Analysis

Function Point Analysis was initially developed by Allan J. Albrecht in
1979 at IBM and has been further modified by the International Function
Point User’s Group (IFPUG) in 1984, to clarify rules, establish standards,
and encourage their use and evolution. Allan J. Albrecht gave the initial
definition, Functional Point Analysis gives a dimensionless number defined
in function points which we have found to be an effective relative measure
of function value delivered to our customer. A systematic approach to
measuring the different functionalities of a software application is offered
by function point metrics. Function point metrics evaluate functionality from
the perspective of the user, that is, based on the requests and responses
they receive.
Objectives of Functional Point Analysis
1. Encourage Approximation: FPA helps in the estimation of the
work, time, and materials needed to develop a software project.
Organizations can plan and manage projects more accurately when
a common measure of functionality is available.
2. To assist with project management: Project managers can monitor
and manage software development projects with the help of FPA.
Managers can evaluate productivity, monitor progress, and make
well-informed decisions about resource allocation and project
timeframes by measuring the software’s functional points.
3. Comparative analysis: By enabling benchmarking, it gives
businesses the ability to assess how their software projects
measure up to industry standards or best practices in terms of size
and complexity. This can be useful for determining where
improvements might be made and for evaluating how well
development procedures are working.
4. Improve Your Cost-Benefit Analysis: It offers a foundation for
assessing the value provided by the program concerning its size
and complexity, which helps with cost-benefit analysis. Making
educated judgements about project investments and resource
allocations can benefit from having access to this information.
5. Comply with Business Objectives: It assists in coordinating
software development activities with an organization’s business
objectives. It guarantees that software development efforts are
directed toward providing value to end users by concentrating on
user-oriented functionality.
Types of Functional Point Analysis
There are two types of Functional Point Analysis:
1. Transactional Functional Type
• External Input (EI): EI processes data or control information that
comes from outside the application’s boundary. The EI is an
elementary process.
• External Output (EO): EO is an elementary process that generates
data or control information sent outside the application’s
boundary.
• External Inquiries (EQ): EQ is an elementary process made up of
an input-output combination that results in data retrieval.
2. Data Functional Type
• Internal Logical File (ILF): A user-identifiable group of logically
related data or control information maintained within the boundary
of the application.
• External Interface File (EIF): A group of users recognizable
logically related data allusion to the software but maintained
within the boundary of another software
Benefits of Functional Point Analysis
Following are the benefits of Functional Point Analysis:
1. Technological Independence: It calculates a software system’s
functional size independent of the underlying technology or
programming language used to implement it. As a result, it is a
technology-neutral metric that makes it easier to compare projects
created with various technologies.
2. Better Accurate Project Estimation: It helps to improve project
estimation accuracy by measuring user interactions and functional
needs. Project managers can improve planning and budgeting by
using the results of the FPA to estimate the time, effort and
resources required for development.
 3. Improved Interaction: It provides a common language for business
analysts, developers, and project managers to communicate with
one another and with other stakeholders. By communicating the
size and complexity of software in a way that both technical and
non-technical audiences can easily understand this helps close the
communication gap.
4. Making Well-Informed Decisions: FPA assists in making well-
informed decisions at every stage of the software development life
cycle. Based on the functional requirements, organizations can use
the results of the FPA to make decisions about resource allocation,
project prioritization, and technology selection.
5. Early Recognition of Changes in Scope: Early detection of changes
in project scope is made easier with the help of FPA. Better scope
change management is made possible by the measurement of
functional requirements, which makes it possible to evaluate
additions or changes for their effect on the project’s overall size.
Disadvantage of Functional Point Analysis
Given below are some disadvantages of Functional Point Analysis:
1. Subjective Judgement: One of the main disadvantages of
Functional Point Analysis is it’s dependency on subjective
judgement i.e. relying on personal opinions and interpretations
instead of just using clear, measurable standards.
2. Low Accuracy: It has low evaluation accuracy as it’s dependency
on subjective judgement.
3. Time Consuming: Functional Point Analysis is a time consuming
process, particularly during the initial stages of implementation.
4. Steep Learning Curve: Learning FPA can be challenging due to its
complexity and the length of time required to gain proficiency.
5. Less Research Data: Compared to LOC-based metrics, there is
relatively less research data available on function points.
6. Costly: The need for thorough analysis and evaluation can result in
increased project timelines and associated costs.
 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.

COCOMO Model is a procedural cost estimate model for Software

Projects and is often used as a process of reliably predicting the various
parameters associated with making a project such as size, effort, cost, time,
and quality.
The key parameters that define the quality of any Software Product, which
are also an outcome of COCOMO, are primarily effort and schedule.

Types of Projects in COCOMO Model

In the COCOMO model, software projects are categorized into three types
based on their complexity, size, and the development environment. These
types are:
1. Organic
A software project is said to be an organic type if the team size required is
adequately small, the problem is well understood and has been solved in
the past and also the team members have a nominal experience regarding
the problem.
2. Semi-detached
A software project is said to be a Semi-detached type if the vital
characteristics such as team size, experience, and knowledge of the various
programming environments lie in between organic and embedded.
3. Embedded
A software project requiring the highest level of complexity, creativity, and
experience requirement falls under this category. Such software requires a
larger team size than the other two models and also the developers need to
be sufficiently experienced and creative to develop such complex models.

Structure of COCOMO Model

Detailed COCOMO incorporates all characteristics of the intermediate
version with an assessment of the cost driver’s impact on each step of
the Software Engineering Process.

The Six phases of detailed COCOMO are:

 Phases of COCOMO Model

1. Planning and requirements: This initial phase involves defining

the scope, objectives, and constraints of the project. It includes
developing a project plan that outlines the schedule, resources, and
milestones
2. System design: : In this phase, the high-level architecture of the
software system is created. This includes defining the system’s
overall structure, including major components, their interactions,
and the data flow between them.
3. Detailed design: This phase involves creating detailed
specifications for each component of the system. It breaks down
the system design into detailed descriptions of each module,
including data structures, algorithms, and interfaces.
4. Module code and test: This involves writing the actual source code
for each module or component as defined in the detailed design. It
includes coding the functionalities, implementing algorithms, and
developing interfaces.
5. Integration and test: This phase involves combining individual
modules into a complete system and ensuring that they work
together as intended.
6. Cost Constructive model: The Constructive Cost Model
(COCOMO) is a widely used method for estimating the cost and
effort required for software development projects.

Importance of the COCOMO Model

1. Cost Estimation: To help with resource planning and project
budgeting, COCOMO offers a methodical approach to software
development cost estimation.
2. Resource Management: By taking team experience, project size,
and complexity into account, the model helps with efficient
resource allocation.
 3. Project Planning: COCOMO assists in developing practical project
plans that include attainable objectives, due dates, and
benchmarks.
4. Risk management: Early in the development process, COCOMO
assists in identifying and mitigating potential hazards by including
risk elements.
5. Support for Decisions: During project planning, the model
provides a quantitative foundation for choices about scope,
priorities, and resource allocation.
6. Benchmarking: To compare and assess various software
development projects to industry standards, COCOMO offers a
benchmark.
7. Resource Optimization: The model helps to maximize the use of
resources, which raises productivity and lowers costs.

Types of COCOMO Model

There are three types of COCOMO Model:

1. Basic COCOMO Model

The Basic COCOMO model is a straightforward way to estimate the effort
needed for a software development project. It uses a simple mathematical
formula to predict how many person-months of work are required based on
the size of the project, measured in thousands of lines of code (KLOC).
It estimates effort and time required for development using the following
expression:
E = a*(KLOC)b PM
Tdev = c*(E)d
Person required = Effort/ Time
Where,
E is effort applied in Person-Months
KLOC is the estimated size of the software product indicate in Kilo Lines of
Code
Tdev is the development time in months
a, b, c are constants determined by the category of software project

2.The Intermediate COCOMO model is an extension of the Basic COCOMO model,

aiming for more accurate software cost estimation by incorporating "cost drivers" .
Intermediate COCOMO Model equation:
E = a*(KLOC)b * EAF PM
Tdev = c*(E)d
Where,
• E is effort applied in Person-Months
• KLOC is the estimated size of the software product indicate in Kilo
Lines of Code
• EAF is the Effort Adjustment Factor (EAF) is a multiplier used to
refine the effort estimate obtained from the basic COCOMO model.
• Tdev is the development time in months
• a, b, c are constants determined by the category of software project

3. Detailed COCOMO Model

Detailed COCOMO goes beyond Basic and Intermediate COCOMO by diving
deeper into project-specific factors. It considers a wider range of
parameters, like team experience, development practices, and software
complexity. By analyzing these factors in more detail, Detailed COCOMO
provides a highly accurate estimation of effort, time, and cost for software
projects.
Advantages of the COCOMO Model
1. Systematic cost estimation: Provides a systematic way to estimate
the cost and effort of a software project.
2. Helps to estimate cost and effort: This can be used to estimate
the cost and effort of a software project at different stages of the
development process.
3. Helps in high-impact factors: Helps in identifying the factors that
have the greatest impact on the cost and effort of a software
project.
4. Helps to evaluate the feasibility of a project: This can be used to
evaluate the feasibility of a software project by estimating the cost
and effort required to complete it.
Disadvantages of the COCOMO Model
1. Assumes project size as the main factor: Assumes that the size of
the software is the main factor that determines the cost and effort
of a software project, which may not always be the case.
2. Does not count development team-specific characteristics: Does
not take into account the specific characteristics of the
development team, which can have a significant impact on the cost
and effort of a software project.
3. Not enough precise cost and effort estimate: This does not
provide a precise estimate of the cost and effort of a software
project, as it is based on assumptions and averages.

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

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

• 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

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.
 COCOMO I COCOMO II

COCOMO I is useful in the waterfall COCOMO II is useful in non-sequential,

models of the software development rapid development and reuse models of
cycle. software.

It provides estimates that represent one

It provides estimates of effort and
standard deviation around the most likely
schedule.
estimate.

This model is based upon the linear This model is based upon the non linear
reuse formula. reuse formula

This model is also based upon the This model is also based upon reuse model
assumption of reasonably stable which looks at effort needed to understand
requirements. and estimate.

Effort equation’s exponent is

Effort equation’s exponent is determined by
determined by 3 development
5 scale factors.
modes.

Development begins with the

requirements assigned to the It follows a spiral type of development.
software.

Number of submodels in COCOMO I In COCOMO II, Number of submodel are 4

is 3 and 15 cost drivers are assigned and 17 cost drivers are assigned
 COCOMO I COCOMO II

Size of software stated in terms of Size of software stated in terms of Object

Lines of code points, function points and lines of code

What is Risk?

In project management, a risk is any uncertain event or condition that, if it

occurs, can have a positive or negative impact on the project's objectives. It's
essentially an unexpected event that could disrupt the project, potentially
causing delays, cost overruns, or even project failure.

Risk Identification, Risk Assessment, and Risk Projection, which are key components of risk
management in projects or systems:

1. Risk Identification

Risk identification is the initial and crucial step in risk management, focusing on
spotting and documenting potential threats that could hinder an organization's or
project's success. It's a systematic process of pinpointing risks arising from internal
and external factors, ensuring a comprehensive understanding of potential challenges.

This is the process of identifying potential risks that could affect a project, system, or process. It
involves:

• Brainstorming possible threats (e.g., technical failures, budget overruns, staff

shortages).
• Documenting all possible risks.
• Using tools like SWOT analysis, checklists, and expert interviews.

Goal: To list and describe all risks that could potentially impact objectives.

2. Risk Assessment

Risk assessment simply means to describe the overall process or method to identify risk and
problem factors that might cause harm. It is a systematic examination of a task or project that
you perform to simply identify significant risks, problems, and hazards, and then to find out
control measures that you will take to reduce risk.

Once risks are identified, they are evaluated in terms of their likelihood and impact. This step
includes:

• Categorizing risks (e.g., low, medium, high).

• Prioritizing based on severity.
• Often involves qualitative or quantitative analysis.

Goal: To understand the seriousness of each risk and focus attention on the most significant
ones.

3. Risk Projection (or Risk Estimation)

Risk projection in software engineering is a proactive process of identifying,

analyzing, and estimating the potential impact of risks on a project. It involves
assessing the likelihood of risks occurring and the consequences should they
occur. This helps teams develop mitigation plans and proactively address
potential issues, ultimately increasing the likelihood of project success.

This step predicts the future impact of identified risks. It includes:

• Estimating probability of occurrence.

• Evaluating the potential consequences.
• Modeling risk exposure (e.g., Risk Exposure = Probability × Impact).

Goal: To forecast the effects of risks and help with decision-making on mitigation strategies

RMMM Plan :
A risk management technique is usually seen in the software Project plan.
This can be divided into Risk Mitigation, Monitoring, and Management Plan
(RMMM). In this plan, all works are done as part of risk analysis.

Risk Mitigation :
It is an activity used to avoid problems (Risk Avoidance).
Steps for mitigating the risks as follows.
1. Finding out the risk.
2. Removing causes that are the reason for risk creation.
3. Controlling the corresponding documents from time to time.
 4. Conducting timely reviews to speed up the work.

Risk Monitoring :
It is an activity used for project tracking.
It has the following primary objectives as follows.

1. To check if predicted risks occur or not.

2. To ensure proper application of risk aversion steps defined for risk.
3. To collect data for future risk analysis.
4. To allocate what problems are caused by which risks throughout
the project.

Risk Management :
Risk Management is a systematic process of recognizing, evaluating, and
handling threats or risks that have an effect on the finances, capital, and
overall operations of an organization. These risks can come from different
areas, such as financial instability, legal issues, errors in strategic planning,
accidents, and natural disasters.
The main goal of risk management is to predict possible risks and find
solutions to deal with them successfully.

Software Configuration Management (SCM) process:

SCM Process Steps

1Configuration Identification

• Define what needs to be managed (e.g., source code, documentation, design

files).
• Assign unique identifiers (e.g., version numbers).
• Create a Configuration Item (CI) list.

2.Configuration Control
 • Establish a change control process to approve or reject changes.
• Use tools to track change requests and enforce approvals.
• Version Control
• Maintain multiple versions and revisions of software artifacts.
• Ensure safe collaboration using tools like Git, SVN, etc.
• Configuration Status Accounting
• Record and report the current state of configuration items.
• Maintain logs of what has changed, when, and by whom.
• Configuration Audits and Reviews
• Ensure changes are properly implemented.
• Verify that the system is consistent with documentation and requirements.

In software engineering, an SCM (Software Configuration Management)

repository is a centralized storage space for managing software components,
including source code, documentation, and configuration files. It acts as a
record of all changes made to the software throughout its development
lifecycle, allowing developers to track and manage those changes efficiently.

• .Centralized Storage:
o The repository serves as a single source of truth for all software artifacts,
ensuring that everyone is working with the same version of the code and
other related files.
o .Version Control:
o It tracks changes to all files, allowing developers to revert to previous
versions, compare different versions, and merge changes from different
branches.
• Collaboration:
o SCM repositories facilitate collaboration among developers by enabling them
to work on different parts of the code simultaneously, track changes, and
resolve conflicts.
• Change Management:
 o It provides a way to manage changes to the software, ensuring that changes
are properly documented, reviewed, and tested before being integrated into
the main codebase.
• Data Integrity:
o The repository ensures that all files are stored in a consistent and reliable
format, reducing the risk of data loss or corruption.
• Communication:
o It can be used to communicate changes and issues among developers and
other stakeholders.

Benefits of using an SCM Repository:

• Improved code quality:
o By tracking changes and facilitating collaboration, SCM repositories help
developers identify and fix bugs more effectively.
• Increased productivity:
o SCM repositories automate many tasks related to version control and
change management, freeing up developers to focus on coding.
• Reduced risk of errors:
o By providing a history of changes, SCM repositories make it easier to identify
and fix errors introduced by developers.
• Better collaboration:
o SCM repositories facilitate collaboration among developers by providing a
shared space for working on code and tracking changes.
• Easier maintenance:
SCM repositories make it easier to maintain and update the software, as it provides
a record of all changes made to the code.

Importance of Software Configuration Management

1. Effective Bug Tracking: Linking code modifications to issues that
have been reported, makes bug tracking more effective.
 2. Continuous Deployment and Integration: SCM combines with
continuous processes to automate deployment and testing,
resulting in more dependable and timely software delivery.
3. Risk management: SCM lowers the chance of introducing critical
flaws by assisting in the early detection and correction of
problems.
4. Support for Big Projects: Source Code Control (SCM) offers an
orderly method to handle code modifications for big projects,
fostering a well-organized development process.
5. Reproducibility: By recording precise versions of code, libraries, and
dependencies, source code versioning (SCM) makes builds
repeatable.
6. Parallel Development: SCM facilitates parallel development by
enabling several developers to collaborate on various branches at
once.

Why need for System configuration management?

1. Replicability: Software version control (SCM) makes ensures that a
software system can be replicated at any stage of its development.
This is necessary for testing, debugging, and upholding consistent
environments in production, testing, and development.
2. Identification of Configuration: Source code, documentation, and
executable files are examples of configuration elements that SCM
helps in locating and labeling. The management of a system’s
constituent parts and their interactions depend on this
identification.
3. Effective Process of Development: By automating monotonous
processes like managing dependencies, merging changes, and
resolving disputes, SCM simplifies the development process. Error
risk is decreased and efficiency is increased because of this
automation.
Key objectives of SCM
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
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
were 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.
The main disadvantages of SCM
1. Increased complexity and overhead, particularly in large software
systems.
2. Difficulty in managing dependencies and ensuring that all changes
are properly integrated.
 3. Potential for conflicts and delays, particularly in large development
teams with multiple contributors.

Software Quality Assurance (SQA) is simply a way to assure quality in the

software. It is the set of activities that ensure processes, procedures as well
as standards are suitable for the project and implemented correctly.
Software Quality Assurance is a process that works parallel to Software
Development. It focuses on improving the process of development of
software so that problems can be prevented before they become major
issues. Software Quality Assurance is a kind of Umbrella activity that is
applied throughout the software process.

Elements of Software Quality Assurance (SQA)

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 that 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.

Software Quality Assurance (SQA) focuses

The Software Quality Assurance (SQA) focuses on the following

• Software’s portability: Software’s portability refers to its ability to

be easily transferred or adapted to different environments or
 platforms without needing significant modifications. This ensures
that the software can run efficiently across various systems,
enhancing its accessibility and flexibility.
• software’s usability: Usability of software refers to how easy and
intuitive it is for users to interact with and navigate through the
application. A high level of usability ensures that users can
effectively accomplish their tasks with minimal confusion or
frustration, leading to a positive user experience.
• software’s reusability: Reusability in software development
involves designing components or modules that can be reused in
multiple parts of the software or in different projects. This
promotes efficiency and reduces development time by eliminating
the need to reinvent the wheel for similar functionalities, enhancing
productivity and maintainability.
• software’s correctness: Correctness of software refers to its ability
to produce the desired results under specific conditions or inputs.
Correct software behaves as expected without errors or
unexpected behaviors, meeting the requirements and specifications
defined for its functionality.
• software’s maintainability: Maintainability of software refers to
how easily it can be modified, updated, or extended over time.
Well-maintained software is structured and documented in a way
that allows developers to make changes efficiently without
introducing errors or compromising its stability.
• software’s error control: Error control in software involves
implementing mechanisms to detect, handle, and recover from
errors or unexpected situations gracefully. Effective error control
ensures that the software remains robust and reliable, minimizing
disruptions to users and providing a smoother experience overall.
Software Quality Assurance (SQA) Include
1. A quality management approach.
2. Effective software engineering technology (methods and tools).
3. Some formal technical reviews are applied throughout the software
process.
 4. A multi-tiered testing strategy.
5. Controlling software documentation and the changes made to it.
6. Procedure to ensure compliance with software development
standards (when applicable).
7. Measurement and reporting mechanisms.

Major Software Quality Assurance (SQA) 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. Maintaining records and reports: Comprehensively document and
share all QA records, including test cases, defects, changes, and
cycles, for stakeholder awareness and future reference.
7. Reviews software engineering activities: The SQA group
identifies and documents the processes. The group also verifies the
correctness of software product.
 8. Formalize deviation handling: Track and document software
deviations meticulously. Follow established procedures for
handling variances.
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.
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 Software Quality Assurance (SQA)
There are a number of disadvantages of quality assurance.
• Cost: Some of them include adding more resources, which cause
the more budget its not, Addition of more resources For betterment
of the product.
• Time Consuming: Testing and Deployment of the project taking
more time which cause delay in the project.
• Overhead : SQA processes can introduce administrative overhead,
requiring documentation, reporting, and tracking of quality metrics.
This additional administrative burden can sometimes outweigh the
benefits, especially for smaller projects.
• Resource Intensive : SQA requires skilled personnel with expertise
in testing methodologies, tools, and quality assurance practices.
Acquiring and retaining such talent can be challenging and
expensive.
 • Resistance to Change : Some team members may resist the
implementation of SQA processes, viewing them as bureaucratic or
unnecessary. This resistance can hinder the adoption and
effectiveness of quality assurance practices within an organization.
• Not Foolproof : Despite thorough testing and quality assurance
efforts, software can still contain defects or vulnerabilities. SQA
cannot guarantee the elimination of all bugs or issues in software
products.
• Complexity : SQA processes can be complex, especially in large-
scale projects with multiple stakeholders, dependencies, and
integration points. Managing the complexity of quality assurance
activities requires careful planning and coordination.

What is a Software Quality Assurance Plan?

A Quality Assurance Plan (QAP) is a document or set of documents that
outlines the systematic processes, procedures, and standards for ensuring
the quality of a product or service. It is a key component of quality
management and is used in various industries to establish and maintain a
consistent level of quality in deliverables. For a software product or service,
an SQA plan will be used in conjunction with the typical development,
prototyping, design, production, and release cycle. An SQA plan will include
several components, such as purpose, references, configuration and
management, tools, code controls, testing methodology, problem reporting
and remedial measures, and more, for easy documentation and referencing.
Importance of Software Quality Assurance Plan
• Quality Standards and Guidelines: The SQA Plan lays
out the requirements and guidelines to make sure the
programme satisfies predetermined standards for quality.
• Risk management: It is the process of recognizing,
evaluating and controlling risks in order to reduce the
possibility of errors and other problems with quality.
• Standardization and Consistency: The strategy
guarantees consistent methods, processes, and
procedures, fostering a unified and well-structured
approach to quality assurance.
• Customer Satisfaction: The SQA Plan helps to ensure
that the finished product satisfies customer needs, which
in turn increases overall customer satisfaction.
• Resource optimization: It is the process of defining roles,
responsibilities, and procedures in order to maximize
resource utilization and minimize needless rework.
• Early Issue Detection: SQA Plans help identify problems
early on, which lowers the expense and work involved in
fixing them.

Objectives And Goals of Software Quality Assurance

Plan:
The objectives and goals of a Quality Assurance Plan (QAP) are to
ensure that the products or services meet specified quality
standards and requirements. The plan serves as a roadmap for
implementing quality assurance processes throughout a project or
organizational activity. The specific objectives and goals can vary
depending on the nature of the project or industry, but common
elements include:
Compliance with Standards and Regulations:
• Objective: Ensure that the project or product
complies with relevant industry standards,
 regulatory requirements, and any other
applicable guidelines.
Customer Satisfaction:
• Objective: Enhance customer satisfaction by delivering
products or services that meet or exceed customer
expectations.

Defect Prevention:
• Objective: Implement measures to prevent defects, errors,
or issues in the early stages of the project lifecycle.

Consistency and Reliability:

• Objective: Establish a consistent and reliable process for
the development or delivery of products and services.

Process Improvement:
• Objective: Continuously improve processes to enhance
efficiency, effectiveness, and overall quality.

Risk Management:
• Objective: Identify and manage risks that could impact the
quality of the project or product.

Clear Roles and Responsibilities:

• Objective: Clearly define roles and responsibilities related
to quality assurance activities.

Documentation and Traceability:

• Objective: Establish a robust documentation process to
track and trace quality-related activities and decisions.
Training and Competence:
• Objective: Ensure that team members are adequately
trained and possess the necessary competencies to
perform quality assurance tasks.

Continuous Monitoring and Reporting:

• Objective: Monitor quality metrics and report on the
status of quality assurance activities.

Steps to Develop Software Quality Assurance Plan:

Developing a Quality Assurance Plan (QAP) involves a systematic
process to ensure that the plan effectively addresses the quality
requirements of a project or process. Here are the steps to develop
a Quality Assurance Plan:
Define Project Objectives and Scope:
• Clearly articulate the objectives and scope of the project
or process for which the Quality Assurance Plan is being
developed. Understand the goals, deliverables, and
stakeholders involved.
Identify Quality Standards and Criteria:
• Determine the relevant quality standards, regulations, and
criteria that are applicable to the project. This may include
industry standards, legal requirements, and internal
organizational standards.
Identify Stakeholders:
• Identify and involve key stakeholders who have an interest
in or will be affected by the quality of the project or
process. This includes project managers, team members,
customers, and any regulatory bodies.
Define Roles and Responsibilities:
• Clearly define the roles and responsibilities of individuals
or teams involved in quality assurance activities. This
 ensures accountability and clarity in the execution of
quality-related tasks.
Conduct a Risk Assessment:
• Identify potential risks to the quality of the project. Assess
the impact and likelihood of these risks and develop
strategies for risk mitigation and management.
Establish Quality Assurance Activities:
• Determine the specific activities and tasks that will be
carried out to ensure quality throughout the project
lifecycle. This may include reviews, inspections, audits,
testing, and other quality control measures.
Develop Testing and Inspection Procedures:
• If applicable, create detailed testing and inspection
procedures. This includes developing test plans, test
cases, and acceptance criteria to ensure that the product
or service meets quality standards.
Document Processes and Procedures:
• Document the processes and procedures that will be
followed to implement quality assurance activities. This
documentation serves as a reference for team members
and provides a basis for consistency.
Establish Documentation and Reporting Mechanisms:
• Define the documentation requirements for tracking and
reporting quality-related information. This may include
reports, checklists, and records of quality assessments.
Allocate Resources and Training:
• Specify the resources, tools, and training that will be
provided to team members to support quality assurance
efforts. Ensure that team members have the necessary
skills and knowledge.
Define Change Control Processes:
• Establish a process for managing changes to the project or
product to ensure that they do not negatively impact
 quality. This includes a change control board and a
structured process for reviewing and approving changes.
Review and Approval:
• Seek input and feedback from relevant stakeholders on
the draft Quality Assurance Plan. Revise the plan based
on feedback and obtain formal approval before
implementation.
Monitoring and Continuous Improvement:
• Continuously monitor quality metrics, track progress, and
identify opportunities for improvement. Regularly review
and update the Quality Assurance Plan to adapt to
changes and enhance its effectiveness.
Communication and Training:
• Communicate the Quality Assurance Plan to all relevant
stakeholders and provide training as necessary. Ensure
that everyone involved understands their roles and
responsibilities in maintaining and improving quality.

Software Quality Assurance (SQA) metrics are quantifiable measurements

used to evaluate the quality, efficiency, and effectiveness of software
development and testing. They provide data-driven insights into the software
development process, helping identify areas for improvement and ensuring
the final product meets quality standards. These metrics are crucial for early
issue detection, continuous improvement, and delivering high-quality
software.

Types of SQA Metrics:

SQA metrics can be broadly classified into:

Product Metrics:
These measure the quality attributes of the software product itself, such as
functionality, reliability, usability, maintainability, and security. Examples include:
 • Defect Density: The number of defects found per unit of code or
functionality.
• Code Coverage: The percentage of code executed during testing.
• Defect Removal Effectiveness: The effectiveness of the testing process in
identifying and removing defects.
• Cyclomatic Complexity: A measure of the complexity of a software
application.
• Customer Satisfaction: A measure of how well the software meets user
expectations.
Process Metrics:
These measure the quality characteristics of the SQA process itself, such as
efficiency, effectiveness, compliance, and maturity. Examples include:
• Test Coverage: The extent to which the software has been tested.
• Defect Capture Rate: The percentage of defects detected during testing.
• Time to Test: The time it takes to complete the testing process.
• Cost per Bug Fix: The cost associated with fixing a defect.

Software reliability :
Software reliability refers to the probability that a software system will operate
without failure for a specified period in a given environment. It's a customer-
oriented view of software quality, focusing on how often faults cause
problems in real-world use, rather than just the design itself. Essentially, it's
about how dependable and trustworthy a software product is.

Here's a more detailed breakdown:

Key Aspects of Software Reliability:

• Probability of Failure-Free Operation:
Software reliability quantifies the likelihood that a software system will function
correctly without any errors or failures.
• Time:
 Reliability is evaluated over a specific time period, reflecting how long the software
is expected to operate reliably.
• Environment:
The specified environment includes the hardware, software, and other factors that
influence the system's behavior.
• Dynamic Nature:
Software reliability is a dynamic concept, meaning it's measured during the
software's operation, rather than being a static property determined solely by the
code.

Factors Influencing Software Reliability:

• Faults: The number of bugs or defects in the software code.
• Operational Profile: How users actually interact with the system, which can
impact the frequency of bug activation.
• Error Rate: The rate at which errors occur, which is influenced by both the
number of bugs and the frequency of their activation.

Importance of Software Reliability:

• User Experience: Reliable software provides a better user experience, reducing
frustration and downtime.
• Business Impact: Unreliable software can lead to lost productivity, damage to
reputation, and even legal consequences if it's part of critical systems.
• Software Quality: Software reliability is a key indicator of overall software
quality.

Formal Technical Review (FTR):

Formal Technical Review (FTR) is a software quality control activity

performed by software engineers. It is an organized, methodical procedure
for assessing and raising the standard of any technical paper, including
software objects. Finding flaws, making sure standards are followed, and
improving the product or document under review’s overall quality are the
main objectives of a formal technical review (FTR). Although FTRs are
frequently utilized in software development, other technical fields can also
employ the concept.
Objectives of formal technical review (FTR)
• Detect Identification: Identify defects in technical objects by finding
and fixing mistakes, inconsistencies, and deviations.

• Quality Assurance: To ensure high-quality deliverables, and

confirm compliance with project specifications and standards.

• Risk Mitigation: To stop risks from getting worse, proactively

identify and manage possible threats.

• Knowledge Sharing: Encourage team members to work together

and build a common knowledge base.

• Consistency and Compliance: Verify that all procedures, coding

standards, and policies are followed.

• Learning and Training: Give team members the chance to improve

their abilities through learning opportunities

Review Guidelines
Guidelines for the conducting of formal technical reviews should be
established in advance. These guidelines must be distributed to all
reviewers, agreed upon, and then followed. An unregistered review can
often be worse than a review that does not minimum set of guidelines for
FTR.
• Review the product, not the manufacturer (producer): FTR includes
people and egos. while properly conducted FTR will give all
participants a good feeling of accomplishment, and when
conducted improperly, the FTR team will be pointed out clearly. the
meeting tone will be only loose and constructive, the review team
 leader will ensure that the proper way of communication will be
happening or not into the team or it will get out of control.
• Set an agenda and maintain it: one of the measure keys in the
meeting is drift. FTR will always keep on track and schedule. the
review leader is making and maintaining the meeting schedule and
should not be afraid that many people drift sets in.
• Limit debate and rebuttal: whenever the issue is raised by the
reviewer there will not be an impact on a universal agreement.
rather than spending time with the questions, then issues will be
further discussed off-line.
• Enunciate problem areas, but don’t attempt to solve every problem
noted: A review is not a problem-solving session. The solution to a
problem can often be accomplished for the producer alone or with
the help of only one other individual. problem-solving should be
postponed for a while until after the review meeting.
• Take written notes (record purpose): it is a good idea to take notes
on the wallboard so that will be wording, and priorities can be
assessed by other reviewers as information is recorded.
• Limit the number of participants and insist upon preparation: two
heads are better than one, but 14 are not needed to be better than
4. We will keep the number of people involved to a minimum, all
review teams must prepare in advance, and written comments will
be requested by the review leader.
• Develop a checklist for each product that is likely to be reviewed: A
checklist will help to structure of Review meeting and for the
review leader and help to focus the reviewer on the important
issues. checklist should be developed by the analysis, design, code,
and even test documents.
• Allocate resources and schedule for FTRs to maintain schedule: it’s
effective to review, they should be effective and it should be a task
 during the software engineering process. In addition, the time
should be scheduled for modification that occurs as a result of an
FTR.
• Conduct meaningful training for all reviewers to make reviews
effective: To be effective for all the reviews at first some have
received formal training. it will stress both process-related and the
human psychological side of the reviews. for every person who is
to participate in reviews which is a one-month learning curve of 20
people.
• Review earlier reviews that serve as the base for the current review
being conducted: it can be beneficial in uncovering problems with
the review process itself. the first product to be reviewed should be
the guidelines themselves because many variables have a
successful review, a software organization should experiment to
find approaches that work best in a local context. porter and his
colleagues provide excellent guidance for this type of experiment.

Types Software Technical Review

1. Peer Reviews
Informal reviews conducted by colleagues to provide quick feedback and
suggestions.
• Description: Informal reviews conducted by colleagues, peers, or
teammates to provide quick feedback and suggestions. These
reviews focus on improving the quality of the work product through
collaborative discussion and immediate corrective action.
• Purpose: To identify defects early, share knowledge, and improve
the quality of the software product.
• Process: Usually unstructured and does not follow a formal
process. Can occur spontaneously, often during pair programming
or code sharing sessions.
 • Example: A developer asks a teammate to review a piece of code
they just wrote.
2. Walkthroughs
Semi-formal reviews where the author of the document or code explains
the content to a group of reviewers.
• Description: Semi-formal reviews where the author of the
document or code explains the content to a group of reviewers. The
focus is on understanding the material and gathering feedback
rather than on finding defects.
• Purpose: To ensure that the content is clear, logical, and meets the
requirements. Walkthroughs also serve as a knowledge-sharing
mechanism.
• Process: The author presents the material, often using slides or
documents, and reviewers ask questions and provide feedback. No
formal defect logging is usually done.
• Example: A project manager walks the team through a new project
plan to gather feedback and ensure everyone understands the
upcoming tasks.
3. Inspections
Formal reviews with a structured process and predefined roles, focusing on
defect detection and correction.
• Description: Formal reviews with a structured process and
predefined roles, focusing on defect detection and correction.
Inspections are systematic and thorough, with the goal of
identifying as many defects as possible.
• Purpose: To detect and correct defects early in the development
process, ensuring high-quality deliverables.
• Process: Involves planning, preparation, inspection meeting,
rework, and follow-up. Specific roles such as moderator, author,
scribe, and reviewers are assigned.
• Example: A software development team conducts a formal code
inspection meeting to review the latest module of the application.
4. Audits
Reviews conducted to ensure compliance with standards, regulations, and
contractual agreements.
• Description: Reviews conducted to ensure compliance with
standards, regulations, and contractual agreements. Audits are
typically performed by external parties or specialized internal
teams.
• Purpose: To verify that processes and products comply with
specified requirements, ensuring legal and contractual obligations
are met.
• Process: Involves reviewing documentation, processes, and
products against a predefined set of criteria. Findings are
documented, and non-compliances are reported.
• Example: An external auditor reviews a company’s software
development processes to ensure they meet ISO standards.

Walkthrough:

A walkthrough is a form of software peer review where the author of a

document or code explains their work to a group, guiding them through the
process and gathering feedback. It's an informal and conversational approach
aimed at identifying potential issues, improving understanding, and enhancing
the overall quality of the software product.

Purpose of Walkthroughs:
• Early Error Detection:
Walkthroughs help identify errors and potential problems early in the development
process, before they become more complex and costly to fix.
• Knowledge Transfer and Understanding:
They facilitate knowledge sharing and ensure that everyone involved has a clear
understanding of the work being reviewed.
• Improved Quality:
 By identifying and addressing issues during walkthroughs, the overall quality of the
software product is improved.
• Collaboration and Communication:
Walkthroughs encourage collaboration and open communication among team
members, leading to better teamwork and problem-solving.

Characteristics of Walkthroughs:
• Informal:
Walkthroughs are less formal than other review processes, such as inspections or
technical reviews.
• Author-Led:
The author of the document or code leads the walkthrough, explaining their work
and guiding the discussion.
• Participant-Driven:
While the author leads, participants are encouraged to ask questions, offer
comments, and share their perspectives.
• Focused on Understanding and Feedback:
The primary goal is to achieve a common understanding and gather feedback on
the work being reviewed.

What is Software Testing

Software Testing is a process of verifying and validating whether
the Software Product or Application is working as expected or not. The
complete testing includes identifying errors and bugs that cause future
problems for the performance of an application.

Software Testing Can be Divided into Two Steps:

Software testing mainly divides into the two parts, which is used in
the Software Development Process:
 1. Verification: This step involves checking if the software is doing what
is supposed to do. Its like asking, “Are we building the product the
right way?“

2.Validation: This step verifies that the software actually meets the
customer’s needs and requirements. Its like asking, “Are we building the
right product?“

Types of software testing :

1. Manual Testing
Manual Testing is a technique to test the software that is carried out using
the functions and features of an application. Which means manual testing
will check the defect manually with trying one by one function is working as
expected.
2. Automation Testing
Automation Testing It is a technique where the Tester writes scripts
independently and uses suitable Software or Automation Tools to test the
software. It is an Automation Process of a Manual Process. It allows for
executing repetitive tasks without the use of a Manual Tester.
Types of Manual Testing
Manual testing will be divided into further types which is following:
1. White Box Testing
White Box Testing is a software testing technique that involves testing the
internal structure and workings of a software application. The tester has
access to the source code and uses this knowledge to design test cases that
can verify the correctness of the software at the code level.
2. Black Box Testing
Black-Box Testing is a type of software testing in which the tester is not
concerned with the internal knowledge or implementation details of the
software but rather focuses on validating the functionality based on the
provided specifications or requirements.
3. Gray Box Testing
Gray Box Testing is a software testing technique that is a combination of
the Black Box Testing technique and the White Box Testing technique. In
the Black Box Testing technique, the tester is unaware of the internal
structure of the item being tested and in White Box Testing the internal
structure is known to the tester.

Types of Black Box Testing

Black Box Testing will be divided into further types which is
following:
1. Functional Testing
Functional Testing is a type of Software Testing in which the
system is tested against the functional requirements and
specifications. Functional testing ensures that the requirements or
specifications are properly satisfied by the application.
2. Non-Functional Testing
Non-Functional Testing is a type of Software Testing that is
performed to verify the non-functional requirements of the
application. It verifies whether the behavior of the system is as per
the requirement or not. It tests all the aspects that are not tested in
functional testing.
Types of Functional Testing
Functional Testing will be divided into further types which is
following:
1. Unit Testing
Unit Testing is a method of testing individual units or components of
a software application. It is typically done by developers and is used
to ensure that the individual units of the software are working as
intended.
2. Integration Testing
Integration Testing is a method of testing how different units or
components of a software application interact with each other. It is
used to identify and resolve any issues that may arise when different
units of the software are combined.
3. System Testing
System Testing is a type of software testing that evaluates the
overall functionality and performance of a complete and fully
integrated software solution. It tests if the system meets the
specified requirements and if it is suitable for delivery to the end-
users.
Types of Non-functional Testing
Here are the Types of Non-Functional Testing
 1. Performance Testing
Performance Testing is a type of software testing that ensures
software applications perform properly under their expected
workload. It is a testing technique carried out to determine system
performance in terms of sensitivity, reactivity, and stability under a
particular workload.
2. Usability Testing
Usability Testing in software testing is a type of testing, that is
done from an end user’s perspective to determine if the system is
easily usable. Usability testing is generally the practice of testing
how easy a design is to use on a group of representative users.
3. Compatibility Testing
Compatibility Testing is software testing that comes under the non
functional testing category, and it is performed on an application to
check its compatibility (running capability) on different
platforms/environments. This testing is done only when the
application becomes stable.

Different Levels of Software Testing

In Software testing there are Different Levels of Testing can be majorly
classified into 4 levels:
• Unit Testing: In this type of testing, errors are detected individually
from every component or unit by individually testing the components
or units of software to ensure that they are fit for use by the
developers. It is the smallest testable part of the software.
• Integration Testing: In this testing, two or more modules which are
unit tested are integrated to test i.e., technique interacting
components, and are then verified if these integrated modules work
as per the expectation or not, and interface errors are also detected.
 • System Testing: In system testing, complete and integrated Software
are tested i.e., all the system elements forming the system are tested
as a whole to meet the requirements of the system.
• Acceptance Testing: This is a kind of testing conducted to ensure that
the requirements of the users are fulfilled before its delivery and that
the software works correctly in the user’s working environment.

Benefits of Software Testing

Here are some Benefits which give Software Testing:
• Product Quality: Testing ensures the delivery of a high-quality
product as the errors are discovered and fixed early in the
development cycle.
• Customer Satisfaction: Software testing aims to detect the errors
or vulnerabilities in the software early in the development phase so
that the detected bugs can be fixed before the delivery of the
product. Usability testing is a type of software testing that checks
the application for how easily usable it is for the users to use the
application.
• Cost-Effective: Testing any project on time helps to save money
and time for the long term. If the bugs are caught in the early
phases of software testing, it costs less to fix those errors.
• Security: Security testing is a type of software testing that is
focused on testing the application for security vulnerabilities from
internal or external sources.

Importance of Software Testing

Software testing is important for the several reasons and it mainly classified
in the following reason which are affecting the most.
• Defects can be Identified Early: Software testing is important
because if there are any bugs they can be identified early and can
be fixed before the delivery of the software.
 • Improves Quality of Software: Software Testing uncovers the
defects in the software, and fixing them improves the quality of the
software.
• Increased Customer Satisfaction: Software testing ensures
reliability, security, and high performance which results in saving
time, costs, and customer satisfaction.
• Helps with Scalability: Software testing type non-functional
testing helps to identify the scalability issues and the point where
an application might stop working.
• Saves Time and Money: After the application is launched it will be
very difficult to trace and resolve the issues, as performing this
activity will incur more costs and time. Thus, it is better to conduct
software testing at regular intervals during software development.

Black Box Testing Vs White Box Testing

Black Box Testing White Box Testing
Parameters

White Box Testing is a way

Black Box Testing is a way of
of testing the software in
software testing in which the
which the tester has
internal structure or the
knowledge about the
program or the code is
internal structure or the code
hidden and nothing is known
or the program of the
about it.
software.
Definition

Black box testing is mainly

focused on testing the White box testing is mainly
functionality of the software, focused on ensuring that the
ensuring that it meets the internal code of the software
Testing requirements and is correct and efficient.
objectives specifications.
 Black Box Testing White Box Testing
Parameters

Black box testing uses

White box testing uses
methods like Equivalence
methods like Control Flow
Partitioning, Boundary
Testing, Data Flow
Value Analysis, and Error
Testing and Statement
Testing Guessing to create test
Coverage Testing.
methods cases.

Black box testing does not

require any knowledge of the White box testing requires
internal workings of the knowledge of programming
software, and can be languages, software
performed by testers who architecture and design
are not familiar with patterns.
Knowledge
programming languages.
level

White box testing is used for

Black box testing is generally
testing the software at the
used for testing the software
unit level, integration level
at the functional level.
Scope and system level.

Implementation of code is Code implementation is

not needed for black box necessary for white box
testing. testing.
Implementation

White Box Testing is mostly

Black Box Testing is mostly
done by software
done by software testers.
developers.
Done By
 Black Box Testing White Box Testing
Parameters

Black Box Testing can be White Box Testing is the

referred to as outer or inner or the internal
external software testing. software testing.
Terminology

Black Box Testing is a White Box Testing is a

functional test of the structural test of the
software. software.
Testing Level

Black Box testing can be

White Box testing of
initiated based on the
software is started after a
requirement specifications
Testing detail design document.
document.
Initiation

No knowledge of It is mandatory to have

programming is required. knowledge of programming.
Programming

Black Box Testing is the

White Box Testing is the
behavior testing of the
logic testing of the software.
software.
Testing Focus

White Box Testing is

Black Box Testing is
generally applicable to the
applicable to the higher
lower levels of software
levels of testing of software.
testing.
Applicability
 Black Box Testing White Box Testing
Parameters

Black Box Testing is also White Box Testing is also

Alternative
called closed testing. called as clear box testing.
Names

Black Box Testing is least White Box Testing is most

Time
time consuming. time consuming.
Consumption

Black Box Testing is not White Box Testing is

Suitable for
suitable or preferred for suitable for algorithm
Algorithm
algorithm testing. testing.
Testing

Data domains along with

Can be done by trial and error
inner or internal boundaries
ways and methods.
can be better tested.
Approach

Search something on google By input to check and verify

by using keywords loops
Example

It is less exhaustive as It is comparatively more

compared to white box exhaustive than black box
Exhaustiveness testing. testing.

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.

Factors of Software Quality

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 products, 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 products.
3. Reusability: A software has smart reusability if completely
different modules of the products will simply be reused to develop
new products.
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 products, and therefore the functionalities of the
products 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.
Difference between Quality Assurance (QA) and Quality Control
(QC)
Parameters Quality Assurance (QA) Quality Control (QC)

QA focuses on providing
QC focuses on fulfilling
Objective assurance that the quality
the quality requested.
requested will be achieved.

QA is the technique of QC is the technique to

Technique
managing quality. verify quality.

Involved in which QA is involved during the QC is not included during

phase? development phase. the development phase.

Program
QA does not include the QC always includes the
execution is
execution of the program. execution of the program.
included?

Type of tool QA is a managerial tool. QC is a corrective tool.

Process/ Product-
QA is process oriented. QC is product oriented.
oriented

The aim of quality control

The aim of quality assurance
Aim is to identify and improve
is to prevent defects.
the defects.
 Parameters Quality Assurance (QA) Quality Control (QC)

Quality Control is
Quality Assurance is
Order of performed after the
performed before Quality
execution Quality Assurance activity
Control.
is done.

QA is a preventive QC is a corrective
Technique type
technique. technique.

Measure type QA is a proactive measure. QC is a reactive measure.

QA is responsible for the QC is responsible for

SDLC/ STLC? entire software development the software testing life
life cycle. cycle.

QA is a low-level activity QC is a high-level activity

Activity level that identifies an error and that identifies an error
mistakes that QC cannot. that QA cannot.

Pays main focus is on the Its primary focus is on

Focus
intermediate process. final products.

Generally, the testing

All team members of the
Team team of the project is
project are involved.
involved.
 Parameters Quality Assurance (QA) Quality Control (QC)

Time QA is a less time-consuming QC is a more time-

consumption activity. consuming activity.

Statistical Process Control Statistical Quality Control

Which statistical
(SPC) statistical technique is (SQC) statistical
technique was
applied to Quality technique is applied to
applied?
Assurance. Quality Control.

Example Verification Validation

Software testing Strategies

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. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
 7. 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.

Issues 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.
6. Adapting to Evolving Requirements:
Software requirements can change during the development
process. This can lead to outdated test cases and an ineffective
testing strategy.

What is Conventional Testing?

Conventional testing is defined as traditional testing where the main aim is
to check whether all the requirements stated by the user are achieved.
• The difference between conventional testing and other testing
approach is that it concentrates on checking all the requirements
given by the user rather than following a software development
life cycle.
• Conventional testing mainly focuses on functional testing.
• This testing is being performed by a dedicated team of software
testers.
Stages of Conventional Testing

Conventional testing follows a sequential approach. It consists of various

stages. Such as
1. Planning
Planning is the first stage of conventional testing. This stage consists of
planning regarding the objective of testing developing a complete test plan
and resources that will be required for performing testing.
2. Requirement Analysis
Software Requirements are being analyzed in this phase. These
requirements help to identify the scope of testing and risks and for the
preparation of test cases.
3. Design
In this stage, test cases are designed. If the test cases are successful it
means that test cases are achieved. If not test cases are failed to achieve.
4. Execution
Execution is the process where test cases are executed. The errors
encountered during execution are documented.
5. Reporting
In reporting phase, all the documented errors are sent to the development
team for fixing.
6. Retesting
Retesting is the stage where all the test cases are performed again. It
checks whether all the failed test cases meet. All the requirements specified
by the user are achieved.
7. Release
In the last stage, the software is released for the users. It is verified that all
the requirements stated by the user or client are successfully working
before the release of the software product.
Types of Conventional Testing
1. Unit Testing
Unit Testing is defined as a type of testing where the various modules and
units are being tested individually. Unit testing makes sure that each
individual component of the system works well and eventually checks
whether all the requirements stated by clients are achieved successfully.
2. Integration Testing
Integration Testing is defined as a type of testing where multiple modules
or components are tested together in order to check that they work
accordingly once integrated with each other. It makes sure that interaction
and communication between different modules work well.
3. Performance Testing
Performance Testing is defined as a type of testing that checks for
performance-related parameters for a software product. Performance
testing helps to find out the loopholes in the system and improve
performance.
4. Acceptance Testing
Acceptance Testing is defined as a type of testing that is used to check the
requirements according to the user’s point of view. It makes sure that all
requirements specified by the user are achieved.
5. Regression Testing
Regression Testing is defined as a type of testing in which test cases are
executed again in order to check that the changes made are being fixed and
the system is working accordingly.
Benefits of Conventional Testing
1. Cost Effective: Conventional Testing is cost-effective as manual
testing is being used. Manual testing requires less financial
investment as compared to automation testing.
2. Flexible: Conventional testing has the advantage of flexibility.
Manual testing has the ability to adopt the changes that take place
while testing the product.
3. Testing of Non-functional Requirements also: Manual testing can
test functional as well as non-functional requirements such as
accessibility, and usability which is different from automation
testing.
4. Understanding User Experience more effectively: Conventional
Testing makes use of manual testing which helps to understand
the user experience more effectively as the manual tester can test
the requirements with multiple scenarios.
5. Provides better communication between testers and
developers: Manual testing allows better communication between
testers, developers, and other clients regarding issues and wrong
outputs.

Limitations of Conventional Testing

1. Time-consuming: Conventional Testing can be time-consuming as
with manual testing it can take more time for large applications
and accordingly delay further deployment process of the project.
2. Subjective: The manual tester performing the testing can have
their own views and opinions which can in turn result in the quality
of testing that is being performed.
3. Repetitive: Manual testing can lead to repetition by performing the
testing for the same test cases. It can consume more time than it is
required.
 4. Limited Coverage: Manual testing can miss some of the test cases
and it will be not notified by the tester. This can result in delivering
the software product with errors or untasted test cases.

What is Object-Oriented Testing?

Object-oriented testing is a process used to test software that follows
object-oriented principles like encapsulation, inheritance,
and polymorphism. Instead of focusing on just individual functions, this
type of testing looks at how different objects and classes in the software
interact with one another.
.
Testing Classes in Object-Oriented Testing
Testing classes is a fundamentally different issue than testing
functions. A function (or a procedure) has a clearly defined input-
output behavior, while a class does not have an input-output
behavior specification. We can test a method of a class using
approaches for testing functions, but we cannot test the class using
these
approaches.
• Data dependencies between variables
• Calling dependencies between modules
• Functional dependencies between a module and the
variable it computes
• Definitional dependencies between a variable and its
types.
But in Object-Oriented systems, there are the following additional
dependencies:
• Class-to-class dependencies
• Class to method dependencies
• Class to message dependencies
• Class to variable dependencies
• Method to variable dependencies
• Method to message dependencies
 • Method to method dependencies
Object-Oriented Testing Issues and Levels
Additional testing Issue of interest is that it is not possible to test
the class dynamically, only its instances i.e, objects can be tested.
Similarly, the concept of inheritance opens various issues e.g., if
changes are made to a parent class or superclass, in a larger
system of a class it will be difficult to test subclasses individually
and isolate the error to one class. In object-oriented programs,
control flow is characterized by message passing among objects,
and the control flow switches from one object to another by inter-
object communication.
1. Fault Based Testing: This type of checking permits for
coming up with test cases supported the consumer
specification or the code or both. It tries to identify
possible faults (areas of design or code that may lead to
errors.). For all of these faults, a test case is developed to
“flush” the errors out. These tests also force each time of
code to be executed. This method of testing does not find
all types of errors. However, incorrect specification and
interface errors can be missed. These types of errors can
be uncovered by function testing in the traditional testing
model. In the object-oriented model, interaction errors can
be uncovered by scenario-based testing. This form of
Object oriented-testing can only test against the client’s
specifications, so interface errors are still missed.
2. Class Testing Based on Method Testing: This approach is
the simplest approach to test classes. Each method of the
class performs a well defined cohesive function and can,
therefore, be related to unit testing of the traditional
testing techniques. Therefore all the methods of a class
can be involved at least once to test the class.
3. Random Testing: It is supported by developing a random
test sequence that tries the minimum variety of operations
typical to the behavior of the categories
 4. Partition Testing: This methodology categorizes the
inputs and outputs of a category so as to check them
severely. This minimizes the number of cases that have to
be designed.
5. Scenario-based Testing: It primarily involves capturing
the user actions then stimulating them to similar actions
throughout the test. These tests tend to search out
interaction form of error.
Purpose of Object Oriented Testing
1. Object Interaction Validation: Check to make sure objects
interact with one another appropriately in various
situations. Testing makes ensuring that the interactions
between objects in object-oriented systems result in the
desired results.
2. Determining Design Errors: Find the object-oriented
design’s limitations and design faults. Testing ensures that
the design complies with the desired architecture by
assisting in the identification of problems with inheritance,
polymorphism, encapsulation and other OOP concepts.
3. Finding Integration Problems: Evaluate an object’s ability
to integrate and communicate with other objects when it
is part of a bigger component or subsystem. This helps in
locating integration difficulties, such improper method
calls or issues with data exchange.
4. Assessment of Reusable Code: Evaluate object-oriented
code’s reusability. Code reuse is promoted by object-
oriented programming via features like inheritance and
composition. Testing ensures that reusable parts perform
as intended in various scenarios.
5. Verification of Handling Exceptions: Confirm that objects
respond correctly to error circumstances and exceptions.
The purpose of object-oriented testing is to make sure
that the software responds carefully and is durable in the
face of unforeseen occurrences or faults.
 6. Verification of Uniformity: Maintain uniformity inside and
between objects and the object-oriented system as a
whole. Maintainability and readability are enhanced by
consistency in naming standards, coding styles and
compliance to design patterns.

Web based application testing:

Web testing is a software testing technique to test web applications or
websites for finding errors and bugs. A web application must be tested
properly before it goes to the end-users. Also, testing a web application
does not only mean finding common bugs or errors but also testing the
quality-related risks associated with the application. Software
Testing should be done with proper tools and resources and should be
done effectively. We should know the architecture and key areas of a
web application to effectively plan and execute the testing.
Testing a web application is very common while testing any other
application like testing functionality, configuration, or compatibility, etc.
Testing a web application includes the analysis of the web fault
compared to the general software faults.

Types of Web Testing:

Basically, there are 4 types of web-based testing that are available and all
four of them are discussed below:
• Static Website Testing: A static website is a type of website in
which the content shown or displayed is exactly the same as it is
stored in the server. This type of website has great UI but does not
have any dynamic feature that a user or visitor can use. In static
testing, we generally focus on testing things like UI as it is the
most important part of a static website. We check things font size,
color, spacing, etc. testing also includes checking the contact us
form, verifying URLs or links that are used in the website, etc.
• Dynamic Website Testing: A dynamic website is a type of website
that consists of both a frontend i.e, UI, and the backend of the
 website like a database, etc. This type of website gets updated or
change regularly as per the user’s requirements. In this website,
there are a lot of functionalities involved like what a button will do
if it is pressed, are error messages are shown properly at their
defined time, etc. We check if the backend is working properly or
not, like does enter the data or information in the GUI or frontend
gets updated in the databases or not.
• E-Commerce Website Testing: An e-commerce website is very
difficult in maintaining as it consists of different pages and
functionalities, etc. In this testing, the tester or developer has to
check various things like checking if the shopping cart is working as
per the requirements or not, are user registration or login
functionality is also working properly or not, etc. The most
important thing in this testing is that does a user can successfully
do payment or not and if the website is secured. And there are a lot
of things that a tester needs to test apart from the given things.
• Mobile-Based Web Testing: In this testing, the developer or tester
basically checks the website compatibility on different devices and
generally on mobile devices because many of the users open the
website on their mobile devices. So, keeping that thing in mind, we
must check that the site is responsive on all devices or platforms.
Points to be Considered While Testing a Website:
As the website consists of a frontend, backend, and servers, so things like
HTML pages, internet protocols, firewalls, and other applications running on
the servers should be considered while testing a website. There are various
examples of considerations that need to be checked while testing a web
application. Some of them are:
• Do all pages are having valid internal and external links or URLs?
• Whether the website is working as per the system compatibility?
• As per the user interface-Does the size of displays are the optimal
and the best fit for the website?
• What type of security does the website need (if unsecured)?
• What are the requirements for getting the website analytics, and
also controlling graphics, URLs, etc.?
 • The contact us or customer assistance feature should be added or
not on the page, etc.?
Objectives of Web Based Testing:
• Testing for functionality: Make that the web application performs
as expected for all features and functions. Check that user interface
elements like form submissions and navigation work as intended.
• Testing for Compatibility: To make sure it is compatible, test the
web application across a variety of devices, operating systems, and
browsers. Verify that the program operates consistently in a range
of settings.
• Evaluation of Performance: Analyze the online application’s
overall performance, speed, and responsiveness. Any performance
bottlenecks, such as slow page loads or delayed server response
times, should be located and fixed.
• Testing for load: Examine how well the web application can
manage a particular load or multiple user connections at
once. Determine and fix performance problems when there is a lot
of traffic.
• Testing for accessibility: Make sure the online application complies
with applicable accessibility standards (e.g., WCAG) and is usable
by people with disabilities. Make sure the program can
communicate with assistive technologies efficiently.
• Testing Across Browsers: Make sure the operation and
appearance of the web application are consistent by testing it in
various web browsers. Determine and fix any problems that might
develop with a particular browser.

Steps in Software Testing:

In web-based testing, various areas have to be tested for finding the
potential errors and bugs, and steps for testing a web app are given below:
• App Functionality: In web-based testing, we have to check the
specified functionality, features, and operational behavior of a web
application to ensure they correspond to its specifications. For
example, Testing all the mandatory fields, Testing the asterisk sign
 should display for all the mandatory fields, Testing the system
should not display the error message for optional fields, and also
links like external linking, internal linking, anchor links, and mailing
links should be checked properly and checked if there’s any
damaged link, so that should be removed. We can do testing with
the help of Functional Testing in which we test the app’s functional
requirements and specifications.
• Usability: While testing usability, the developers face issues with
scalability and interactivity. As different numbers of users will be
using the website, it is the responsibility of developers to make a
group for testing the application across different browsers by using
different hardware. For example, Whenever the user browses an
online shopping website, several questions may come to his/her
mind like, checking the credibility of the website, testing whether
the shipping charges are applicable, etc.
• Browser Compatibility: For checking the compatibility of the
website to work the same in different browsers we test the web
application to check whether the content that is on the website is
being displayed correctly across all the browsers or not.
• Security: Security plays an important role in every website that is
available on the internet. As a part of security, the testers check
things like testing the unauthorized access to secure pages should
not be permitted, files that are confined to the users should not be
downloadable without the proper access.
• Load Issues: We perform this testing to check the behavior of the
system under a specific load so that we can measure some
important transactions and the load on the database, the
application server, etc. are also monitored.
• Storage and Database: Testing the storage or the database of any
web application is also an important component and we must sure
that the database is properly tested. We test things like finding
errors while executing any DB queries, checking the response time
of a\the query, testing whether the data retrieved from the
database is correctly shown on the website or not.
Software maintenance :
Software maintenance is the process of modifying and updating software
after it's been deployed to fix issues, improve performance, add new features,
and adapt to changing environments. It's a crucial part of the software
development lifecycle, ensuring the software remains functional, reliable, and
secure throughout its lifespan.

Importance :
• Correcting Faults:
Software is rarely perfect when first released. Maintenance involves fixing bugs,
addressing errors, and resolving issues that arise after deployment.
• Improving Performance:
Maintenance can involve optimizing code, improving efficiency, and enhancing the
overall responsiveness of the software.
• Adapting to Changes:
Software needs to adapt to evolving hardware and software environments, new
operating systems, and changing user needs. This may involve rewriting portions of
the code or adding new modules.
• Enhancing Functionality:
Maintenance can include adding new features, improving the user interface, and
making the software more user-friendly.
• Maintaining Security:
Software vulnerabilities are constantly being discovered. Maintenance includes
patching security holes, ensuring the software remains secure against threats, and
protecting user data.

Types of Software Maintenance:

• Corrective Maintenance: Fixing bugs and errors reported by users or identified
during testing.
• Adaptive Maintenance: Adapting the software to changes in the environment,
such as new operating systems, hardware, or software libraries.
 • Perfective Maintenance: Improving the performance, efficiency, and usability of
the software.
• Preventive Maintenance: Taking steps to prevent future problems, such as
refactoring code, improving documentation, and conducting code reviews.

Software supportability :
Software supportability refers to the ease with which a software system can
be maintained, modified, and supported throughout its lifecycle. It
encompasses the design, development, and deployment aspects that enable
effective and efficient support activities, ensuring the system meets user
needs and remains operational.

Key Aspects of Software Supportability:

• Ease of Maintenance:
The ability to easily correct errors, update features, and adapt the software to
changing requirements.
• Design for Support:
Incorporating features and structures during development that make it easier to
diagnose problems, test changes, and deploy updates.
• Documentation and Training:
Providing clear documentation, training materials, and knowledge bases to assist
support personnel and users.
• Support Infrastructure:
Ensuring that necessary resources, such as bug tracking systems, release
management tools, and support channels, are in place.
• Resource Availability:
Having the necessary manpower, equipment, and other resources available to
maintain and support the software.
• Lifecycle Management:
Considering supportability throughout the software development lifecycle, from
requirements gathering to deployment and ongoing maintenance.
Benefits of Supportability:
• Reduced Support Costs:
A well-designed and supported system can significantly reduce the time and
resources required for troubleshooting and maintenance.
• Improved User Satisfaction:
Easier support and faster resolution of issues lead to greater user satisfaction.
• Increased System Reliability:
Effective maintenance and support practices can enhance the reliability and
stability of the system.
• Faster Time to Market:
Well-supported systems can be more easily updated and adapted to changing
market demands.

What is Business Process Re-engineering (BPR)?

Business Process Re-engineering (BPR) is a strategic approach to improve
an organization’s performance by rethinking and redesigning its business
processes. The goal of BPR is to achieve significant improvement in
parameters like cost, quality, service, and speed.
1. The aim is to improve customer satisfaction by improving the
quality and speed of services delivered.
2. It involves questioning the basic assumptions and principles of
current business processes.
3. It involves the collaboration of cross-functional teams to ensure all
the aspects of the processes are considered.
4. Its successful implementation requires effective change
management strategies to handle resistance to change.
Principles of BPR
Here are seven key principles of BPR:
1. Focus on Desired Outcomes: BPR emphasizes organizing
processes based on desired outcomes, rather than individual tasks
and designing processes that achieve these outcomes efficiently.
 2. Identify and Eliminate Non-Value-Adding Activities: BPR aims to
eliminate non-value-added activities by analyzing processes,
thereby reducing waste and unnecessary bottlenecks.
3. Integrate Multiple Steps: BPR emphasizes combining multiple
steps and ensures that information processing occurs as a part of
the actual work process. This helps to simplify the process and
reduce delays.
4. Coordinate Geographically Dispersed Resources: BPR advocates
to use of technology to integrate and treat geographically
dispersed resources as a centralized source to create a unified
process and improve accuracy.
5. Link Parallel Activities: BPR focuses on integrating parallel
activities to enable simultaneous processing and thus reducing the
wait time and errors.
6. Empower Employees: BPR advocates to empower employees so
that they can make decisions at the point where the work is
performed, thus enabling faster and more efficient decision-
making.
7. Capture Information Once at the Source: BPR emphasizes
capturing information once and ideally at the source to avoid
duplication and errors. The same information can be used
throughout the process.

Steps to BPR
Here is a brief overview of how BPR works:
1. Identify Processes: This step involves identifying processes for re-
engineering that require the improvement most and will offer the
greatest benefit from re-engineering.
2. Understand Existing Processes: Conduct a thorough analysis of
current processes to identify inefficiencies and bottlenecks.
3. Define Objectives: Set clear and specific goals for the re-
engineering process such as cost reduction, faster service,
improved quality, and many more.
 4. Form a Cross-Functional Team: Form a team of members from
various departments to bring diverse expertise to the re-
engineering process.
5. Redesign Processes: Rethink and redesign processes from the
ground up, focusing on eliminating non-value-adding activities.
6. Implement Changes: Execute new process designs and ensure
that all necessary resources are available to facilitate a smooth
transition.
7. Monitor and Optimize: Continuously track the performance of re-
engineered processes and make changes as needed to ensure that
they meet the desired outcomes.

Benefits of BPR
Here are some key benefits that can significantly impact organizational
performance and efficiency:
1. Increased Efficiency: It aims to streamline processes, reduce cycle
times, and eliminate redundancies, leading to improved operational
efficiency.
2. Cost Reduction: Organizations can lower operational costs by
optimizing processes and reducing costs.
3. Improved Quality: Redesigned processes include built-in quality
checks, resulting in higher quality outputs and fewer errors.
4. Improved Customer Satisfaction: It focuses on improving overall
customer satisfaction by aligning the processes with customer
needs.
5. Employee Empowerment: Involving employees in process
redesign leads to a more motivated workforce.
6. Improved Financial Performance: BPR can lead to improved
financial performance through cost savings, better resource
utilization, and increased revenues.
7. Continuous Improvement: It encourages an environment of
continuous improvement, enabling organizations to be more
adaptable to market changes.
Challenges in BPR
Here are common challenges in BPR initiatives:
1. High Costs: Implementing BPR can be a costly and time-
consuming process, requiring significant investment in resources,
including technology, training, and consulting fees. This can be a
significant barrier for small or cash-strapped organizations.
2. Resistance to Change: Implementing BPR can be a difficult and
complex process that requires significant changes to an
organization’s culture, processes, and people. Employees may
resist the changes, especially if they feel their job security is at risk,
leading to decreased morale and increased turnover.
3. Focus on Short-term Goals: BPR initiatives may focus on short-
term goals, such as reducing costs, without considering the long-
term impact on the organization’s overall strategy and goals.
4. Lack of Top Management Support: Without support from senior
management, BPR initiatives may lack the necessary resources and
authority to succeed.
5. Unclear Objectives: Unclear goals can lead to confusion and
difficulty in measuring success.
6. Risk of Failure: BPR is a high-risk strategy that can fail if not
implemented properly. The failure to gain employee support, lack
of a clear strategy, or poor planning can all lead to a BPR
initiative’s failure.
7. Disruption to Operations: Implementing BPR can disrupt the day-
to-day operations of the organization, leading to decreased
productivity, customer dissatisfaction, and revenue loss.

What is Re-engineering?
Re-engineering, also known as software re-engineering, is the process of
analyzing, designing, and modifying existing software systems to improve
their quality, performance, and maintainability.
1. This can include updating the software to work with new hardware
or software platforms, adding new features, or improving the
software’s overall design and architecture.
 2. Software re-engineering, also known as software restructuring or
software renovation, refers to the process of improving or
upgrading existing software systems to improve their quality,
maintainability, or functionality.
3. It involves reusing the existing software artifacts, such as code,
design, and documentation, and transforming them to meet new or
updated requirements.
Objective of Re-engineering
The primary goal of software re-engineering is to improve the quality and
maintainability of the software system while minimizing the risks and costs
associated with the redevelopment of the system from scratch. Software re-
engineering can be initiated for various reasons, such as:
1. To describe a cost-effective option for system evolution.
2. To describe the activities involved in the software maintenance
process.
3. To distinguish between software and data re-engineering and to
explain the problems of data re-engineering.

Process of Software Re-engineering

The process of software re-engineering involves the following steps:
1. Planning: The first step is to plan the re-engineering process,
which involves identifying the reasons for re-engineering, defining
the scope, and establishing the goals and objectives of the process.
2. Analysis: The next step is to analyze the existing system, including
the code, documentation, and other artifacts. This involves
identifying the system’s strengths and weaknesses, as well as any
issues that need to be addressed.
3. Design: Based on the analysis, the next step is to design the new
or updated software system. This involves identifying the changes
that need to be made and developing a plan to implement them.
4. Implementation: The next step is to implement the changes by
modifying the existing code, adding new features, and updating the
documentation and other artifacts.
5. Testing: Once the changes have been implemented, the software
system needs to be tested to ensure that it meets the new
requirements and specifications.
6. Deployment: The final step is to deploy the re-engineered
software system and make it available to end-users.
The software reengineering is necessary for having-
a) Boost up productivity: Software reengineering increase productivity by
optimizing the code and database so that processing gets faster.
b) Processes in continuity: The functionality of older software products can
be still used while the testing or development of software.
c) Improvement opportunity: Meanwhile the process of software
reengineering, not only software qualities, features, and functionality but
also your skills are refined, and new ideas hit your mind. This makes the
developer’s mind accustomed to capturing new opportunities so that more
and more new features can be developed.
d) Reduction in risks: Instead of developing the software product from
scratch or from the beginning stage, developers develop the product from
its existing stage to enhance some specific features brought in concern by
stakeholders or its users. Such kind of practice reduces the chances of fault
fallibility.
e) Saves time: As stated above, the product is developed from the existing
stage rather than the beginning stage, so the time consumed in software
engineering is lesser.
f) Optimization: This process refines the system features, and
functionalities and reduces the complexity of the product by consistent
optimization as maximum as possible.

Steps involved in Re-engineering

1. Inventory Analysis
2. Document Reconstruction
3. Reverse Engineering
4. Code Reconstruction
5. Data Reconstruction
6. Forward Engineering
1. Inventory Analysis:
Every software organization should have an inventory of all the
applications.

• Inventory can be nothing more than a spreadsheet model

containing information that provides a detailed description of every
active application.
• By sorting this information according to business criticality,
longevity, current maintainability, and other local important criteria,
candidates for re-engineering appear.
• The resource can then be allocated to a candidate application for
re-engineering work.
2. Document reconstructing:
Documentation of a system either explains how it operates or how to use it.
• Documentation must be updated.
• It may not be necessary to fully document an application.
• The system is business-critical and must be fully re-documented.
3. Reverse Engineering:
Reverse engineering is a process of design recovery. Reverse engineering
tools extract data and architectural and procedural design information from
an existing program.

4. Code Reconstructing:

• To accomplish code reconstruction, the source code is analyzed

using a reconstructing tool. Violations of structured programming
construct are noted and code is then reconstructed.
• The resultant restructured code is reviewed and tested to ensure
that no anomalies have been introduced.
5. Data Restructuring:

• Data restructuring begins with a reverse engineering activity.

• The current data architecture is dissected, and the necessary data
models are defined.
• Data objects and attributes are identified, and existing data
structures are reviewed for quality.
6. Forward Engineering:
Forward Engineering also called renovation or reclamation not only
recovers design information from existing software but uses this
information to alter or reconstitute the existing system to improve its overall
quality.

What is Reverse Engineering?

Reverse engineering can extract design information from source code, but
the abstraction level, the completeness of the documentation, the degree to
which tools and a human analyst work together, and the directionality of
the process are highly variable.
Objective of Reverse Engineering:
1. Reducing Costs: Reverse engineering can help cut costs in product
development by finding replacements or cost-effective alternatives
for systems or components.
2. Analysis of Security: Reverse engineering is used in cybersecurity
to examine exploits, vulnerabilities, and malware. This helps in
understanding of threat mechanisms and the development of
practical defenses by security experts.
3. Integration and Customization: Through the process of reverse
engineering, developers can incorporate or modify hardware or
software components into pre-existing systems to improve their
operation or tailor them to meet particular needs.
4. Recovering Lost Source Code: Reverse engineering can be used to
recover the source code of a software application that has been
lost or is inaccessible or at the very least, to produce a higher-level
representation of it.
5. Fixing bugs and maintenance: Reverse engineering can help find
and repair flaws or provide updates for systems for which the
original source code is either unavailable or inadequately
documented.
Steps of Software Reverse Engineering:
1. Collection Information: This step focuses on collecting all possible
information (i.e., source design documents, etc.) about the
software.
2. Examining the Information: The information collected in step-1 is
studied so as to get familiar with the system.
3. Extracting the Structure: This step concerns identifying program
structure in the form of a structure chart where each node
corresponds to some routine.
4. Recording the Functionality: During this step processing details of
each module of the structure, charts are recorded using structured
language like decision table, etc.
5. Recording Data Flow: From the information extracted in step-3
and step-4, a set of data flow diagrams is derived to show the flow
of data among the processes.
6. Recording Control Flow: The high-level control structure of the
software is recorded.
7. Review Extracted Design: The design document extracted is
reviewed several times to ensure consistency and correctness. It
also ensures that the design represents the program.
8. Generate Documentation: Finally, in this step, the complete
documentation including SRS, design document, history, overview,
etc. is recorded for future use.

What is Forward Engineering?

Forward Engineering is a method of creating or making an application with
the help of the given requirements. Forward engineering is also known as
Renovation and Reclamation. Forward engineering requires high proficiency
skills. It takes more time to construct or develop an application. Forward
engineering is a technique of creating high-level models or designs to make
complexities and low-level information. Therefore this kind of engineering
has completely different principles in numerous packages and information
processes. Forward Engineering applies all the software engineering process
that contains SDLC to recreate associated existing applications. It is near to
full fill new needs of the users into re-engineering.
Characteristics of forward engineering
1. Forward engineering is a variety of engineering that has different
principles in numerous package and information processes.
2. Forward engineering is vital in IT as a result of it represents the
‘normal’ development process.
3. Forward engineering deals with the conversion of business
processes, services, and functions into applications.
4. In this method, the business model is developed first. Then, a top-
down approach is followed to urge the package from the model
developed.
5. Forward engineering tools are accustomed to moving from
implementation styles and logic to the event of supply code.
6. It essentially permits the user to develop a business model which
may then be translated into data system components.
7. These tools follow the top-down approach. System creator and
visual Analyst is a forward engineering CASE tool.

Difference between Forward Engineering and Reverse

Engineering
Forward Engineering Reverse Engineering
Aspect

In forward engineering, the In reverse engineering or

Process application are developed backward engineering, the
 Forward Engineering Reverse Engineering
Aspect

with the given information are collected

requirements. from the given application.

Reverse Engineering or
Forward Engineering is a
backward engineering is a
high proficiency skill.
low proficiency skill.
Skill Level

While Reverse Engineering

Forward Engineering takes
or backward engineering
more time to develop an
takes less time to develop an
Development application.
application.
Time

The nature of reverse

The nature of forward
engineering or backward
engineering is Prescriptive.
engineering is Adaptive.
Nature

In forward engineering, In reverse engineering,

production is started with production is started by
Production Start
given requirements. taking the existing products.
Point

The example of forward

engineering is the An example of backward
construction of electronic engineering is research on
kit, construction of DC Instruments etc.
MOTOR , etc.
Examples
 Forward Engineering Reverse Engineering
Aspect

Forward engineering
Reverse engineering Starts
Starts with requirements
with an existing software
analysis and design, then
system and works backward
proceeds to
to understand its structure,
implementation and
Development design, and requirements.
testing.
Steps

Forward engineering is
Reverse engineering is Used
used to create new
to modify and improve an
software applications from
existing software application.
scratch.
Use Case

Forward engineering is Reverse engineering is a

process of moving from a process of moving from a
high-level abstraction to a low-level implementation to
Abstraction
detailed implementation. a higher-level abstraction.
Level

Requirements and design

Requires a clear set of specifications may not be
requirements and design available, making it
Requirements specifications. necessary to reconstruct
and Design
them from the code itself.
Specifications
Project management
Project management is the discipline of planning, organizing, and managing
resources to achieve specific project objectives within defined constraints,
including time, budget, and scope. It involves a systematic approach to guide
a project from initiation to closure, ensuring it meets stakeholder needs and
expectations.

Key aspects of project management include:

• Planning: Defining project goals, scope, timelines, and budget.
• Organization: Identifying and allocating necessary resources, including
personnel, materials, and tools.
• Execution: Carrying out the planned activities and managing the project team.
• Monitoring and Control: Tracking progress, identifying risks, and making
necessary adjustments to stay on track.
• Closing: Finalizing the project and ensuring all deliverables are completed.

Why is project management important?

• Ensures project success:
It helps organizations achieve their goals by providing a structured approach to
project delivery.
• Improves resource utilization:
By effectively managing resources, organizations can optimize costs and maximize
efficiency.
• Reduces risks:
Proactive risk identification and management can minimize disruptions and ensure
project completion within constraints.
• Enhances communication:
Clear communication among stakeholders is crucial for successful project
management, and it fosters collaboration.
4 P’s in Software Project
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.

• 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.
W5HH principles
Barry Boehm gave a philosophy that prepares easy and manageable
designs or outlines for software projects. He also gave a technique to
discuss objectives, management, duties, and technical approach of the
project and its necessary resources. Then he named it the W5HH
principle when few questions resulted in project properties, definition, and
resultant plan to make the project successful. Those questions are :
The W5HH principle in software management exists to help project
managers guide objectives, timelines, responsibilities, management styles,
and resources. In this lesson, we’ll explore each part.

W5HH Principles:
Why the system is going to be developed?
For the purpose of software work, all stakeholders must assess the validity
of the system product/project. Here Barry questions that whether the
project’s purpose will justify the cost, time spent on it by people?
What is activities are needed to be done in this?
In this Barry questions what task is needed to be done for a project
currently.
When is this done?
Project Scheduling is done by the team after recognizing when project tasks
will be started and when they enter into the final stage to reach the goal.
Who are the reasons for these activities in this project?
Every member who is part of the software team is responsible for this. And
their roles are defined.
Where are these authoritatively located?
Not only do software practitioners have roles in this but also users,
customers, stakeholders also have roles and responsibilities
organizationally.
How is the job technically and managerially finished?
All technical strategies, management rules of the project are defined after
knowing the scope of the project which is being built.
How much part of each resource is required?
This is known by software developers after the estimation of each resource
as per the needs of customers/users.
This W5HH principle of Bohem is appropriate irrespective of the scale or
difficulty of software projects being developed. These questions help in
planning the outline of the project for the software team.

The W5HH principle outlines a series of questions that can help project
managers more efficiently manage software projects. Each letter in W5HH
stands for a question in the series of questions to help a project manager
lead. (Notice there are five ”W” questions and two ”H” questions).

W5HH The Question What It Means

Why is the system being This focuses a team on the business reasons
Why?
developed? for developing the software.

This is the guiding principle in determining the

What? What will be done?
tasks that need to be completed.

When will it be This includes important milestones and the

When?
completed? timeline for the project.

This is where you determine which team

Who is responsible for member takes on which responsibilities. You
Who?
each function? may also identify external stakeholders with a
claim in the project.
 Where are they This step gives you time to determine what
Where? organizationally other stakeholders have a role in the project
located? and where they are found.

How will the job be done In this step, a strategy for developing the
How? technically and software and managing the project is
managerially? concluded upon.

The goal of this step is to figure out

How How much of each
the number of resources necessary to
Much? resource is needed?
complete the project.

Project management is crucial for organizations to ensure successful

completion of projects within defined scope, time, and budget constraints,
leading to improved efficiency, better organization, and reduced risks. It
provides a structured approach to planning, executing, and controlling
projects, ultimately enhancing productivity, profitability, and client
satisfaction.

Need for project management:

• Improved Efficiency and Productivity:
Project management offers a structured approach, reducing wasted time and
resources by clearly defining tasks, timelines, and responsibilities.
• Better Organization:
A project management framework provides a roadmap for teams, preventing tasks
from falling through the cracks and ensuring everyone understands their roles and
responsibilities.
• Enhanced Communication:
Project management promotes clear and regular communication among team
members and stakeholders, preventing misunderstandings and aligning
expectations.
• Risk Mitigation:
 By identifying potential risks early, project management enables teams to develop
strategies to avoid or minimize their impact, preventing costly setbacks.
• Measurable Outcomes:
With well-defined goals and metrics, businesses can easily track progress and
measure the success of their projects.
• Increased Client Satisfaction:
Delivering projects on time, within budget, and to specification, as facilitated by
project management, leads to higher client satisfaction.
• Optimized Resource Utilization:
Project management helps businesses allocate resources effectively, ensuring they
are used efficiently and strategically.
• Improved Quality Control:
By establishing clear quality standards and incorporating quality control activities,
project management helps ensure that project deliverables meet the specified
requirements.
• Reduced Project Overruns:
Effective project management helps control costs and timelines, reducing the
likelihood of budget overruns and delays.
• Enhanced Decision-Making:
Project managers can use data and information gathered through project
management processes to inform decisions and secure support for the right
course of action.
• Continuous Learning and Improvement:
Project retrospectives provide valuable insights for improving future projects and
processes.

What is the Project Life Cycle?

The project life cycle is a step-by-step process that guides a project from
start to finish. It includes phases like starting, planning, doing the work,
checking progress, and wrapping up. This process helps organize and
manage project tasks, ensuring everything stays on track to meet the
project's goals efficiently. By following these steps, projects are more likely
to be successful and meet their objectives.

The 5 Project Life Cycle Phases

Project life cycles typically consist of five major phases:

• Initiation: This is the first phase where the project's idea is created,
and its feasibility is assessed. Initial project goals, objectives, and
key stakeholders are identified. This phase sets the foundation for
the project, ensuring that it is viable and aligned with overall
objectives before moving forward. Proper planning in this phase
helps to guide the project's direction and success.
• Planning: In this phase, a detailed project plan is developed. It
includes a list of tasks, a timeline for each task, how resources will
be allocated, and strategies for managing risks. This plan helps
keep the project organized and on track, ensuring that everyone
understands their roles and responsibilities and how to handle any
potential issues that might arise.
• Execution: In this phase, the project plan is put into action. The
team works together to complete the tasks and produce the
project's results. It’s where the real work happens, with everyone
collaborating to achieve the goals and ensure the project stays on
track. Regular updates and adjustments are made as needed.
 • Monitoring and Controlling: In this phase, project progress is
carefully monitored to ensure it follows the plan. Any deviations or
issues are identified, and corrective actions are taken to address
them. This helps keep the project on track and ensures that it
continues to meet its goals and deadlines. Regular checks and
adjustments are made to ensure successful completion.
• Closure: Once the project’s deliverables are completed and
approved, the project officially comes to an end. Lessons learned
throughout the project are documented to help with future
projects. The team and resources are then released or reassigned,
and any final paperwork or administrative tasks are completed.
This phase ensures everything is finalized and reviewed for future
improvements.

Benefits of Effective Project Life Cycle Management

There are several benefits to following a clearly defined project life cycle:
• Improved project success rates: By following a clear set of phases,
risks are reduced, and project goals are more likely to be met. This
structured approach helps organize tasks and manage problems
effectively, making it easier to stay on track and achieve successful
outcomes.
• Enhanced stakeholder satisfaction: Clear communication and
regular updates throughout the project help build trust and
confidence among stakeholders. Keeping everyone informed about
progress and any changes ensures they understand what's
happening and feel involved. This openness helps prevent
misunderstandings and keeps stakeholders supportive of the
project.
• Optimized resource utilization: Effective planning and resource
management ensure that resources are used appropriately. This
helps avoid situations where too many resources are assigned to
one task or where resources are not used enough. Proper
 management makes sure resources are allocated efficiently,
improving the project's chances of success.
• Increased project visibility: Tracking project progress through clear
phases ensures transparency and accountability. It helps everyone
see how the project is progressing and holds team members
responsible for their tasks. This approach makes it easier to identify
issues early and keep the project on track.

What is a Feasibility Study?

A Feasibility Study in Project Management is a comprehensive analysis
conducted to determine the practicality and viability of a proposed project. It
assesses various aspects such as technical, economic, legal, operational,
and scheduling feasibility to ascertain if the project can be successfully
completed within defined constraints. The study helps stakeholders make
informed decisions about whether to proceed with the project or explore
alternative options based on the identified risks, costs, benefits, and
potential outcomes.
What's the Importance of a Feasibility Study?
1. Cost-Benefit Analysis: It permits the interested parties to carry out
an exhaustive evaluation of costs and advantages to envision
2. Project Viability: Evaluating the general viability and feasibility of
a proposed project is critical because it enables stakeholders to
determine if the project is profitable.
3. Market Demand and Competition: A feasibility study gives
insights into the possible purchaser base, marketplace possibilities,
and competitive surroundings by analyzing market demands,
trends, and opposition.
4. Making Decisions: Feasibility studies provide stakeholders the
information and understanding they need to decide whether or not
to move ahead with the task, exchange its scope or technique, or
scrap it entirely.
What is Included in a Feasibility Study Report?
1. Executive Summary: A executive summary is a quick assessment
of the feasibility study's important conclusions, guidelines, and
findings.
2. Introduction: A summary of the goals and goals to be carried out,
along with the reason and scope of the feasibility study.
3. Background and Context: Details about the project or business
endeavors under attention, such as its heritage, purpose, and
justification for conducting a feasibility study.
4. Market Analysis: Market study is the process of examining the
target market's size, trends, potential for growth, customer
demographics, and competitive environment. This section explores
possible opportunities and difficulties as well as evaluates the
demand for the suggested good or service.
5. Financial Analysis: A thorough financial analysis that includes ROI
calculations, cost estimates, revenue forecasts, and cash flow
projections. This part evaluates the project's prospective
profitability as well as its financial viability.
6. Risk assessment: It is the process of identifying and evaluating the
project's possible risks and difficulties, such as financial, technical,
commercial, and regulatory concerns. The methods for decreasing
and controlling those risks are described in this phase.
7. Resource Requirements: Plans for allocating sources and an
estimate of it's expenses are supplied in this segment.
8. Conclusion and Recommendations: An evaluate of the feasibility
study's essential conclusions and findings, together with
suggestions for decision-makers.
9. Appendices: Extra data, charts, tables, references, and supporting
documents that give the feasibility study more context or
information.
Types of Feasibility Study
1. Technical Feasibility Study: This type of feasibility take a look at
evaluating a project's technical capabilities, consisting of the
accessibility of the resources, technology, and knowledge had to
 deliver it out efficiently. It assesses whether or not the project may
be technically finished on time.
2. Economic Feasibility Study: Economic feasibility studies examine a
project's expenses and feasible benefits to determine whether or
not it's financially viable. This entails comparing the project's effect
on income, charges, and profitability as well as doing cost-benefit
analysis and calculating return on funding (ROI).
3. Operational Feasibility Study: Operational feasibility research
determine a assignment's operational factors, which include its
workflows, organizational structure, and strategies. They evaluate
how successfully and efficiently the project can be performed and
integrated into the current operations.
4. Social Feasibility Study: It evaluates how a task will have an effect
on stakeholders, neighborhood communities, and society as a
whole on a social and cultural stage. To decide if the project is
socially possible and suitable, they determine variables like social
acceptance, stakeholder participation, community effect, and
company social responsibility.

RFP:
In project management, RFP stands for Request for Proposal. It's a formal
document used to solicit bids or proposals from potential vendors or
contractors for a specific project or service. The RFP outlines project
requirements, expectations, and evaluation criteria, allowing vendors to
understand the scope of work and submit tailored solutions.

Purpose:
• Gather Information:
RFPs are used to gather detailed information about potential vendors, their
capabilities, pricing, and proposed solutions.
• Transparency and Competition:
They ensure a transparent and competitive bidding process, allowing organizations
to choose the best fit for their project.
 • Clear Expectations:
RFPs clearly define the project requirements and expectations for vendors,
minimizing misunderstandings and ensuring alignment.

Key Elements of an RFP:

• Project Overview: A brief description of the project, its goals, and objectives.
• Scope of Work: A detailed description of the tasks and deliverables required from
the vendor.
• Technical Requirements: Specific technical specifications, standards, and
functionalities that the project requires.
• Evaluation Criteria: The criteria that will be used to evaluate the proposals (e.g.,
cost, technical expertise, experience, etc.).
• Timeline and Milestones: A schedule outlining the key dates and milestones for
the project.
• Submission Instructions: Clear instructions on how vendors should submit their
proposals, including format, deadline, and contact information.

How RFPs are Used in Project Management:

1. Initiation:
The RFP is typically used in the project initiation phase to define the scope and
requirements of the project.
2. Procurement:
It's a key tool in the procurement process, used to solicit bids and negotiate
contracts.
3. Selection:
The proposals received in response to the RFP are evaluated based on the criteria
outlined, and the best vendor is selected.
4. Contract Negotiation:
Once a vendor is selected, the RFP serves as a basis for contract negotiations.

PMBOK Methodology in Project Management

PMBOK stands for Project Management Body of Knowledge.
PMBOK is a process-based project management methodology (actually a
framework), developed by the Project Management Institute (PMI).
1. It constitutes a collection of project management processes, best
practices, terminologies, guidelines, and tools, accepted as
standard within the project management industry.
2. It is widely used as a standard that allows organizations to
professionalize the role of project management resulting in better-
managed projects.

Here's how PMBOK can help with project management:

• Standardized Framework: PMBOK provides a standardized
framework for project management, which ensures consistency and
facilitates communication among project teams. It outlines
key project management processes, knowledge areas, and process
groups that are essential for managing projects effectively.
• Best Practices: PMBOK incorporates best practices from
experienced project managers and industry experts. It offers
guidance on how to initiate, plan, execute, monitor, control, and
close projects efficiently, based on proven methods and techniques.
• Common Terminology: PMBOK establishes common terminology
and definitions used in project management. This helps ensure
clarity and understanding among project stakeholders, reducing
the likelihood of misunderstandings or miscommunication.
• Knowledge Areas: PMBOK defines ten knowledge areas that
encompass various aspects of project management, including
scope, time, cost, quality, human resources, communications, risk,
procurement, stakeholder, and integration management. By
addressing these knowledge areas, project managers can ensure
comprehensive coverage of project management activities.
• Tools and Techniques: PMBOK provides a wide range of tools and
techniques that project managers can use to perform project
management activities. These tools and techniques include
methodologies, data gathering and analysis methods, decision-
making techniques, and communication strategies, among others.
Why Use PMBOK?
With so many other PM methodologies available, why should you consider
using PMBOK?
1. Project Success: To increase project success within the set
timeframe and budget. PMBOK enables you to do precisely that by
providing the best practices for project management.
2. Standardized Approach: PMBOK allows companies to standardize
practices across departments. So, it doesn’t matter whether a
project belongs to the development team or the operations team.
All projects are managed in the same manner.
3. Standardized System with other companies: Additionally, PMBOK
can help project managers work with a standardized system across
companies. If you leave your organization for another, you’ll still be
able to use the same practices described by PMBOK.
4. Project Risk Analysis: Think of PMBOK as a project management
handbook that you can refer to whenever you need guidance. The
methods documented within the PMBOK methodology can help
you manage potential project risks. The guide discusses what
works, giving you an idea of what you need to do to steer your
projects towards success. It also discusses what doesn’t work,
giving you the power to prevent the failure of projects.

10 PMBOK Knowledge Areas

The PMBOK fundamentals are defined as ten knowledge areas:
1. Integration
Project integration management can be simply defined as the framework
that allows project managers to coordinate tasks, resources, stakeholders,
changes, and project variables. Integration is the ability to bring together
everything you know so that you’re managing your project as a cohesive
whole rather than a collection of isolated entities. A great way to achieve
this is by using Project Service Automation (PSA) to access and manage all
your project processes from one central place.

2. Scope
Scope defines what your project will deliver. This involves collecting
requirements and preparing the work breakdown structure. As you define
your scope better, the better everyone will understand. As, per the project
manager, you need to ensure that all stakeholders clearly understand the
project’s purpose.

3. Time
Time management is very precise for every project life cycle. The time
knowledge area elaborates on the value of time tracking and how to do it.
You must track how much time people spend on tasks and how long the
project takes overall. Knowing how long tasks take helps you allocate
reasonable deadlines, thereby completing projects within set timeframes.
4. Cost
This project management knowledge area involves estimating project costs
to create a project budget. To do so, you’ll need to use cost-estimating tools
and techniques to make sure that the funds cover the project expenses and
are being monitored regularly to keep stakeholders or sponsors informed.
As, with other project management knowledge areas, the cost management
plan is the document where you’ll explain the method to establish the
budget, which includes how and if it will change and what procedures will
be used to control it. Each project has been estimated for cost, which means
including all resources such as materials, labor, equipment, and any other
things needed to complete the task.

5. Quality
A project can come in on time and within budget, but the quality isn’t the
same as perfection. It’s not practical to spend the time and resources to take
a project to perfection but if the quality isn’t up to standard, then the project
is a failure. This means that quality management is one of the most critical
project management knowledge areas.

6. Procurement
Procurement will impact the budget and schedule. Procurement
management planning starts by identifying the outside needs of the project
and how those contractors will be involved. Now conduct those
procurements by hiring the contractors, which includes a statement of work,
terms of reference, request for proposals, and choosing a vendor. You’ll
want to control the procurement process by managing monitoring and then
closing the contracts once the work has been done to everyone’s
satisfaction.

7. Human Resources
Before you put together a team, you first understand what human resources
you need to complete your project successfully. Once you have the right
team, you have to manage it. It is essential to encourage your resources to
grow the skills necessary to get to the finish line.

8. Communication
The Communication of the project ensures that all stakeholders know the
project’s progress and also have access to the information they need at the
right time. This also includes setting up a communication plan, establishing
channels for communication, and communicating effectively with team
members and other stakeholders.

9. Risk Management
Project risk management can flag upcoming problems and equip you with
the means to work around and through them, rather than causing major
complications. It includes quantitative risk analysis associated with the
project, developing contingency plans in case those risks materialize, and
monitoring risks throughout the project’s lifecycle. This knowledge area
involves identifying and assessing project risks. If you can manage your
firefighting by identifying major project risks and the mitigation plans
associated with them, your team and project requesters will be prepared
and more forgiving when issues in a project come up. It helps to understand
how to perform quantitative and qualitative risk assessments. With this
knowledge, you are better equipped to identify or predict potential threats
and prevent them from happening.

10. Stakeholder Management

They include not only the project requester but also team members who
have worked on the project as contractors or suppliers. They are an integral
part of any successful project plan. Not all stakeholders are equal in the
eyes of the project. The success rate or failure of a project depends on the
delivery of your project to the stakeholders.
Benefits of PMBOK
1. Standardized Approaches: PMBOK is a widely used standard, that
allows consistency in project execution across different
departments. It enables project managers to follow and apply the
established processes and guidelines, leading to improved project
outcomes.
2. Guidance of Best Practice: It incorporates proven techniques and
methods from various industries, reducing the likelihood of project
failures and increasing chances of success.
3. Improved Communication and Collaboration: PMBOK promotes
effective communication among stakeholders. It facilitates a clear
understanding of requirements, progress, and expectations,
resulting in smoother project execution.
4. Clear Project Phases and Processes: PMBOK defines five groups
of processes and provides guidelines for each phase, ensuring
systematic planning and execution and avoiding overlooked
activities and deliverables.
5. Increased Success Rates: By using the PMBOK plan, organizations
and departments can improve project success rates through
standardized practices, risk management, and clear project phases.
6. Comprehensive Knowledge Areas: PMBOK is expanded into 10
knowledge areas, equipping project managers with a well-rounded
understanding to address challenges effectively.
7. Risk Management Optimization: PMBOK ensures the risk analysis,
which provides guidelines to mitigate risks and reduce negative
impacts on project objectives proactively.

Disadvantages of PMBOK
1. Rigidity: PMBOK can be perceived as inflexible or limited in its
applicability in dynamic environments and agile methodologies.
2. Complexity: The extensive knowledge areas and processes can be
overwhelming, especially for smaller projects or organizations.
 3. Limited Contextual Guidance: PMBOK may lack specific guidance
for industry-specific or specialized projects.
4. Overloading of DocumentationYou must track: Detailed
documentation can lead to excessive paperwork and administrative
burden.
5. Lack of Emphasis upon Soft Skills: PMBOK focuses on technical
aspects and may overlook the importance of soft skills like
leadership and communication.
6. Limiting Focus on Organizational Culture: PMBOK may not fully
address the influence of organizational culture on project success.
7. Adaptability of Challenges: PMBOK may struggle to keep up with
rapidly changing project environments and emerging
methodologies.

PMBOK Project Examples

The PMBOK gives a comprehensive framework that can be applied to a
wide range of projects across different industries. Here, are some examples
of projects where PMBOK principles have been implemented:
1. Constructing the High-Rise Building
2. Software Development for a Mobile Application
3. Implementation of Enterprise Resource Planning System
4. Event Planning for a Conference

Business case:
A business case is a document that justifies undertaking a project or
investment by outlining its potential benefits, costs, and risks. It's a crucial
tool for decision-makers, providing evidence to support or reject a proposal.

Key elements of a business case:

• Problem Statement: Clearly defines the issue the project aims to address.
• Proposed Solution: Outlines the specific project or initiative being proposed.
 • Benefits: Explains the positive outcomes and value the project will deliver.
• Costs: Includes all relevant expenses, including capital costs, operational costs,
and opportunity costs.
• Risks: Identifies potential challenges and downsides associated with the project.
• Assumptions: Lists any underlying assumptions or conditions that must be met
for the project to be successful.
• Recommendations: Provides a clear recommendation for the project, along with
the rationale for that recommendation.

Why are business cases important?

• Justification: They provide a solid foundation for making informed investment
decisions.
• Transparency: They ensure that all stakeholders have a clear understanding of
the project and its potential impact.
• Communication: They facilitate effective communication and collaboration
among stakeholders.
• Risk Management: They help identify and mitigate potential risks early on.
• Resource Allocation: They guide the allocation of resources to projects that offer
the greatest value.

What Is a Project Plan?

Planning is an important process in project management that requires the
objectives, scope, schedule, and budget among other things to be clearly
outlined. Planning entails establishing a path for the project team that will
direct them through every stage of their life expectancy to get past together
efficiently and effectively down the derived objectives of this venture.
• It involves creating a comprehensive roadmap that guides the team
throughout the project lifecycle, from initiation to completion.

• Effective planning sets the foundation for successful project

execution by ensuring clarity, alignment with objectives, and
efficient resource utilization.
Key Components of Project Planning
Here are the following key components of Project Planning:
• Scope Definition: Clearly articulate project goals, deliverables, and
constraints with acceptance criteria to prevent scope creep.

• Time Planning (Scheduling): Develop a timeline outlining activity

sequences, task dependencies, and estimated durations, often
represented using Gantt charts.

• Resource Planning: Identify and allocate human resources,

equipment, and other necessary resources for efficient project
implementation.

• Cost Estimation and Budgeting: Estimate costs for each project

activity and create a budget to control and manage expenses
effectively.

• Risk Management: Identify potential project risks and develop

response or mitigation plans to ensure successful project
outcomes.

• Communication Planning: Determine communication methods,

frequencies, formats, and channels both within the project team
and with stakeholders.

6. Quality Planning: Establish a clear understanding of quality

requirements and implement procedures to ensure project
deliverables meet specified standards.

7. Procurement Planning: Identify external goods and services

required for the project, and map out the procurement process.

8. Stakeholder Management: Identify stakeholders, understand their

needs and expectations, and develop engagement strategies for
effective communication.
 9. Monitoring and Control Planning: Establish mechanisms for
tracking project progress, and performance, and implement
corrective actions if necessary to stay on course.

Why is Project Planning Important?

There are several reasons why project planning is so important, and its
significance manifests itself in different areas of managing projects. Below
are some key reasons why project planning is essential:
• Guidance and Direction: Planning creates a way that the project
team and stakeholders will be following to enable them to reach
their set goals. It establishes clear guidelines and goals for all who
will be involved.

• Resource Optimization: By effective planning; resources such as

time, money, and manpower are organized well. This eliminates
the over- and under-usage of resources hence guaranteeing that
any project is completed within its boundaries.

• Risk Management: Planning allows for identifying potential risks

and uncertainties quite early in the project. Recognizing these
challenges will allow the team to implement strategies aimed at
reducing risks or responding to them in order not to harm negative
impacts on your project.

• Time Management: Project planning requires a schedule describing

the order of tasks and how they logically depend. This facilitates
the team in terms of time management and allocation, so there can
be no delays as well to make sure that the project is completed
promptly.

• Budget Control: Through costing and budgetary planning, it

provides better financial control. Project managers will be able to
find out the spending aspects, recognize differences, and
 implement countermeasure actions for keeping the project under
budget limits.

• Scope Management: Well-defined, clear scope definition and

planning facilitate in prevention of so-called “scope creep” – an act
where additional work is thrown into the project without proper
evaluation. It ensures that the project remains on track with its
initial goals.

• Communication: Planning entails communication strategies that

support the efficient flow of information within the team and with
stakeholders. It ensures transparency, controls expectations and
handles issues before they can escalate.

• Quality Assurance: Planning involves the setting of quality

specifications and work procedures to guarantee that delivery
items are delivered as per defined requirements. This emphasis on
quality enables a project to be made successfully that meets or
even surpasses stakeholder requirements.

10. Stakeholder Engagement: Identifying and demystifying interest

groups during planning enables the creation of comprehensive
engagement techniques. This ensures stakeholders are well
involved and informed throughout the lifecycle of a project.

11. Monitoring and Control: The planning process sets up

possibilities for monitoring and control activities relating to the
progression of a project. This enables the project team to monitor
performance, note variations from these standards and intervene in
case of deviations.

Project charter and project scope :

A project charter and project scope statement both define the project, but at
different levels of detail and purpose. A project charter is a high-level
document that provides a general overview of the project, including its
purpose, objectives, and scope. It serves as the initial authorization for the
project and provides a foundation for planning. The project scope statement,
on the other hand, is a more detailed document that outlines the specific
deliverables, tasks, and requirements of the project. It defines the boundaries
of the project and helps ensure that the project stays on track and within
budget.

Project Charter:
• Purpose: To formally authorize the project and provide a high-level overview of
the project's goals, scope, and stakeholders.
• Content: Includes the project title, purpose, objectives, high-level scope, key
deliverables, stakeholders, timeline, and budget.
• Level of Detail: High-level and broad, not as detailed as the scope statement.
• Timing: Created in the initiating phase of the project lifecycle.

Project Scope Statement:

• Purpose:
To define the specific work required to complete the project, including deliverables,
tasks, and requirements.
• Content:
Includes a description of the project, acceptance criteria, deliverables, exclusions,
and any constraints or assumptions.
• Level of Detail:
More detailed than the project charter, outlining specific tasks and requirements.
• Timing:
Created during the planning phase of the project lifecycle.

Project scheduling:
Project scheduling involves creating a detailed timeline for all project tasks,
including their start and end dates, dependencies, and resource allocation. It's
a critical step in project management that helps ensure timely completion and
effective resource utilization.

Key Aspects of Project Scheduling:

• Defining Tasks and Dependencies:
Breaking down the project into smaller, manageable tasks and identifying their
relationships (which tasks must be completed before others).
• Assigning Start and End Dates:
Establishing realistic timelines for each task, taking into account dependencies and
resource availability.
• Allocating Resources:
Identifying the necessary resources (people, equipment, budget) for each task and
assigning them appropriately.
• Creating a Visual Timeline:
Using tools like Gantt charts to visually represent the project schedule and track
progress.
• Tracking Progress and Making Adjustments:
Regularly monitoring project progress against the schedule and making necessary
adjustments to ensure the project stays on track.

Benefits of Project Scheduling:

• Improved Project Management:
Provides a clear roadmap for the project, allowing for better planning, execution,
and control.
• Reduced Risk:
By identifying potential delays and dependencies early on, project schedules help
mitigate risks and ensure timely delivery.
• Enhanced Communication:
Project schedules serve as a communication tool, informing all stakeholders about
the project timeline and milestones.
• Better Resource Utilization:
By allocating resources effectively, project schedules help optimize resource
utilization and avoid over- or under-allocation.
• Increased Efficiency:
Project schedules contribute to more efficient project execution by providing a clear
framework for work and reducing confusion.

Defining a task set for a software project involves breaking down the entire development
process into manageable, structured activities. A standard task set for project scheduling
in a software project:

1. Project Planning

• Define project scope and objectives

• Identify stakeholders
• Create a high-level timeline
• Select project tools and technologies
• Risk assessment and mitigation planning

2. Requirements Analysis

• Gather user and system requirements

• Create use cases or user stories
• Prioritize requirements
• Validate requirements with stakeholders

3. System Design

• High-level system architecture design

• Database schema design
• UI/UX design
• Define module interactions and data flow

4. Implementation (Coding)

• Set up development environment

• Assign coding tasks to team members
 • Write unit tests
• Code development based on the design
• Code reviews and integration

5. Testing

• Perform unit testing

• Integration testing
• System testing
• User acceptance testing (UAT)
• Bug tracking and fixing

6. Deployment

• Prepare deployment documentation

• Set up production environment
• Deploy application
• Monitor initial performance

7. Maintenance

• Ongoing bug fixes

• Performance optimization
• Implement user feedback
• Plan updates or feature additions

Timeline charts :
A timeline chart in project management is a visual representation of a
project's schedule, showcasing tasks, milestones, and their associated
timelines. It's a tool for planning, tracking progress, and communicating the
project's overall plan to stakeholders. Often, these timelines take the form of a
horizontal bar chart, where each task is represented by a bar, displaying its
start and end dates.

Key features and benefits of timeline charts in project management:

• Visual representation of the project schedule:
Timeline charts provide a clear visual overview of the project's timeline, making it
easier to understand the sequence of tasks and their durations.
• Tracking progress and identifying potential issues:
By comparing the planned timeline with the actual progress, project managers can
easily identify any delays or potential issues that may arise.
• Communication and collaboration:
Timeline charts facilitate clear communication between project team members and
stakeholders, ensuring everyone is on the same page and aware of the project's
progress.
• Improved project planning and execution:
By visualizing the project schedule, project managers can better plan the project's
execution, allocate resources effectively, and identify potential bottlenecks.
• Different types of timeline charts:
Various types of timeline charts are available, including Gantt charts, PERT charts,
and others, each with its own strengths and weaknesses.

Common types of timeline charts used in project management:

• Gantt Chart:
A widely used bar chart that visually represents a project's schedule, including
tasks, start and end dates, milestones, and dependencies.
• PERT Chart:
A network diagram that shows the sequence of tasks and activities in a project, along
with their dependencies and estimated durations.

Steps to create a timeline chart:

• Identify all tasks and milestones: List all the tasks and milestones required to
complete the project.
• Determine the start and end dates for each task: Estimate the duration of each
task and assign start and end dates.
• Identify dependencies between tasks: Determine which tasks must be completed
before others can begin.
 • Choose a suitable chart format: Select the type of chart that best suits the
project's needs, such as a Gantt chart or PERT chart.
• Create the visual representation: Use project management software or other
tools to create the timeline chart, displaying the tasks, their timelines, and
dependencies.

Work Breakdown Structure (WBS) :

A Work Breakdown Structure (WBS) is a hierarchical decomposition of a

project's scope, breaking it down into smaller, manageable work packages. It's
a visual tool that helps project managers and teams understand the project's
scope, plan tasks, and assign responsibilities. Essentially, a WBS outlines
what needs to be done, by whom, and when.

Key Features of a WBS:

• Hierarchical:
The WBS starts with the overall project goal at the top and progressively breaks it
down into smaller components, sub-components, and finally, individual tasks or
work packages.
• Deliverable-oriented:
Each level of the WBS represents a specific deliverable or a set of deliverables.
• Visual:
The WBS is often represented as a diagram or tree structure, making it easy to
understand the project's scope and relationships between tasks.

Purpose of a WBS:
• Scope Definition:
A WBS helps define the project scope by identifying all the work that needs to be
done.
• Project Planning:
It provides a framework for planning tasks, allocating resources, and scheduling
activities.
• Task Assignment:
The WBS facilitates the assignment of tasks to specific team members or groups.
• Progress Tracking:
It enables the tracking of project progress by monitoring the completion of
individual work packages.
• Communication:
The WBS serves as a common language for the project team and stakeholders,
ensuring everyone is on the same page regarding the project's scope and
deliverables.

Creating a WBS:
• Define the Project Scope: Clearly define the project's objectives, deliverables, and
boundaries.
• Identify Major Deliverables: Break down the project into its main deliverables or
major components.
• Decompose Deliverables: Further decompose each deliverable into sub-
deliverables and work packages.
• Create Work Packages: Define specific tasks or work packages within each sub-
deliverable.
• Assign Resources: Allocate resources (personnel, equipment, etc.) to each work
package.

Benefits of Using a WBS:

12. Improved Project Planning:
A WBS helps project managers create a more comprehensive and detailed project
plan.
13. Better Resource Allocation:
It facilitates the efficient allocation of resources by providing a clear view of the
project's scope and tasks.
14. Enhanced Communication:
The WBS ensures that all project stakeholders have a shared understanding of the
project's scope and deliverables.
15. Accurate Cost and Time Estimates:
By breaking down the project into smaller tasks, it becomes easier to estimate the
cost and time required for each task.
16. Increased Project Control:
A WBS provides a framework for monitoring project progress and identifying
potential issues early on.

Network diagrams:
Network diagrams, specifically Activity on Arrow (AOA) and Activity on Node
(AON), are project management tools used to visualize project activities, their
durations, and dependencies. AOA diagrams represent activities as arrows,
with nodes representing milestones, while AON diagrams use nodes to
represent activities and arrows to show relationships. These diagrams help in
planning, scheduling, and tracking project progress, and are crucial for
determining the critical path, which is the longest sequence of tasks that
determines the minimum project completion time.

Key Concepts:
• Activities: Tasks or work items that consume resources and time.
• Nodes: Represent milestones, events, or points in time where activities start or
end. In AOA, they represent milestones, while in AON, they represent activities.
• Arrows: Connect nodes in AOA, representing the activity between those nodes. In
AON, arrows represent dependencies between activities.
• Dependencies: Relationships between activities, indicating the order in which
they must be completed.
• Duration: The estimated time an activity will take.
• Critical Path: The longest sequence of activities that determines the shortest
possible project completion time. Activities on the critical path have zero slack,
meaning any delay will delay the entire project.
• Slack: The amount of time an activity can be delayed without delaying the project
completion.

Activity on Arrow (AOA):

 • Arrows represent activities. The tail of the arrow denotes the start, and the head
denotes the end of the activity.
• Nodes represent events or milestones. They are often numbered for easier
identification.
• Duration is indicated on the arrow. This is the estimated time it will take to
complete the activity.
• Widely used in PERT (Program Evaluation and Review Technique). PERT
incorporates uncertainty in task durations using three time estimates (optimistic,
most likely, and pessimistic).

Activity on Node (AON):

• Nodes represent activities.
Each node contains information about the activity, including its name and duration.
• Arrows represent dependencies.
They show the order in which activities must be completed.
• Widely used in CPM (Critical Path Method).
CPM focuses on deterministic task durations, while PERT accounts for uncertainty.
• Often more intuitive and easier to create than AOA diagrams.
Project management software generally supports AON diagrams more readily than
AOA diagrams.

Benefits of Network Diagrams:

 • Visual representation of project tasks and dependencies: Helps teams
understand the project workflow and identify potential bottlenecks.
• Facilitates scheduling and planning: Allows project managers to create a timeline
and track progress.
• Helps identify the critical path and determine project completion time: Critical
path analysis is a key aspect of project management.
• Supports resource allocation: Network diagrams can help identify resource
constraints and ensure efficient allocation of resources.
• Enables better communication with stakeholders: Provides a clear visual
representation of the project plan.

Critical path method(CPM):

In project management, CPM stands for Critical Path Method. It's a project
scheduling technique that identifies the longest sequence of tasks (the
"critical path") that must be completed on time for the entire project to finish
on schedule.

Benefits of using the critical path method in project management:

• Show the project schedule visually.
• Highlight important tasks with CPM.
• Use CPM to find and handle risks.
• CPM helps the project team communicate better.
How to find the critical path in a project:
• Step 1: Identify all tasks required to complete the project
• Step 2: Determine the sequence of tasks
• Step 3: Estimate the duration of each task
• Step 4: Draw a network diagram
• Step 5: Identify the critical path
• Step 6: Calculate the float
 • Step 7: Monitor the critical path

Project Evaluation and Review Technique (PERT) is a procedure through

which activities of a project are represented in its appropriate sequence and
timing. It is a scheduling technique used to schedule, organize and integrate
tasks within a project. PERT is basically a mechanism for management
planning and control which provides blueprint for a particular project. All of
the primary elements or events of a project have been finally identified by
the PERT.
What is PERT Chart?
A PERT chart is a project management tool used to plan and schedule tasks,
illustrating the sequence and timing of project activities. The PERT chart is
used to schedule, organize and co-ordinate tasks within the project. the
objective of PERT chart is to determine the critical path, which comprises
critical activities that should be completed on schedule. This chart is prepared
with the help of information generated in project planning activities such as
estimation of effort, selection of suitable process model for software
development and decomposition of tasks into subtasks.
What does a PERT Chart Contain?
Here are the main components of a PERT chart:
• Nodes: it represents the task or milestones. every node represents
the task name and may also show duration of the task.
• Arrows: it indicates the direction or sequence of task and also
dependencies between them. suppose an array from A to B, then
task A must be completed before task B.
• Time Estimation: It estimates the time duration to complete the
task.
 • Critical Path: The critical path is the largest path in project
management that always results in the shortest time to complete
the project.
• Milestones: It is Key point in the project timeline that represent
significant events or deadlines

To create a PERT chart, we can follow the below steps:

Step 1: Identify Project Tasks
List all the tasks required to complete the project. Identifying tasks means
listing all the steps needed to complete a project. Start by figuring out what
the main goal is, then break it down into smaller actions. Ask team
members for ideas and use clear action words for each task.

Step 2: Define task dependencies

Defining task dependencies means figuring out which tasks must be
completed before others can start. Look at your task list and identify
connections by asking if one task relies on another. This helps you establish
the order of work, ensuring everything is done in the right sequence.

Step 3: Estimate Timeline

Estimating the timeline involves figuring out how long each task will take to
complete. For each task, think about the quickest time it could be done
(optimistic), the longest it might take (pessimistic), and the most likely time
it will actually take. This gives you a better idea of the overall project
duration and helps with planning.

Step 4: Calculate Critical Path

Calculate Critical Path means finding the longest sequence of tasks that
determines the shortest time to complete the project. Identify which tasks
can’t be delayed without affecting the overall project deadline, helping you
focus on what’s most important.
Step 5: Manage task progress
It involves tracking how each task is going. Regularly check if tasks are on
schedule, address any delays, and adjust plans if needed. This ensures the
project stays on track and any issues are resolved quickly.

Characteristics of PERT Chart

The main characteristics of PERT are as following:
• It serves as a base for obtaining the important facts for
implementing the decision-making.
• It forms the basis for all the planning activities.
• PERT helps management in deciding the best possible resource
utilization method.
• PERT take advantage by using time network analysis technique.
• PERT presents the structure for reporting information.
• It helps the management in identifying the essential elements for
the completion of the project within time.
• It specifies the activities that from the critical path.
• It describes the probability of completion of project before the
specified date.
• It describes the dependencies of one or more tasks on each other.
• It represents the project in graphical plan form.

Advantages of PERT Chart

It has the following advantages:
• Estimation of completion time of project is given by the PERT.
• It supports the identification of the activities with slack time.
• The start and dates of the activities of a specific project is
determined.
• It helps project manager in identifying the critical path activities.
• PERT makes well organized diagram for the representation of large
amount of data.
Disadvantages of PERT Chart
It has the following disadvantages:
• The complexity of PERT is more which leads to the problem in
implementation.
• The estimation of activity time are subjective in PERT which is a
major disadvantage.
• Maintenance of PERT is also expensive and complex.
• The actual distribution of may be different from the PERT beta
distribution which causes wrong assumptions.
• It under estimates the expected project completion time as there is
chances that other paths can become the critical path if their
related activities are deferred.

GANTT Chart:
Generalized Activity Normalization Time Table (GANTT) chart is type of
chart in which series of horizontal lines are present that show the amount of
work done or production completed in given period of time in relation to
amount planned for those projects. A Gantt Chart is a visual project
management timeline that consists of horizontal bars, usually color-coded.
1. These bars show all the project tasks, when they are due, who is
responsible, and how long each task will take.
2. Therefore, Gantt charts illustrate the start and finish dates of the
terminal elements and summary elements of a project.
3. In other words, the Gantt chart assembles all pieces of tasks that
are relative to a fixed deadline.
What is the Purpose of a Gantt Chart?
Essentially, a Gantt chart arranges project tasks on a visual timeline, making
it simple for project, programme, and portfolio managers to sketch
out project plans. Gantt charts are utilised in resource management, project
planning, project scheduling, and project tracking, among many other areas.
• Break down the project into manageable tasks, identify
dependencies, and allocate resources effectively.
• Determine the sequence and duration of tasks, establishing a
timeline for the project.
• Monitor the progress of tasks, compare planned versus actual
timelines, and identify any delays or issues.
• Share project plans and progress with stakeholders, team
members, and clients in a clear and understandable format.
• Ensure that all team members are aware of their responsibilities
and deadlines, facilitating collaboration and coordination within the
project.
Basic components of a Gantt chart
Gantt charts could initially appear difficult. However, if you can interpret
them, you'll be able to determine precisely where your initiatives stand and
what has to be done to steer them towards success.
Understanding how the various components work together to create a gantt
chart is the key to reading one. Here are the following components of a
Gantt Chart:
• Task list
• Timeline
• Dateline
• Bars
• Milestones
• Dependencies
• Progress
• Resource assigned

Features of Gantt Chart

Here are the following features of the Gantt Chart:
1. Helps in Project Management
The Gantt Chart gives us a high-level interpretation of the Project
timeline using which we can schedule our Project Delivery, wrap up the
pending tasks, and extend the timeline according to the requirement.

2. Simple to Use
It has a drag-and-drop feature that enables us to easily make changes or
update the timeframes of the tasks.

3. Supports Integration with Existing Projects

You can easily integrate the Gantt Chart into your existing Project
Workflow. Therefore, you do not need to create the Gantt Log from scratch.

4. Ideal for Complex Projects

If the project structure is complex with multiple tasks or issues and the
subtasks within them, the Gantt Chart serves as a proven solution to easily
manage the complex work breakdown structure.
5. Provides Useful Insights along with Timelines
A Gantt chart does not only deliver an overview of the sequence of events,
but it also provides important information for project managers. Also, it
visualizes the critical path and hence guides the schedulers’ attention to
those activities that are crucial and deserve a specific treatment

How to Create a Gantt Chart?

Although creating a Gantt Chart depends on multiple factors such
as project status, its current phase, team size, deadlines, structure of tasks,
and subtasks, it is easy to create it for your Project. The various steps in
creating the Gantt Chart are stated below.
• Step 1: List out every task you will need to complete to finish the
project. For example, you can mention tasks such as Backend
Configuration, Database Integration, Testing and Validation,
Deployment, etc.
• Step 2: Define chronological order and put each task in order of
when it needs to be done. Also, identify whether some tasks
depend on others or they need to be completed before any other
tasks.
• Step 3: Estimate how much time it will take you to complete each
task to a level of quality that has been defined during the
requirement elicitation and gathering.
• Step 4: In this step, assign a realistic due date and start dates for
each task. You should analyze whether the task execution will need
some extra time or not.
• Step 5: Fill up your Gantt Chart and Continuously update your
Gantt chart with actual timelines.

Advantages of Gantt Chart

Here are the following advantages of Gantt Chart:
1. Easy identification of tasks: The Gantt Chart helps us to easily
identify the various tasks, their inter-relation, and the Progress of
the tasks.
 2. Helps to evaluate critical resources utilization: We can evaluate
the critical Resources and their utilization, Dependencies, and
Impacts of schedule changes in the Gantt Chart. Along with this,
we can also create Visual alerts in case of scheduling conflicts.
3. Helps to manage tasks order: The Gantt chart equips the project
experts with the capabilities to manage the order in which tasks
need to be carried out so that we can easily identify the priority of
the activities. In Project Execution.

Disadvantages of Gantt Chart

Here are the following disadvantages of Gantt Chart:
1. Time-consuming: Setting up the Gantt Chart includes various
activities such as planning the tasks, resources, timelines, due
dates, dependencies, etc. This makes the Gantt Chart a time-
consuming tool for the project.
2. Can turn into complex sheets: Putting too much information about
the Project timelines can turn the Gantt Chart into complex sheets,
due to which timeline management becomes challenging.
3. Sometimes tough to update Gantt Chart: If the Project includes
the switching between multiple tools and platforms for the task
execution, it is tough to update the Gantt Chart we need to
configure it repeatedly, as the workflow switches to another
platform.

Gantt Chart Examples

Here are a few examples of how Gantt charts can be used:
1. Construction Projects: Gantt charts help construction project
managers schedule tasks like excavation, building, and finishing
work, ensuring that each phase is completed on time and in the
correct sequence.
2. Software Development: In software development, Gantt charts
assist teams in planning tasks such as coding, testing, and
debugging, providing a visual timeline to coordinate efforts and
meet project milestones.
 3. Event Planning: Event planners use Gantt charts to organize tasks
like venue booking, vendor coordination, and marketing, enabling
them to manage multiple aspects of an event simultaneously and
ensure everything is ready by the event date.
4. Research Projects: Researchers utilize Gantt charts to plan
research activities such as literature review, data collection,
analysis, and writing, helping them stay on track and manage their
time effectively throughout the project.

Example :
Nowadays, there are many companies and teams that use Gantt chart to
plan, schedule, and execute their projects. Some of them are consulting
agencies, manufacturing companies, Marketing teams, Construction
companies, etc. Below is an example of Gantt chart:
Tracking the schedule:
Tracking the schedule in project management involves monitoring the
progress of tasks against the planned timeline and making necessary
adjustments to keep the project on track. This includes using tools like Gantt
charts and project tracking software to visualize the schedule, identify
potential delays, and ensure timely completion of tasks and milestones.

1. Planning and Baseline:

• Define Project Activities:
Clearly outline all the tasks and activities needed to complete the project.
• Assign Tasks:
Allocate tasks to specific team members and establish dependencies between
tasks.
• Estimate Durations:
Estimate the time required for each task to be completed.
• Create a Schedule:
Develop a detailed timeline, often using tools like Gantt charts, to visualize the
project schedule.
• Establish a Baseline:
Set a baseline for the project, including the initial schedule, budget, and scope. This
baseline serves as a reference point for tracking progress.

2. Monitoring and Tracking:

• Track Progress:
Regularly monitor the progress of tasks against the planned schedule.
• Identify Deviations:
Recognize any deviations from the planned schedule, such as delays or unexpected
issues.
• Analyze Variance:
Analyze the reasons for deviations and assess their impact on the project timeline.
• Use Tracking Tools:
 Utilize project tracking software, Gantt charts, or other tools to visualize progress
and identify potential problems.
• Regularly Update the Schedule:
Update the schedule as needed to reflect actual progress and changes to the
project plan.

3. Adjustments and Mitigation:

• Take Corrective Action: Implement actions to address deviations and get the
project back on track.
• Adjust the Schedule: If necessary, adjust the schedule to accommodate changes
or delays.
• Communicate Changes: Communicate any changes to the schedule to
stakeholders to ensure everyone is aware of the current status.
• Risk Management: Continuously monitor and manage risks that could impact the
project schedule.

4. Tools and Techniques:

• Gantt Charts:
A visual representation of the project schedule, showing tasks, milestones, and
their start and end dates.
• Project Tracking Software:
Software that allows for real-time monitoring of project progress, resource
allocation, and task management.
• Work Breakdown Structure (WBS):
A hierarchical decomposition of the project into smaller, more manageable tasks.
• Milestone Tracking:
Monitoring the completion of key milestones in the project lifecycle.
• Time Tracking:
Recording the time spent on specific tasks to identify potential bottlenecks and
optimize resource allocation.
Earned Value Analysis:
Earned Value Analysis (EVA) is a project management technique that helps
track project performance by comparing the actual work completed to the
planned budget and schedule. It provides a clear measure of project progress,
cost, and schedule deviations. By analyzing earned value, project managers
can make informed decisions, identify potential issues, and take corrective
actions to keep the project on track.

What is Earned Value Analysis?

EVA is a method that allows project managers to measure the amount of work
actually performed on a project beyond the basic review of cost and schedule
reports. It provides a way to measure project progress and forecast the
project's total cost and completion date based on the work done.

Methods For Earned Value Analysis

• 0/100 Technique: The technique where a task is assigned a value
of zero until such time that is completed when it is given a value of
100% of the budgeted value.

• 50/50 Technique: The technique in which a task is assigned a 50%

value as soon as it is started and then given a value.

• 75/25 Technique: The technique where a task is assigned 75% on

starting and 25% on completion.

• Milestone Technique: The technique where a task is given a value

based on the achievement of milestones that have been assigned
values as part of the original budget plan.

• Percentage Complete: In some cases, there may be a way of

objectively measuring the amount of work completed.
Stages in Earned Value Analysis
• Creating the baseline budget: This is the first stage in setting up
EVA. This budget is based on the project plan. It predicts the
earned value through time. Normally, it is measured in person
hours or workdays, for example: in a software development project.

• Monitoring Earned Value: The second stage is monitoring the

earned value as the project progresses. This is achieved by
monitoring the completion of each task. Actual cost(AC) is the
actual cost of each task and it can be analyzed and collected.

• Schedule Variance(SV): This is the third stage which is measured in

cost as EV-PV which is the deviation between planned work and
completed work.
Example: Consider these values,
PV =40000
EV=35000
SV=35000-40000 = -5000

Here the calculated SV value is negative and hence we conclude

that the project is behind the original schedule.

• Time variance(TV): The difference between the current time and

the time when the achievement of the earned value was
planned to occur.
• Cost Variance(CV): This value is the difference between the
actual cost and the earned value. Using this value we can
estimate the accuracy of the original cost scheduled for the
project. If the CV values are found to be negative, we conclude
the project is over cost.
Advantages of Earned Value Analysis (EVA)
• Project Performance Measurement: EVA provides a
comprehensive method for measuring and assessing the
performance of a project. It helps project managers gain a clear
understanding of how well a project is progressing in terms of
cost and schedule.
• Objective Performance Metrics: EVA relies on objective metrics,
making it less susceptible to subjective interpretations. This can
lead to more accurate assessments of project performance.
• Integration of Cost and Schedule: EVA combines cost and
schedule performance, allowing project managers to see the
relationship between these two critical aspects of project
management. This integration can help in identifying issues
early and making informed decisions.
• Early Issue Identification: EVA can highlight problems in project
execution early, enabling project managers to take corrective
actions promptly. This can prevent cost overruns and schedule
delays.
• Benchmarking: EVA allows for benchmarking project
performance against planned targets and historical data. It
helps project managers assess whether their project is on track
compared to similar projects.
• Effective Communication: EVA provides a standardized way to
communicate project performance to stakeholders. Charts and
reports generated from EVA data can make it easier for
stakeholders to understand the project's status.
Disadvantages of Earned Value Analysis (EVA)
• Complexity: EVA involves complex calculations and terminology,
which can be challenging for project teams to understand,
especially for smaller projects or teams with limited expertise.
• Resource-Intensive: Implementing EVA requires tracking
detailed data and maintaining comprehensive records. This can
be resource-intensive, and some organizations may lack the
necessary tools or resources for effective EVA implementation.
• Subjectivity in Earned Value Calculation: The "earned value"
itself can be subject to interpretation, especially in situations
where there are gray areas regarding the completion of work
packages or milestones.
• Assumption of Linear Progression: EVA assumes linear
progression, which means that it may not work well for projects
with irregular or non-linear progress patterns, such as research
and development projects.
• Time-Consuming: Calculating and updating EVA metrics can be
time-consuming, which may not be suitable for projects that
require quick decision-making and frequent changes.
• Focus on Metrics vs. Problem Solving: Overemphasis on EVA
metrics can sometimes lead to a focus on numbers rather than
addressing the underlying issues causing performance
problems.