ADAPTIVE

SOFTWARE
ENGINEERING
Cohort E27 Group

__________

SOFTWARE ENGINEERING, MIS &

DEVOPS
Adaptive Software Engineering
Copyright © 2022 by Cohort E27 Group

All rights reserved. No part of this book may be reproduced or

transmitted in any form or by any means without written
permission from the author.

ISBN: XXXXXXXXXXXXX

Printed in the USA by 48 Hour Books (www.48HrBooks.com)

2
DEDICATION
Dear Software Engineering Students,
It is with immense pleasure and pride that I dedicate this book to
each one of you, the aspiring software engineers of tomorrow.
This dedication is a tribute to your dedication, passion, and
pursuit of knowledge in the dynamic world of software
engineering.
Why Dedicated to Software Engineering Students?
I understand the challenges and opportunities that lie ahead as
you embark on your journey into the ever‐evolving field of
software engineering. This dedication represents my unwavering
belief in your potential and my commitment to support your
growth and development as professionals.
Gratitude and Encouragement
We are grateful for the opportunity to share our knowledge and
experiences with you through this book. As you delve into the
pages, I hope to inspire and encourage you to explore, innovate,
and embrace the art and science of software engineering.
Empowering the Future
In dedicating this book to you, We wish to empower you with the
tools, principles, and best practices that will serve as a strong
foundation for your future endeavors. Software engineering is a
journey of continuous learning, and we hope that this book will
equip you with the essential skills to thrive in an ever‐changing
technological landscape.
Final Words
As you navigate the complexities of software engineering,
remember that each line of code you write has the potential to
shape the world. Embrace the challenges, celebrate the victories,
and never stop seeking knowledge and growth.
May this book be a guiding light on your path to becoming an
exceptional software engineer.
With warm regards and best wishes,

Cohort E27 Group.

3
TABLE OF CONTENTS
Dedication ................................................................................... 3
Foreword ..................................................................................... 7
Introduction ................................................................................. 9
Instructional Objectives (Course Objectives) Error! Bookmark
not defined.
Introduction ............................................................................. 11
Chapter 1. description ............................................................. 11
Chapter 1.2. Software Engineering, Software Process and
Product, Software Engineering Practice, Software Myths .. 23
Introduction ............................................................................. 23
description .................................. Error! Bookmark not defined.
Software Engineering .............................................................. 23
The Software Process and product: ....................................... 24
Process framework activities: ................................................. 25
Umbrella Activities:................................................................. 29
Software Engineering Practice:.............................................. 31
Software Myths ........................................................................ 31
Management Myths ................................................................. 31
Customer Myths ...................................................................... 33
Practitioners Myths ................................................................. 34
chapter 1.3. Process Models: Generic process model, prescriptive
process models .......................................................................... 36
Introduction ............................................................................... 36
description ................................................................................. 36
Introduction: .............................................................................. 36
PROCESS ASSESSMENT AND IMPROVEMENT ........... 41
PRESCRIPTIVE PROCESS MODELS ................................ 42
CHAPTER 1.4. Specialized Process Models, Unified Process . 54

4
Introduction ............................................................................... 54
description ................................................................................. 54
SPECIALIZED PROCESS MODELS .................................. 54
The UNIFIED PROCESS ....................................................... 57
chapter 1.5. Personal And Team Process Models Course
Description ................................................................................ 60
Introduction ............................................................................... 60
description ................................................................................. 60
Chapter 1.6. Reverse Engineering ............................................. 73
Introduction ............................................................................... 73
description ................................................................................. 73
chapter 2.1. Requirements Development Methodology -
Specifying Requirements ........................................................ 76
Introduction ............................................................................... 76
Specifying Requirements: ....................................................... 79
Requirements Engineering activities ..................................... 80
chapter 2.4. Achieving Requirements Traceability ................. 122
chapter 2.5. Reviews, Walkthroughs and Inspections, SRS VS
User Stories ............................................................................. 138
Chapter 2.6. Agile Modelling, Extreme Programming ........... 148
Integration Testing ................................................................ 198
Risk Prediction: ....................................................................... 227

CHAPTER 4.7. PROJECT PLANNING ESTIMATION

232

5
FOREWORD
Adaptive Software Engineering
Forword’s from Prof. Senthil, HOD‐H, KLU.
It is with great pleasure and enthusiasm that I introduce you to
this exceptional book on Adaptive Software Engineering. As an
experienced professional in the field of software engineering, I
have witnessed the remarkable evolution of this discipline, and I
firmly believe that adaptive practices are at the forefront of
shaping its future.
The Need for Adaptability
In today's fast‐paced and dynamic technological landscape, the
demand for software that can swiftly adapt to changing
requirements has never been more critical. The traditional
methods of software development, while valuable, are often
insufficient to meet the challenges posed by rapidly evolving user
needs, emerging technologies, and unpredictable market trends.
Embracing Change
The hallmark of adaptive software engineering is the recognition
that change is not an impediment but rather an inherent and
inevitable aspect of the development process. Instead of
resisting change, adaptive practitioners embrace it, utilizing
flexible methodologies and innovative tools to deliver software
that remains relevant and effective throughout its lifecycle.
Book Overview
This comprehensive book provides a profound exploration of
adaptive software engineering principles, methodologies, and
techniques. From the early stages of requirements elicitation to
the final stages of deployment and maintenance, the authors
offer a systematic approach to addressing change and
uncertainty. Through insightful case studies and real‐world
examples, they illustrate how adaptive practices can lead to more
robust, scalable, and user‐centric software solutions.

Prof. Senthil, HOD‐H,

KLU.

7
INTRODUCTION
Welcome to the fascinating world of Adaptive Software
Engineering. In this book, we embark on a journey to explore the
cutting‐edge practices, methodologies, and principles that define
this rapidly evolving discipline. Adaptive software engineering
represents a paradigm shift in how we approach software
development, emphasizing the ability to embrace change and
uncertainty as catalysts for innovation and improvement.
What This Book Offers
In this comprehensive book, we delve deep into the world of
adaptive software engineering. We begin by laying the
groundwork with an exploration of the fundamental concepts
and principles that underpin adaptive practices. From there, we
move on to practical methodologies such as Agile, Scrum, and
Kanban, which enable teams to respond effectively to change
while maintaining high levels of productivity and collaboration.
We discuss techniques for requirements elicitation and
management in an adaptive environment, emphasizing the
importance of constant communication and feedback with
stakeholders. You will gain insights into effective project
planning, risk management, and continuous integration
strategies that ensure the delivery of high‐quality software, even
in the face of uncertainties.
Real‐World Examples and Case Studies
Throughout this book, we illustrate adaptive software
engineering concepts with real‐world examples and case studies.
These examples offer tangible insights into how adaptive
practices have been successfully applied to diverse projects,
ranging from small startups to large‐scale enterprise
solutions.Top of Form

9
 CHAPTER ONE
CHAPTER 1.1. NATURE OF SOFTWARE,
SOFTWARE APPLICATION DOMAINS,
UNIQUE NATURE OF WEB APP.

INTRODUCTION
“Software and Software Engineering: Nature of software,
software application domains, unique nature of web
applications”
The objectives of this session are to introduce software and
to provide Software Characteristics. When students have
read this session content, Student will
 Understand what software is and why it is important;
 Understand the Nature of Software.
 Understanding different types of software systems may
require different areas in real‐time environments
(Applications of software).

CHAPTER 1. DESCRIPTION
Software is essential for the functioning of government,
society, and national and international businesses and
institutions. We can’t run the present modern world
without software. National and international
infrastructures and utilities are controlled by software’s (i.e.
computer‐based systems), and most electrical products
built and includes a software, for computing and controlling
purpose. Industrial manufacturing and distribution is
completely computerized, as is the financial system.
Entertainment, including the music industry, computer

11
games, and film and television, is software intensive. More
than 70% of the world’s population have a software‐
controlled mobile phone, and, by 2016, almost all areas
used software these will be Internet‐enabled.
1.1. The Nature of Software:
The evolving role of Software:
In general term software is referred to as an organized set
of instructions which, when executed by means of given
computing device, delivers the desired results by
considering various process and functions.
It is an organized set of instructions capable of accepting
inputs, processes it and delivers the present in the form of
functions and performance as expected by the user. apart
from this it refers to records to help and guide the users to
efficiently deal with it and also, so it is in now a days daily
word in the form of package accumulating the design
documents, source code, installations implementation
manuals, operations system manuals respectively.
Software Definition:
Software is:
(1) instructions (computer programs) that when executed
provide desired features, function, and performance.
(2) data structures that enable the programs to adequately
manipulate information and
(3) documentation that describes the operation and use of
the programs.
Software Evolution:
The flexibility of software system is one of the reasons, why
more and more software is being incorporated in large,
complex systems. It is very expensive to make changes to
the hardware once it is manufactured. However, changes to
software can be made at any time during or after the
system development.

12
There is always a difference between the process of
software development and its maintenance. Software
development is creative activity, where a software system
is developer from initial concept through a working system.
Software maintenance is the process of changing the
system ones it has gone into use.
Few software systems are now completely new systems
and development, and maintenance are continuous.
Software evaluation is an evaluation process where
software is continually changed over its lifetime in response
to changing requirements.
The evolutionary process is illustrated in the figure

Figure 1: Evolutionary Process

In practical terms, the phases of software process can be
mapped to what are known as evaluation patterns
containing parallel activities. Let the symbol (||) symbolize
parallel. The software evaluation pattern can be formulated
as a collection of parallel activities as follows.
Software evaluation process = where || why || what ||
when || how || By –whom.

13
Characteristics of Software
We know that a software is an organized collection of
instructions which when processed using a computing
device produces the desired output by considering various
processes and functions. But it is definition does not bring
maturity. To derive a suitable definition, it should be
analysed through various levels of perception which is only
possible bye realizing its characteristics. Detailed
instructions on its characteristics are given below.
 Software is developed or engineered; it is not
manufactured in the classical sense.
 Software doesn't "wear out."
 Although the industry is moving toward component‐
based construction, most software continues to be custom‐
built.
 Software is developed or engineered, it is not
manufactured in the classical sense
Explanation: In order to analyse the above characteristics,
the difference between software development process and
other hardware development activities is provided in the
most abstract notation.
While developing a software and other hardware
manpower involves, but the quantity and their way of
approach remains significantly different. In both the
manufacturing process will be left out with certain end
products but the efforts applied in them remain different,
finally both the activities are initiated with determination of
building high quality products but their quality maintaining
activities differ.

Hence, with this specification we can conclude that

software is a developed are engineered, it is not
manufactured in the classical sense.

14
 Software doesn't "wear out."
Explanation: To analyse the above characteristics, we shall
again turn our attention towards the development life cycle
of hardware and software. Best mode of comparison
remains the graphs where, various aspects during their life
(hardware and software) can be e perfectly analysed. We
initially begin with graph describing various consequences
related to the hardware.

Figure 2: Graph depicting the failure curve for Hardware

Now consider the above graph. By analysing the curve, we
can estimate that during initial days of manufacturing the
hardware suffers from severe defects due to which the
curve initiates from high failure. When this failure is curbed,
the curve attains a study success rate, but even the success
rate does not last longer and mini external editors' entities
such as vibration, environmental effects, temperature
changes, dust etc.., act barrier to its prolonged success
causing it to wear out steadily. Now, analyse, the same
aspects of software, following is a curve depicting various
consequences of its during its lifetime.

15
 Figure 3: Software Failure Curve

Initially considered ideal curve. It indicates that, during

initial days of software, it suffers from unexpected effects.
But as software does not get affected with climatic or other
environmental changes as that of hardware, hands, it
comes down to steady success rate by suitable correcting
the errors provided correction of errors does not introduce
new errors. But this is never the case, hence, it is referred
as ideal curve. Still these stays, the ideal crew remains
analogous to actual curve.

Whenever we consider the actual curve, it declines from its

initial failure rate and comes down steadily to point, where
it demands Saturn changes to be applied because
introducing other defects and hence, a spike is observed in
the curve.
Now, efforts are applied to nullify these defects and hence,
the spike comes down to a point, where it demands change
and again the same process is repeated which gives rise to
other spikes. While change is made to the curve, the main
cause of the effect reminds due to the changes made to the

16
software to certain extent and due to the side effects of the
software to large extent.
 Although the industry is moving toward
component‐based construction, most software continues
to be custom‐built.
Explanation: To analyse the meaning of above‐mentioned
statement, we should have a clear distinction between
hardware and software manufacturing processes. In recent
Trend software engineering process to rely on certain
reusable components along with a few new components in
framing the sentence software. The reusable components,
if analysed in terms of object‐oriented programming,
referred to check boxes, the Drop‐Down menus, buttons,
layouts, etc..

Nature of Software
 Software is a Product, it Transforms information‐
produces, manages, acquires, modifies, displays or
transmits information and delivers computing potential of
hardware and networks

 Software is a vehicle for delivering a product, it

Controls other programs (operating system), Effects
communications (networking software) and helps build
other software (software tools & environments)

The Unique Nature of Web Apps

Applications of Software
Following are certain categories of software often referred
as applications of software, those are
 System software
 Application software
 Engineering/scientific software

17
 Embedded software
 Product‐line software
 Web Apps (Web applications)
 AI software

 System software— Software system refers to a

piece of software capable providing services to the other
applications. Good examples of software's are categorized
in two sets. One of the sets includes file management
utilities, compilers, editors, etc..,. The system software
belonging A category I can easily be applied to quite
complex and determine applications, on the other hand,
category 2 can easily be applied to highly indeterminate
applications. In either category, this software effectively get
bond with the system hardware, which can tackle multiuser
and many more

 Application software— Application software

usually reside can a single system which remains capable of
satisfying only requirement.

 Engineering/scientific software— Software is is

being developed to ease the growth in engineering and
scientific areas. Engineering and scientific software
development requires large area of information to be
covered. For these fields applications have been developed
which cover areas from astronomy to volcanology,
molecular Biology to automated manufacturing and from
automotive stress to space shuttling orbital dynamics.

 Embedded software— Embedded software is

developed to control the products under consumer and
industrial markets. This software resides in the read only

18
memory of the product. The software is developed to
perform Limited and esoteric functions of the product.

 Product‐line software—designed to provide a

specific capability for use by many different customers.
Product‐line software can focus on a limited and esoteric
marketplace (e.g., inventory control products) or address
mass consumer markets (e.g., word processing,
spreadsheets, computer graphics, multimedia,
entertainment, database management, and personal and
business financial applications).

 Web applications—called “Web Apps.

Communication is the main criterion for a quick growth of
any Enterprise. So, so the change after time software
packages now been updated that it could transfer
information on the web these packages are used to develop
highly sophisticated web‐based software simultaneously
eases its usage and ensures safe transfer of data over
network.

Web‐based software or application can be developed by

using languages or r packages like
java, VB.NET, CGI, Java Script, HTML, DHTML, etc.

 Artificial intelligence software— This type of

software makes use of numerical algorithms to solve
Complex problems that's not amenable through
computation or straight forward analysis. One of the most
active artificial intelligence areas in the " expert systems"
other application areas for a software include pattern
recognition, theorem proving, and game planning.

19
New Challenges –Software
Millions of software engineers worldwide are hard at work
on software projects in one or more of these categories. In
some cases, new systems are being built, but in many
others, existing applications are being corrected, adapted,
and enhanced. It is not uncommon for a young software
engineer to work a program that is older than new
challenges have appeared on the horizon:
 Open‐world computing—the rapid growth of
wireless networking may soon lead to true pervasive,
distributed computing. The challenge for software
engineers will be to develop systems and application
software that will allow mobile devices, personal
computers, and enterprise systems to communicate across
vast networks.

 Net sourcing— With unpredictable growth of

internet, the software engineers are now forced to look
forward for the development of simple at the same time
more sophisticated software's so that, it is the end user who
can take lodge benefits from such applications, add internet
in today's world, is not only acting like engine but also the
major source for grabbing large volumes of data.

 Open source— As the name suggests, open source

is also future expected software development, where even
software can be available to all users irrespective of their
profession, so that, they can modify these software's and
make them to adjust to their requirements. In this case the
ingenious must thrive to make the software descriptive and
compatible so that they can be easily moulded.

20
 Ubiquitous Computing: In today's world, the major
source of data communication is by means of wireless
circuits, hence, it is expected that, in future such circuits can
be a flight in developing distributed systems. Hens such
application will also remind a challenge to the software
engineers.

Unique nature of web Apps

With the advent internet technologies in today's world,
many people are forced to believe that the new economy
world created through webapps. Today, Web Apps have
evolved into sophisticated computing tools that not only
provide stand‐alone function to the end user, but also have
been integrated with corporate databases and business
applications. Web‐based systems and applications “involve
a mixture between print publishing and software
development, between marketing and computing, between
internal communications and external relations, and
between art and technology.” The following attributes are
encountered in the vast majority of Web Apps.
 Network intensiveness. A WebApp resides on a
network and must serve the needs of a diverse community
of clients.
 Concurrency. A large number of users may access
the WebApp at one time.
 Unpredictable load. The number of users of the
WebApp may vary by order of magnitude from day to day.
 Performance. If a WebApp user must wait too long
(for access, for server‐side processing, for client‐side
formatting and display), he or she may decide to go
elsewhere.

21
 Availability. Although expectation of 100 percent
availability is unreasonable, users of popular Web Apps
often demand access on a “24/7/365” basis.
 Data driven. The primary function of many Web
Apps is to use hypermedia to present text, graphics, audio,
and video content to the end‐user.
 Content sensitive. The quality and aesthetic nature
of content remains an important determinant of the quality
of a WebApp.
 Continuous evolution. Unlike conventional
application software that evolves over a series of planned,
chronologically spaced releases, Web applications evolve
continuously.
 Immediacy. Although immediacy—the compelling
need to get software to market quickly—is a characteristic
of many application domains, Web Apps often exhibit a
time to market that can be a matter of a few days or weeks.
 Security. Because Web Apps are available via
network access, it is difficult, if not impossible, to limit the
population of end‐users who may access the application.
 Aesthetics. An undeniable part of the appeal of a
WebApp is its look and feel

22
CHAPTER 1.2. SOFTWARE ENGINEERING,
SOFTWARE PROCESS AND PRODUCT, SOFTWARE
ENGINEERING PRACTICE, SOFTWARE MYTHS

INTRODUCTION

SOFTWARE ENGINEERING
Software engineering is the application of principles used in
the field of software engineering, which usually deals with
projects, to the design, development, testing, deployment,
and management of software systems.
Definition: Software engineering is a detailed study of
engineering to the design, development and maintenance
of software projects. Software engineering was introduced
to address the issues of low‐quality software projects.
Problems arise when software generally exceeds timelines,
budgets, and reduced levels of quality.
The IEEE definition:
Software Engineering is the application of a Systematic,
Disciplined, Quantifiable approach to the development,
operation, and maintenance of software; that is, the
application of engineering to software. This is also known
as a Layered Technology as shown below.

23
 Fig:1 Software Engineering

(Layered Technology)

THE SOFTWARE PROCESS AND PRODUCT:

A Process is known as collection of activities, actions, and
tasks that are performed when some work product is to be
created as a software product. Software is the collection of
instructions in the form of programs to govern the
computer system and to process the hardware
components. To produce a software product a set of
activities are used. These are called as software process.
(Eg: communication with stakeholders or the end users,
create the architectural design based on the customers
need, constructing the code and conducting unit test to
produce the software all steps are known as software
process).

24
Software Development: In this process, designing,
programming, documenting, testing, and bug fixing is done.

Components of Software:
There are three components of the software: These are:
Program, Documentation, and Operating Procedures.
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.

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 are the 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.
The framework activities are listed below.
1. Communication

25
2. Planning
3. Modeling
3.1. Analysis of requirements
3.2. Design
4. Construction
4.1. Code generation
4.2. Testing
5. Deployment
5.1. Delivery
5.2. Feedback

Software Process Framework is dealing with ideas of the

software development process. It 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:

Tasks – focus on a small, specific objective.

Action – set of tasks that produce a major work
product.
 Activities – group of related tasks and actions for a
major objective.
The process framework is required for representing
software process activities. Five framework activities are
described in a process framework for software engineering
for creating the software products. Communication,

26
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 will be done. Communication with
consumers or the clients, who are the stakeholders to
determine the system’s objectives and the software’s
requirements.
 Planning: Establish engineering work plan sketch,
describe technical risk, lists resources requirements, work
produced and defines work schedule.
 Modeling: Architectural models and design
specifications to better understand the problem and for
work towards the best solution. The software model is
prepared by Analysis of Requirements and Design stages.
• Construction: Creating code, testing the system,
rectifying bugs, and confirming that all criteria are met. The
software design is mapped into a code by: Code generation
and module testing procedures.
• Deployment: In this activity, the launching of a
complete or non‐complete product or software is
presented to the customers to evaluate and give feedback.
On the basis of their feedback, we modify the product for
better improvements.

27
 Fig:2 Software Process Framework

• These five framework activities will be used for all

software development of any application domain
irrespective of size and the complexity of the efforts etc.
• Though the details will be different in each case.
• For many software development projects, these
framework activities are applied repetitively as the project
progresses. Every iteration produces a software increment.
This provides a subset of overall software features and
functionality for the improvement of the software product.

28
UMBRELLA ACTIVITIES:
• Umbrella Activities are used to complete the
software project framework activities. It help the team to
manage and control progress, quality, change, and risk for
the software development project. These steps of umbrella
activities will evolve through the phases of the generic view
of software development.

• The activities in the software development process

are supplemented by many general activities. Common
activities apply to the entire software project and help the
software development team manage and track progress,
quality, changes, and risks. The process involved with the
following steps as shown in the figure.

Fig:3 Umbrella Activities for software framework

Software project tracking and control: This activity allows

the development team to check the progress of software
development. Before the project starts, make a software
development plan and develop on this basis, but after a
certain period of time, it is necessary to analyze the

29
development progress to find out what measures need to
be taken.
Risk management: Risk management helps software
development teams understand and manage uncertainty.
This step is essential in identifying the risks related to the
software development project.
Software quality assurance: This defines and conducts the
activities required to ensure software quality. The quality of
the software, such as user experience, performance,
workload flexibility, etc., must be tested and verified.
Technical reviews: It assesses software engineering work
products in an effort to uncover and remove errors before
they are propagated to the next activity.
Measurement: This includes all measurements of all
aspects of the software project. Define and compile
process, project, and product metrics to help the team
deliver software that meets the needs of stakeholders.
Software configuration management: It manages the
impact of changes throughout the software development
process. Software Configuration Management (SCM) is a
set of activities designed to manage changes by identifying
work products.
Reusability management: It defines the standards for the
reuse of work products (including software components),
and develop mechanisms to implement reusable
components.

Work product preparation and production: create work

products such as models, documents, logs, forms and lists.
In this activity, the process can be defined and collected.

30
SOFTWARE ENGINEERING PRACTICE:
Practice is a broad array of concepts, principles, methods,
and tools that you must consider as software is planned and
developed.
 communication,
 planning,
 modeling,
 construction
 deployment.
The essence of problem solving is outlined in 4 points:
1. Understand the problem (communication and
analysis).
2. Plan a solution (modeling and software design).
3. Carry out the plan (code generation).
4. Examine the result for accuracy (testing and quality
assurance).

SOFTWARE MYTHS
Myths are known as false belief. In this section the common
myths in the software industries are explained. It commonly
includes from the management and till the customers.

MANAGEMENT MYTHS
Myth1:
 “We already have a book of standards and
procedures for building software. It does provide my people

31
with everything they need to know …”

Fact: Software experts do not know all the requirements for

the software development. And all existing processes are
incomplete as new software development is based on new
and different problem.
Myth2:

 “If my project is behind the schedule, I always can

add more programmers to it and catch up …”

Fact: The role of the latest hardware is not very high on

standard software development; instead (CASE: Computer
Aided Software Engineering) Engineering tools help the
computer, they are more important than hardware to
produce quality and productivity. Hence, the hardware

resources are misused .

Myth 3:

 “If I decide to outsource the software project to a

third party, I can just relax: Let them build it, and I will just
pocket my profits …”
Fact:

If software is late, adding more people will merely make the

problem worse. This is because the people already working
on the project now need to spend time educating the new
comers, and are thus taken away from their work. The
newcomers are also far less productive than the existing

32
software engineers, and so the work put into training them
to work on the software does not immediately meet with
an appropriate reduction in work.

CUSTOMER MYTHS
Myth1:
 “A general statement of objectives is sufficient to
begin writing programs ‐ we can fill in the details later …”
Fact:

Official and detailed description of the database function,

ethical performance, communication, structural issues and
the verification process are important. Unambiguous
requirements (usually derived iteratively) are developed
only through effective and continuous communication
between customer and developer.
Myth 2:
 “Project requirements continually change but this
change can easily be accommodated because software is
flexible …”
Fact:

It is true that software requirements change, but the impact

of change varies with the time at which it is introduced.
When requirements changes are requested early (before
design or code has been started), the cost impact is
relatively small. However, as time passes, the cost impact
grows rapidly—resources have been committed, a design

33
framework has been established, and change can require
additional resources and major design modification.

PRACTITIONERS MYTHS
Myth 1:
 “Let’s start coding ASAP, because once we
write the program and get it to work, our job is done …”
Fact:

It is true that every 60‐80% effort goes into the

maintenance phase (as of the latter software release).
Efforts are required, where the product is available first
delivered to customers.
Myth 2:
 “Until I get the program running, I have no
way of assessing its quality …”

Fact:

Systematic review of project technology is the quality of

effective software verification method. These updates are
quality filters and more accessible than test.
Myth 3:
 “The only deliverable work product for a
successful project is the working program …”
Fact:

34
A working system is not enough, the right document
brochures and booklets are also required to provide
guidance & software support.

Myth 4:
 “Software engineering is
baloney(nonsense.). It makes us create tons of paperwork,
only to slow us down …”
Fact:

Software engineering is not about creating documents. It is

about creating a quality product. Better quality leads to
reduced rework. And reduced rework results in faster
delivery times

35
CHAPTER 1.3. PROCESS MODELS: GENERIC
PROCESS MODEL, PRESCRIPTIVE PROCESS
MODELS

INTRODUCTION

“Process Models: Generic process model, prescriptive

process models”

The objectives of this session are to introduce various

software Process models with examples also a brief
introduction to software process. When students have read
this session’s content, Student will

 Understand what are the software Process

 Understand the various software Process models.

 Understand the steps to develop software.

DESCRIPTION
INTRODUCTION:
PROCESS MODELS
Prescriptive process models define a set of activities, actions,
tasks, milestones, and work products that are required to
engineer high‐quality software. These process models are not
perfect, but they do provide a useful roadmap for software
engineering work.

36
A GENERIC PROCESS MODEL

The software development process is schematically illustrated.

Software engineering actions make up the framework activity. A
task set that outlines the work tasks to be carried out, the work
products to be generated, the quality assurance points that will
be necessary, and the milestones that will be used to track
progress defines each software engineering action. Five
framework activities are outlined in the generic process
framework for software engineering: communication, planning,
modelling, construction, and deployment. A number of umbrella
activities are also used throughout the process, including
technical reviews, risk management, quality assurance,
configuration management, and project tracking and control.
Process flow— In Figure 2.2, the sequence and timing of the
framework activities, as well as the actions and tasks that take
place within each framework activity, are described.

37
Each of the five framework activities is carried out in a linear
process flow, starting with communication and ending with

deployment (Figure 2.2a). Before moving on to the next activity,

an iterative process flow repeats one or more of the previous
ones (Figure 2.2b). A "circular" evolutionary process flow carries
out the tasks. A more full version of the software results from
each circuit through the five activities (Figure 2.2c). One or more
operations are carried out concurrently with other activities in a
parallel process flow (Figure 2.2d).

38
Defining a Framework Activity: Before correctly carrying out
any one of these five software process tasks (Communication,
Planning, Modelling, Construction, Deployment), a software
team would require substantially more information. A phone
contact with the right stakeholder may be all that is required for
a small software project that is requested by a single person (at
a distance) and has simple, uncomplicated needs. The single
action that is required is a phone conversation, and the work

39
activities (the job set) that are covered by this action are as
follows:
1. Phone the stakeholder to introduce yourself.
2. Talk about the demands and make notes.
3. Compile your notes into a succinct, written list of needs.
4. Email the concerned party for review and approval.

The communication activity might involve six different steps,

including inception, elicitation, elaboration, negotiation,
specification, and validation, if the project was significantly more
complicated and involved a large number of stakeholders, each
with their own unique set of requirements. Each of these
software engineering activities would involve a large number of
tasks and different work outcomes.
Identifying a Task Set:
Each task set, which is made up of several software engineering
work tasks, related work products, quality assurance points, and
project milestones, can be used to represent a particular
software engineering action. The task set you select should be
one that both meets the requirements of the project and the
demands of your team.
Process Patterns
A process pattern explains a process‐related issue that
arises while working on software engineering projects,
specifies the setting in which the issue has occurred, and
offers one or more tested solutions. A process pattern gives
you a template, to put it more broadly. A template for
describing a process pattern has been proposed by Ambler:

40
Type of pattern. The pattern is given a name that accurately
describes it in relation to the software process.
Type. The type of the pattern is mentioned. There are three
categories:
1. Stage pattern—defines an issue with a process‐related
framework activity.
2. Task pattern—defines a difficulty connected to an action
or work task in software engineering and pertinent to
successful software engineering practise.
3. Phase pattern: Describe the order of framework activities
that take place throughout the process, even if the overall
activity flow is iterative.
Initial context. Describes the conditions under which the
pattern applies.
Problem. The specific problem to be solved by the pattern.
Solution. Describes how to implement the pattern
successfully.
Resulting Context. Describes the conditions that will result
once the pattern has beensuccessfully implemented. Upon
completion of the pattern.
Related Patterns. Provide a list of all process patterns that
are directly related to thisone.
Known Uses and Examples. Indicate the specific
instances in which the pattern isapplicable.

PROCESS ASSESSMENT AND IMPROVEMENT

Several different approaches to software process
assessment and improvement have been proposed.

41
Standard CMMI Assessment Method for Process
Improvement (SCAMPI)— provides a five‐phase process
assessment paradigm with the following steps: establishing,
starting, diagnosing, acting, and learning. The SEI CMMI
serves as the evaluation framework for the SCAMPI
process.
CMM‐Based Appraisal for Internal Process Improvement
(CBA IPI)— provides a diagnostic technique for assessing
the relative maturity of a software organization; uses the
SEI CMM as the basis for the assessment.
SPICE (ISO/IEC15504)— A specification that spells out a list
of needs for software process evaluation. The standard's
goal is to help organisations create an unbiased assessment
of the effectiveness of any specified software process.
ISO 9001:2000 for Software— A general standard that may
be used by any company that wishes to raise the overall
quality of the systems, products, or services it offers. The
standard therefore immediately applies to software
organisations and businesses.

PRESCRIPTIVE PROCESS MODELS

A predetermined set of process elements and a
predetermined process work flow are defined by
prescriptive process models. The primary idea of
prescriptive process models was to organise the disarray of
software development.
The basic framework activities can be accommodated by all
software process models, but each places a distinct

42
emphasis on them and specifies a process flow that calls
each framework activity in a unique way.
The Waterfall Model: There are occasions when a
problem's needs are clearly defined—when work proceeds
in a somewhat linear method from communication to
deployment. The waterfall model, also known as the classic
life cycle, proposes a structured, sequential approach6 to
software development that starts with customer‐specified
requirements and progresses through planning, modelling,
construction, and deployment, concluding with ongoing
support of the finished software (Figure 2.3).

The waterfall model is the oldest paradigm, the problems

that are sometimes encountered when the waterfall model
is applied are:
1. Real projects rarely follow the sequential flow
that the model proposes. Although the linear model can
accommodate iteration, it does so indirectly. As a result,
changes can cause confusion as the project team proceeds.
2. It is often difficult for the customer to state all
requirements explicitly. The waterfall model requires this
and has difficulty accommodating the natural uncertainty
that exists at the beginning of many projects.
3. The customer must have patience. A working

43
version of the program(s) will not be available until late in
the project time span. A major blunder, if undetected until
the working program is reviewed, can be disastrous.
V Model

The V‐model is a variant of the waterfall model's visual

representation. The V‐model, which is shown in Figure 2.4,
shows how quality assurance actions relate to those related
to modelling, early construction, and communication. Basic
problem specifications are refined into progressively more
intricate and technical representations of the problem and
its solution as a software team works down the left side of
the V. As soon as code has been produced, the team
continues up the right side of the V, effectively conducting
a series of tests (quality assurance procedures) to confirm
each of the models that were developed as they proceeded
down the left side.7 The traditional life cycle and the V‐
model are not fundamentally different from one another, in
actuality. The V‐model provides a way of visualizing how
verification and validation actions are applied to earlier
engineering work.

44
Incremental Process Models: The incremental approach
offers a succession of releases, referred to as increments,
that offer the customer progressively greater functionality
with each iteration that is supplied.
Although the initial software requirements are frequently
very well specified, the full scope of the development effort
frequently prevents a strictly linear process. Additionally,
there can be a strong case for delivering a constrained set
of software capability to users right once, followed by its
improvement and expansion in subsequent software
releases. In these circumstances, you can pick a process
model that is intended to create the programme in stages.

45
The incremental model incorporates aspects of parallel an
d linear process flows.
As calendar time passes, the incremental model applies lin
ear sequences in a staggered manner (see Figure 2.5).Each
linear sequence creates deliverable "increments" of the pr
ogramme in a way that is comparable to how an evolution
ary process flow creates increments.
The initial increment in an incremental approach is
frequently a key product. In other words, the fundamental
needs are met, but many supplemental elements are still
lacking. The customer uses the primary product. A strategy
is created for the following increment as a result of use
and/or evaluation. The strategy covers both the supply of
new features and functionality as well as the change of the
core product to better suit consumer expectations.
Following the delivery of each increment, this process is

46
continued until the entire product is completed. The
delivery of a functioning product with each increment is the
main goal of the incremental process model. Early
iterations are trimmed‐down copies of the finished
product, but they do include functionality that benefits the
consumer and a testing ground. When manpower is lacking
for a full implementation by the project's set business
deadline, incremental development is very helpful.
Evolutionary Process Models: With each iteration,
evolutionary process models create a software version that
is ever more comprehensive. Like all complicated systems,
software develops over time. A straight road to an end
product is impracticable due to the fact that business and
product needs frequently change during development.
Tight market deadlines also prevent the creation of a
comprehensive software product, thus a limited version
must be released to meet commercial or competitive
pressure. Iterative models of evolution are used. They are
described in a way that makes it possible to create ever‐
more‐complete iterations of the software. Here, the two
popular models of the evolutionary process are presented.

Prototyping: Customers frequently specify a list of broad

goals for software but do not specify specific needs for
functions and capabilities. In other situations, the
developer can be sceptical of an algorithm's effectiveness,
the adaptability of an operating system, or the best way to
interface with machines. A prototyping paradigm may be
the appropriate course of action in these and many other

47
circumstances.
The prototyping paradigm helps you and other stakeholders
comprehend what has to be built when requirements are
hazy, regardless of how it is used.
The communication phase of the prototype paradigm is
depicted in Figure 2.6. You get together with other
stakeholders to discuss the broad goals for the product,
identify any existing requirements, and identify any areas
that require more clarification. Iterative prototyping is
designed fast, and modelling takes place. A fast design
concentrates on a visual depiction of the software's
features that end users will see.

An immediate design results in the creation of a prototype.

Stakeholders test the prototype and give their feedback,
which is then used to improve the requirements. Iteration
happens as the prototype is adjusted to meet the needs of
different stakeholders, giving you the chance to better
understand what needs to be done.

48
 The following factors make prototyping problematic:
1. Stakeholders view what seems to be a functional
version of the product without being aware that there is still
work to be done.
2. You frequently sacrifice on implementation as a
software developer in order to quickly get a prototype
operating.
The Spiral Model. The spiral model, which was first put forth by
Barry Boehm, is an evolutionary software process model that
combines the regulated and methodical elements of the
waterfall model with the iterative nature of prototyping. The
model is described in the following way by Boehm:

49
The spiral development model is a tool for multi‐
stakeholder concurrent engineering of software‐intensive
systems. It is a risk‐driven process model generator. It is
distinguished by two key characteristics. One strategy is a
cyclical one that gradually increases a system's level of
definition and implementation while lowering its level of

risk. The other is a group of milestones known as anchor

points that are used to ensure stakeholder commitment to
workable and mutually beneficial system solutions.
Software is created through a succession of evolutionary
releases using the spiral approach. The release could be a
model or prototype in the early stages. Later cycles result in
increasingly finished versions of the engineered system.
The software engineering team defines a collection of
framework activities that make up a spiral model. The spiral
path shown in Figure 2.7 is represented by each of the
framework activities as a separate section.

The software team engages in activities that are suggested

by a circuit around the spiral in a clockwise fashion, starting

50
at the centre, as this evolutionary process gets underway.
With each revolution, risk is taken into consideration. For
each evolutionary run, anchor point milestones—a
collection of work outputs and circumstances attained
along the spiral's path—are logged.
A product specification may be created during the first
circuit around the spiral. Subsequent circuits around the
spiral may be used to create a prototype and then
increasingly more complex iterations of the programme.
The project plan is modified after every visit to the planning
zone. Based on the comments received from the customer
after delivery, the cost and schedule are modified. The
project manager also modifies the anticipated number of
software iterations needed to finish the project.
The spiral model can be modified to apply throughout the
life of the computer programme, in contrast to other
process models that stop after software is delivered. A
practical method for creating complex systems and
software is the spiral model. As the process moves forward,
software changes, which helps the developer and client
better comprehend and respond to risks at each
evolutionary phase.

51
Concurrent Models: A software team can express iterative
and concurrent parts of any of the process models using the
concurrent development model, often known as
concurrent engineering. Using a concurrent modelling
technique, Figure 2.8 shows a schematic representation of

one software engineering activity within the modelling

activity. Modelling can happen in any of the states

52
mentioned at any given time.Other activities, operations, or
tasks (such as communication or construction) can also be
analogously described. Although they are all ongoing, the
various software engineering initiatives are in different
states.
Each of the software engineering activities, operations, or
tasks will transition from one state to another as a result of
a series of events that are defined by concurrent modelling.
For instance, a flaw in the requirements model may be
discovered in the early stages of design. As a result, the
event analysis model correction is generated, which causes
the requirements analysis action to move from the finished
state into the pending modifications stage. Concurrent
modelling gives a precise representation of a project's
current state and is relevant to all styles of software
development.

53
CHAPTER 1.4. SPECIALIZED PROCESS
MODELS, UNIFIED PROCESS

INTRODUCTION
“Specialized Process Models, Unified Process”
The objectives of this session are to introduce software and
to provide Specialized process model. When student have
read this session content, Student will
 Specialized Process Model
 Component Based Development
 Formal Methods Model
 Aspect Oriented Software development

DESCRIPTION
SPECIALIZED PROCESS MODELS
These models tend to be applied when a specialized or
narrowly defined software engineering approach is chosen.
Component‐Based Development: Commercial off‐the‐
shelf (COTS) software components are created by vendors
and sold as products. They offer specialised functionality
with clearly defined interfaces that make it possible to
incorporate the component into the software being
developed. Many of the traits of the spiral model are
included in the component‐based development model. Its
evolving nature necessitates an iterative approach to
software development. Component‐based development,
on the other hand, builds applications from prepackaged

54
software components.
The selection of potential components serves as the first
step in modelling and construction activities. Both
traditional software modules and object‐oriented classes or
collections of classes can be used to construct these
components. The component‐based development
paradigm contains the following processes, regardless of
the technology used to construct the components.
1. For the application domain in issue, research is
conducted, and component‐based products are assessed.
2. Issues with component integration are considered.
3.The components are accommodated by software
architecture.
4. The architecture incorporates the components.
5. Extensive testing is carried out to guarantee optimal
functionality.
The component‐based development model leads to
software reuse, and reusability provides software engineers
with a few measurable benefits.

The Formal Methods Model: A series of actions that result

in the formal mathematical specification of computer
software are included in the formal methods model. By
using a strict, mathematical notation, formal techniques
allow you to describe, construct, and validate a computer‐
based system. Some software development companies
today use a variation of this strategy termed cleanroom
software engineering.

55
 The use of formal methods during design lays the
groundwork for programme verification, allowing you to
find and fix mistakes that could otherwise go unnoticed.
The formal methods paradigm promises software
without errors despite not being a common strategy.
However, there have been some reservations raised about
its viability in a business setting:
• The development of formal models is currently quite
time consuming and expensive;
• Because few software developers have the
background to apply formal methods, extensive training is
required;
• It is challenging to use the models as a communication
mechanism for technically unsophisticated customers.
Aspect‐Oriented Software Development: The developers
of complicated software always include a number of
localised features, functions, and information content,
regardless of the software method they select. These
regionally specific software traits are modelled as parts (like
object‐oriented classes), which are then assembled in the
framework of a system architecture.
Other issues influence functions (such as the execution of
business rules) while others are systemic (such as task
synchronisation or memory management) as contemporary
computer‐based systems become more sophisticated (and
complicated).

56
Crosscutting concerns are problems that affect several
features, functions, or pieces of data in a system. Aspectual
requirements outline the common issues that affect the
entire software architecture. A relatively new software
engineering paradigm known as aspect‐oriented software
development (AOSD), sometimes known as aspect‐oriented
programming (AOP), offers a methodology and
methodological approach for defining, describing,
designing, and constructing aspects.

To describe the cross‐cutting functional and non‐functional

qualities of components, AOCE employs the idea of
"aspects," which are horizontal slices through vertically‐
decomposed software components. User interfaces, group
collaboration, distribution, persistency, memory
management, transaction processing, security, integrity,
and other common systemic characteristics are only a few
examples.

THE UNIFIED PROCESS

Introduction: The Unified Process is an effort to include
many of the most beneficial ideas of agile software
development while retaining the best features and traits of
conventional software process models. The Unified Process
appreciates the value of customer interaction and
streamlines approaches of describing the customer's
perspective of a system. It highlights the significance of
software architecture and explains how it "assists the
architect in focusing on the right goals, such as
understandability, reliance on future changes, and reuse."

57
Phases of the Unified Process: The Unified Process is with
five basic framework activities depicted in figure 2.9. It
depicts the “phases” of the UP and relates them to the
generic activities.

The inception phase of the UP encompasses both customer

communication and planning activities. The elaboration
phase encompasses the communication and modeling
activities of the generic process model. The construction
phase of the UP is identical to the construction activity
defined for the generic software process. The transition
phase of the UP encompasses the latter stages of the
generic construction activity and the first part of the generic
deployment (delivery and feedback) activity. Software is

58
given to end users for beta testing and user feedback
reports both defects and necessary changes. In addition,
the software team creates the necessary support
information (e.g., user manuals, troubleshooting guides,
installation procedures) that is required for the release. The
production phase of the UP coincides with the deployment
activity of the generic process. During this phase, the
ongoing use of the software is monitored, support for the
operating environment (infrastructure) is provided, and
defect reports and requests for changes are submitted and
evaluated. A software engineering workflow is distributed
across all UP phases.

59
CHAPTER 1.5. PERSONAL AND TEAM
PROCESS MODELS COURSE DESCRIPTION

INTRODUCTION

“personal and team process models, product and process”

The objectives of this session are to introduce software and
to provide Personal Software Process Characteristics.
When student have read this session content, Student will
 Understand what Process Model software is and
why it is important;
 Understand Nature of process model.

DESCRIPTION
The best software process is personal and team process
model one that is close to the people who will be doing the
work. Watts Humphrey proposed two process models.
Models “Personal Software Process (PSP)” and “ Team
Software Process (TSP).” Both require hard work, training,
and coordination, but both are achievable.

Personal Software Process (PSP)

The SEI CMM which is reference model for raising the
maturity levels of software and predicts the most expected
outcome from the next project undertaken by the
organizations does not tell software developers about how
to analyze, design, code, test and document the software
products, but expects that the developers use effectual
practices. The Personal Software Process realized that the

60
process of individual use is completely different from that
required by the team.
Personal Software Process (PSP) is the skeleton or the
structure that assist the engineers in finding a way to
measure and improve the way of working to a great extend.
It helps them in developing their respective skills at a
personal level and the way of doing planning, estimations
against the plans.
Objectives of PSP :
The aim of PSP is to give software engineers with the
regulated methods for the betterment of personal software
development processes.
The PSP helps software engineers to:
 Improve their approximating and planning skills.
 Make promises that can be fulfilled.
 Manage the standards of their projects.
 Reduce the number of faults and imperfections in
their work.
Time measurement:
Personal Software Process recommend that the developers
should structure the way to spend the time. The developer
must measure and count the time they spend on different
activities during the development.
PSP Planning :
The engineers should plan the project before developing
because without planning a high effort may be wasted on
unimportant activities which may lead to a poor and
unsatisfactory quality of the result.

61
Levels of Personal Software Process :
Personal Software Process (PSP) has four levels‐
1. PSP 0 – The first level of Personal Software Process,
PSP 0 includes Personal measurement , basic size
measures, coding standards.
2. PSP 1 – This level includes the planning of time and
scheduling .
3. PSP 2 – This level introduces the personal quality
management ,design and code reviews.
4. PSP 3 – The last level of the Personal Software
Process is for the Personal process evolution.

Difference Between PSP and TSP

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

62
In this article, we will see a difference between PSP and
TSP.
PSP:
The personal software process is focused on individuals to
improve their performance. The PSP is an individual
process, and it is a bottom‐up approach to software process
improvement. The PSP is a prescriptive process, it is a more
mature methodology with a well‐defined set of tools and
techniques.

63
Key Features of PSP :
 Process‐focused: PSP is a process‐focused
methodology that emphasizes the importance of following
a disciplined approach to software development.
 Personalized: PSP is personalized to an individual’s
skill level, experience, and work habits. It recognizes that
individuals have different strengths and weaknesses, and
tailors the process to meet their specific needs.
 Metrics‐driven: PSP is metrics‐driven, meaning that
it emphasizes the collection and analysis of data to measure
progress and identify areas for improvement.
 Incremental: PSP is incremental, meaning that it
breaks down the development process into smaller, more
manageable pieces that can be completed in a step‐by‐step
fashion.
 Quality‐focused: PSP is quality‐focused, meaning
that it emphasizes the importance of producing high‐quality
software that meets user requirements and is free of
defects.

Advantages :
 Improved productivity: PSP provides a structured
approach to software development that can help
individuals improve their productivity by breaking down the
development process into smaller, more manageable
steps.
 Improved quality: PSP emphasizes the importance
of producing high‐quality software that meets user
requirements and is free of defects. By collecting and
analyzing data throughout the development process,

64
individuals can identify and eliminate sources of errors and
improve the quality of their work.
 Personalized approach: PSP is tailored to an
individual’s skill level, experience, and work habits, which
can help individuals work more efficiently and effectively.
 Improved estimation: PSP emphasizes the
importance of accurate estimation, which can help
individuals plan and execute projects more effectively.
 Continuous improvement: PSP promotes a culture
of continuous improvement, which can help individuals
learn from past experiences and apply that knowledge to
future projects.

Disadvantages :
 Time‐consuming: PSP can be time‐consuming,
particularly when individuals are first learning the
methodology and need to collect and analyze data
throughout the development process.
 Complex: PSP can be complex, particularly for
individuals who are not familiar with software engineering
concepts or who have limited experience in software
development.
 Heavy documentation: PSP requires a significant
amount of documentation throughout the development
process, which can be burdensome for some individuals.
 Limited to individual use: PSP is designed for
individual use, which means that it may not be suitable for
team‐based software development projects.

TSP:
TSP is a team‐based process. It is focused on team
productivity. Basically, it is a top‐down approach. The TSP is

65
an adaptive process, and process management
methodology.
Key Features of TSP :
 Team‐focused: TSP is team‐focused, meaning that it
emphasizes the importance of collaboration and
communication among team members throughout the
software development process.
 Process‐driven: TSP is process‐driven, meaning that
it provides a structured approach to software development
that emphasizes the importance of following a disciplined
process.
 Metrics‐driven: TSP is metrics‐driven, meaning that
it emphasizes the collection and analysis of data to measure
progress, identify areas for improvement, and make data‐
driven decisions.
 Incremental: TSP is incremental, meaning that it
breaks down the development process into smaller, more
manageable pieces that can be completed in a step‐by‐step
fashion.
 Quality‐focused: TSP is quality‐focused, meaning
that it emphasizes the importance of producing high‐quality
software that meets user requirements and is free of
defects.
 Feedback‐oriented: TSP is feedback‐oriented,
meaning that it emphasizes the importance of receiving
feedback from peers, mentors, and other stakeholders to
identify areas for improvement.

Advantages of TSP :
 Improved productivity: TSP provides a structured
approach to software development that can help teams
improve their productivity by breaking down the

66
development process into smaller, more manageable
steps.
 Improved quality: TSP emphasizes the importance
of producing high‐quality software that meets user
requirements and is free of defects. By collecting and
analyzing data throughout the development process, teams
can identify and eliminate sources of errors and improve
the quality of their work.
 Team collaboration: TSP promotes team
collaboration, which can help teams work more efficiently
and effectively by leveraging the skills and expertise of all
team members.
 Improved estimation: TSP emphasizes the
importance of accurate estimation, which can help teams
plan and execute projects more effectively.
 Continuous improvement: TSP promotes a culture
of continuous improvement, which can help teams learn
from past experiences and apply that knowledge to future
projects.
Disadvantages of TSP :
 Time‐consuming: TSP can be time‐consuming,
particularly when teams are first learning the methodology
and need to collect and analyze data throughout the
development process.
 Complex: TSP can be complex, particularly for
teams that are not familiar with software engineering
concepts or who have limited experience in software
development.
 Heavy documentation: TSP requires a significant
amount of documentation throughout the development
process, which can be burdensome for some teams.
 Requires discipline: TSP requires teams to follow a
disciplined approach to software development, which can

67
be challenging for some teams who prefer a more flexible
approach.
 Cost: TSP can be costly to implement, particularly if
teams need to invest in training or software tools to support
the methodology.
PSP TSP
PSP is a project TSP is a project
management process that management process that
defines how to manage a defines how to manage a
project in a face‐to‐face project in a virtual
environment. environment.
PSP is more formal and TSP is less formal and
structured than TSP. structured than PSP.
PSP is based on the TSP is based on the agile
waterfall model. model.
PSP is more suited for TSP is more suited for small
large projects. projects.
PSP projects are
TSP projects are typically
typically completed in one
completed in multiple phases.
phase.
PSP is a high‐level TSP is a low‐level language
language and it is easy to and it is difficult to learn and
learn and use. use.
PSP is a structured TSP is an unstructured
language and it is easy to language and it is difficult to
read and write. read and write.

68
 PSP programs are TSP programs are written in
written in English and they assembly language and they
are easy to understand. are difficult to understand.
TSP is a platform‐
PSP is a portable
dependent language and it can
language and it can be run
be run only on specific
on any platform.
platforms.
PSP is an interpreted TSP is a compiled language
language and it does not and it needs to be compiled
need to be compiled. before it can be run.
PSP is a free language TSP is a commercial
and it can be downloaded language and it is not available
from the internet. for free.
PSP is an open‐source TSP is a closed‐source
language and it is available language and it is not available
to everyone. to everyone.
TSP, on the other hand, is
PSP is a linear process an iterative and incremental
model that is completed in process model that allows for
a sequential manner. feedback and changes at each
stage of the process.

Personal and Team Process Model in Software

Engineering
The best software process is personal and team process
model one that is close to the people who will be doing the
work. Watts Humphrey proposed two process models.

69
Models “Personal Software Process (PSP)” and “Team
Software Process (TSP).” Both require hard work, training,
and coordination, but both are achievable.
Personal Software Process (PSP)
The Personal Software Process (PSP) emphasizes
personal measurement of both the work product that is
produced and the resultant quality of the work product.
In addition PSP makes the practitioner responsible for
project planning and empowers the practitioner to control
the quality of all software work products that are
developed. The PSP model defines five framework
activities:
 Planning. This activity isolates requirements and
develops both size and resource estimates. In addition,
defects estimate (the number of defects projected for the
work) is made. All metrics are recorded on worksheets or
templates. Finally, development tasks are identified and a
project schedule is created.
 High level design. External specifications for each
component to be constructed are developed and a
component design is created. Prototypes are built when
uncertainty exists. All issues are recorded and tracked.
 High level design review. Formal verification
methods are applied to uncover errors in the design.
Metrics are maintained for all important tasks and work
results.
 Development. The component level design is
refined and reviewed. Code is generated, reviewed,
compiled, and tested. Metrics are maintained for all
important tasks and work results.

70
 Postmortem. Using the measures and metrics
collected, the effectiveness of the process is determined.
Measures and metrics should provide guidance for
modifying the process to improve its effectiveness.
PSP stresses the need to identify errors early and, just as
important, to understand the types of errors that you are
likely to make. PSP represents a disciplined, metrics based
approach to software engineering that may lead to culture
shock for many practitioners.
Team Software Process (TSP)
Watts Humphrey extended the lessons learned from the
introduction of PSP and proposed a Team Software Process
(TSP). The goal of TSP is to build a “self directed” project
team that organizes itself to produce high quality software.
Humphrey defines the following objectives for TSP:
 Build self directed teams that plan and track their
work, establish goals, and own their processes and plans.
These can be pure software teams or integrated product
teams (IPTs) of 3 to about 20 engineers.
 Show managers how to coach and motivate their
teams and how to help them sustain peak performance
 Accelerate software process improvement by
making CMM23 Level 5 behavior normal and expected.
 Provide improvement guidance to high‐maturity
organizations.
 Facilitate university teaching of industrial‐grade
team skills.

A self directed team has a consistent understanding of its

overall goals and objectives; defines roles and

71
responsibilities for each team member; tracks quantitative
project data (about productivity and quality); identifies a
team process that is appropriate for the project and a
strategy for implementing the process; defines local
standards that are applicable to the team’s software
engineering work; continually assesses risk and reacts to it;
and tracks, manages, and reports project status.
TSP defines the following framework activities: project
launch, high level design, implementation, personal and
team process model, integration and test, and
postmortem.
TSP makes use of a wide variety of scripts, forms, and
standards that serve to guide team members in their work.
“Scripts” define specific process activities (project launch,
design, implementation, integration and system testing,
postmortem) and other more detailed work functions
(development planning, requirements development,
software configuration management, unit test) that are
part of the team process.

72
CHAPTER 1.6. REVERSE ENGINEERING

INTRODUCTION
“MOS inverter Design with various pull up Resistive &
Depletion Load”

The session starts with the introduction of the Inverter, as

the nucleus of all digital designs. Once its operation and
properties are clearly understood, designing MOS Inverter
with various pull up Resistive & Depletion Load is greatly
simplified. The electrical behavior of these complex circuits
can be almost completely derived by extrapolating the
results obtained for inverters.
DESCRIPTION

Introduction to Reverse Engineering:

To understand and dissect current technologies, such as

software, firmware, and hardware systems, reverse
engineering is a flexible and potent approach. It entails a
methodical examination of a system or product in order to
comprehend its architecture, functionality, design, and
underlying concepts. Reverse engineering concentrates on
dissecting the intricate workings of an existing entity, as
opposed to traditional engineering, which entails creating
something from nothing.

73
Reverse engineering's main goal is to understand how a
certain technology operates, frequently without having
access to the technology's original source code,
documentation, or design specifications. It is used in many
different industries, including as software development,
cybersecurity, electronics, manufacturing, and more.
Practitioners of reverse engineering can improve current
goods, integrate systems, and handle security issues by
understanding the inner workings of a technology.

Depending on the kind of technology being examined,

reverse engineering might cover a variety of
methodologies. Binary code is analysed in the field of
software reverse engineering to identify the methods and
data structures used by the produced application. On the
other hand, hardware reverse engineering entails analysing
electronic circuits and integrated circuits to determine their
operation and design.

The applications of reverse engineering are diverse and

essential:

1. Legacy System Maintenance: Organisations can

support and prolong the life of legacy systems by using
reverse engineering when the original documentation or
development team is unavailable.
2. Security analysis: Reverse engineering in
cybersecurity helps with vulnerability analysis, virus
identification, and intrusion detection, enhancing system
security as a whole.

74
 3. Interoperability and Integration: Systems can be
made compatible with one another to enable seamless data
interchange by reverse engineering network protocols and
data formats.
4. Competitive Analysis: Companies employ reverse
engineering to learn about the products and technologies
of rival companies, enabling them to make strategic
decisions.

Reverse engineering's ethical and legal implications must be

discussed, nevertheless. Even though reverse engineering
has many useful applications, it can raise issues with privacy
and intellectual property. Practitioners are required to
abide by all applicable laws, contractual obligations, and
industry standards to make sure their actions are legal and
ethical.

Reverse engineering is a potent tool that enables people

and organisations to comprehend, improve, and develop
current technologies. This procedure results in a deeper
comprehension of complicated systems and advances
several businesses and technology.

75
CHAPTER 2.1. REQUIREMENTS DEVELOPMENT
METHODOLOGY ‐ SPECIFYING REQUIREMENTS

INTRODUCTION
“Requirements Development Methodology –
Requirements Development Methodology is a systematic
approach used to gather, analyze, document, and manage
the requirements of a project or system. It is a critical phase
in the software development life cycle (SDLC) and other
project management processes, ensuring that the desired
functionality and objectives of the project are clearly
defined and understood by all stakeholders. An effective
requirements development methodology lays the
foundation for a successful project by reducing risks,
improving communication, and enhancing the overall
project outcomes.
The process of Requirements Development typically
includes the following key steps:
Elicitation: This initial phase involves identifying and
engaging with stakeholders to gather information about
their needs, expectations, and concerns. Various
techniques such as interviews, workshops, surveys, and
observations are used to elicit requirements. This step is
essential for understanding the project's purpose and
setting the stage for subsequent activities.
Analysis: Once the requirements are gathered, they need
to be analyzed to ensure they are complete, consistent, and

76
feasible. Conflicting requirements are resolved, and
dependencies between different requirements are
identified. The goal is to establish a clear and coherent set
of requirements that can serve as a solid basis for further
development.
Documentation: All the requirements collected and
analyzed during the elicitation and analysis phases are
documented in a clear and unambiguous manner. The
requirements document serves as a formal record and
reference for stakeholders, including developers, testers,
and project managers.
Validation: This step involves reviewing the documented
requirements with stakeholders to ensure accuracy and
completeness. Feedback is gathered, and any necessary
adjustments are made to the requirements. The validation
process ensures that the requirements truly reflect the
stakeholders' needs and expectations.
Verification: In the verification phase, the documented
requirements are reviewed by relevant stakeholders,
including developers, testers, and quality assurance
personnel, to ensure that they are technically feasible and
align with the project's goals and constraints.
Management and Traceability: Requirements are subject
to change during the project's life cycle, so a robust
requirements management process is essential. Changes
should be controlled, and the impact of changes on other
aspects of the project should be assessed. Additionally,

77
requirements traceability ensures that each requirement is
linked to its source and can be traced back to its origin.
Communication: Effective communication is crucial
throughout the Requirements Development process. Clear
communication between stakeholders, including end‐
users, business analysts, project managers, and developers,
ensures that everyone is on the same page and has a shared
understanding of the project's goals and requirements.

The choice of the specific Requirements Development

Methodology may vary depending on the nature of the
project, organizational preferences, and industry standards.
Some common methodologies include:
Waterfall: In the Waterfall model, requirements are
gathered and documented at the beginning of the project,
and subsequent phases progress in a linear, sequential
manner. Changes to requirements may be challenging to
accommodate once the project is underway.
Agile: Agile methodologies, such as Scrum and Kanban,
promote iterative and incremental development.
Requirements are gathered and refined throughout the
project, allowing for greater flexibility and responsiveness
to changing needs.
Spiral: The Spiral model combines elements of Waterfall
and iterative development. It involves cycles of planning,
risk assessment, engineering, and evaluation.

78
Requirements are gathered and refined at each cycle,
allowing for a more flexible approach.
V‐Model: The V‐Model emphasizes the relationship
between each development phase and its corresponding
testing phase. Requirements are gathered and verified early
in the process, ensuring a clear link between requirements
and testing activities.
SPECIFYING REQUIREMENTS:
Requirements engineering, often referred to as
requirements elicitation or requirements gathering, is the
process of identifying, documenting, analyzing, and
managing the needs and expectations of stakeholders for a
software system, product, or project. It is a critical phase in
the software development life cycle (SDLC) and other
project management processes, aiming to define the
functional and non‐functional requirements that the
system must meet to fulfill its intended purpose and
achieve the desired outcomes.
The primary objective of requirements engineering is to
establish a clear understanding of the project's goals, scope,
and constraints. It involves engaging with various
stakeholders, including end‐users, customers, business
owners, project managers, and technical experts, to gather
their input and perspectives on what the system should

79
accomplish.

REQUIREMENTS ENGINEERING ACTIVITIES: ‐

The process of requirements engineering typically includes
the following key activities:
Elicitation: Gathering information from stakeholders
through interviews, surveys, workshops, and other
techniques to identify their needs, expectations, and
preferences.
Analysis: Examining and refining the gathered
requirements to ensure they are complete, consistent,
feasible, and unambiguous. Conflicting requirements are
resolved, and dependencies between different
requirements are identified.
Documentation: Formally documenting the requirements
in a clear and unambiguous manner, creating a
Requirements Specification document or Business
Requirement Document (BRD).

80
Validation: Ensuring that the documented requirements
accurately represent the stakeholders' needs and align with
the project's objectives.
Verification: Reviewing the requirements with relevant
stakeholders and validating that they are technically
feasible and meet the desired outcomes.
Management and Traceability: Handling changes to
requirements, maintaining version control, and establishing
traceability between requirements and other project
artifacts.
Prioritization and Negotiation: Prioritizing requirements
based on their importance and negotiating with
stakeholders to manage conflicting needs.
Types of Requirements
Requirements in software development and project
management are classified into different types based on
their nature, scope, and characteristics. Each type of
requirement serves a specific purpose in defining what a
software system or project should accomplish.
Understanding these various types of requirements is
crucial for effective requirements engineering and
successful project outcomes. Let's explore the most
common types of requirements:
Functional Requirements: Functional requirements define
the specific behaviors, capabilities, and functionalities that
the software system or project must possess. They describe
what the system should do to fulfil the needs and

81
expectations of stakeholders. Functional requirements are
usually expressed as use cases or user stories, outlining the
interactions between users and the system. For example, in
a banking application, functional requirements may include
user authentication, account balance inquiries, fund
transfers, and transaction history retrieval.
Non‐Functional Requirements: Non‐functional
requirements focus on the qualities, characteristics, and
constraints of the software system or project, rather than
its specific functionalities. They address aspects such as
performance, reliability, security, usability, scalability,
maintainability, and compatibility. Non‐functional
requirements are essential for ensuring that the system
meets specific performance standards and user experience
expectations. Examples of non‐functional requirements
include response time limits, data encryption, error
handling, and user interface responsiveness.
User Requirements: User requirements represent the
needs, preferences, and expectations of end‐users who will
interact directly with the software system or project.
Understanding user requirements is vital for creating a
user‐centric design that aligns with user needs and goals.
User requirements often capture user stories, scenarios, or
personas, helping developers and designers empathize with
users and tailor the system accordingly.
Business Requirements: Business requirements focus on
the high‐level objectives and goals of the organization or

82
business for which the software system is being developed.
They outline the business problems that need to be
addressed and the potential benefits the system will
provide. Business requirements help align the software
development process with the overall business strategy.
Examples of business requirements include increasing
sales, improving customer service, reducing operational
costs, and enhancing market competitiveness.
System Requirements: System requirements specify the
technical attributes and capabilities that the software
system must possess to function effectively. They define
the hardware, software, and infrastructure needed for the
system's operation. System requirements also include
details on system integration, data storage, performance,
and interfaces with other systems or components.
Regulatory and Compliance Requirements: Regulatory and
compliance requirements refer to the legal, industry, and
government standards that the software system must
adhere to. Depending on the nature of the project,
compliance requirements may include data privacy
regulations, security standards, accessibility guidelines, and
industry‐specific certifications.
Quality Requirements: Quality requirements address the
desired level of quality and standards that the software
system must meet. They are concerned with aspects like
accuracy, reliability, robustness, maintainability, and
testability. Quality requirements ensure that the system is

83
developed to meet specific quality expectations and that it
can be tested effectively to validate those qualities.
Constraints: Constraints represent limitations or
restrictions imposed on the project or software system.
Constraints can be related to budget, time, resources,
technology, or organizational policies. Understanding
constraints helps manage project expectations and set
realistic objectives.
Performance Requirements: Performance requirements
focus on defining the system's performance characteristics,
such as response time, throughput, and resource
utilization. These requirements ensure that the system can
handle the expected workload and perform optimally under
different scenarios.
Security Requirements: Security requirements address the
measures and mechanisms needed to protect the software
system from unauthorized access, data breaches, and
cyber‐attacks. They include authentication, authorization,
encryption, and data privacy guidelines.
Usability Requirements: Usability requirements specify the
ease of use and user‐friendliness of the software system.
They cover aspects such as navigation, layout, user
interface design, and user assistance features to enhance
the overall user experience.
Scalability Requirements: Scalability requirements address
the system's ability to handle increased workloads and user
demands as the application grows. Scalability is essential for

84
ensuring that the system can accommodate future
expansion without compromising performance.
Maintainability Requirements: Maintainability
requirements focus on the ease of maintaining, modifying,
and updating the software system in the future. They
include aspects such as code readability, documentation,
and adherence to coding standards.
Interoperability Requirements: Interoperability
requirements specify the system's capability to interact and
exchange data with other external systems or software.
These requirements are crucial for seamless integration
with other business applications and technologies.
Environmental Requirements: Environmental
requirements address the conditions in which the software
system will operate. They may include temperature range,
humidity, and other environmental factors that can affect
the system's performance and reliability.
Legal and Ethical Requirements: Legal and ethical
requirements encompass compliance with laws,
regulations, and ethical standards related to the project or
software system. These requirements ensure that the
system operates within legal boundaries and adheres to
ethical principles.
Cultural and Social Requirements: Cultural and social
requirements consider the cultural norms, social context,
and user preferences of the target audience. Understanding

85
these requirements helps design a system that is culturally
sensitive and meets users' social expectations.
Data Requirements: Data requirements specify the data
needed for the system to function correctly. They include
data sources, formats, data flow, data storage, and data
access requirements.
Testing and Validation Requirements: Testing and
validation requirements define the testing procedures, test
cases, and acceptance criteria needed to verify that the
system meets the specified requirements. These
requirements ensure that the system is thoroughly tested
and validated before deployment.
Project Management Requirements: Project management
requirements address the project's organizational and
administrative aspects. They include project timelines,
milestones, communication protocols, risk management
procedures, and project documentation requirements.
Training and Support Requirements: Training and support
requirements outline the training needs of users and
support personnel. They ensure that users are adequately
trained to use the system effectively and that there is a
support mechanism in place for addressing user queries and
issues.
Cost and Budget Requirements: Cost and budget
requirements specify the financial constraints and budget
allocations for the project. These requirements help

86
manage project costs and ensure that the development
process remains within budgetary limits.
Time Constraints: Time constraints define the project's
timeline and deadlines for various milestones and
deliverables. Understanding time constraints is crucial for
planning and scheduling the development process
effectively.
Organizational Requirements: Organizational
requirements consider the policies, procedures, and
guidelines of the organization undertaking the project.
These requirements ensure that the software development
process aligns with the organization's standards and
practices.
Differences between Functional and Non‐Functional
Requirements

Non‐Functional
Functional Requirements
Requirements

A non‐functional
A functional requirement
requirement defines the
defines a system or its
quality attribute of a
component.
software system.

It specifies “What should It places constraints

the software system do?” on “How should the

87
 software system fulfil the
functional
requirements?”

Non‐functional
requirement is specified
Functional requirement is by technical peoples e.g.
specified by User. Architect, Technical
leaders and software
developers.

It is mandatory. It is not mandatory.

It is captured as a
It is captured in use case.
quality attribute.

Defined at a component Applied to a system

level. as a whole.

Helps you to verify

Helps you verify the
the performance of the
functionality of the software.
software.

Functional Testing like

Non‐Functional
System, Integration, End to
Testing like Performance,
End, API testing, etc are done.

88
 Stress, Usability, Security
testing, etc are done.

Usually more difficult

Usually easy to define.
to define.

Stages in Requirements Engineering

Elicitation: The first stage is requirements elicitation, where
the project team interacts with stakeholders to gather
information about their needs, expectations, and desired
functionalities. Techniques such as interviews, surveys,
workshops, and observations are used to extract valuable
insights from stakeholders. The goal is to understand the
project's purpose, scope, and constraints and to identify the
functional and non‐functional requirements.
Analysis and Documentation: In this stage, the gathered
requirements are thoroughly analyzed and refined to
ensure clarity, completeness, and consistency. Conflicting
requirements are resolved, and dependencies between
different requirements are identified. The requirements are
then documented in a clear and unambiguous manner
using various tools, templates, or documentation
standards. A well‐documented Requirements Specification
document (BRD) is created, serving as a formal record and
reference throughout the project.

89
Validation and Verification: The third stage involves
validating and verifying the documented requirements.
Validation ensures that the requirements accurately
represent stakeholder needs and expectations. It involves
reviewing the requirements with stakeholders to obtain
their feedback and ensure alignment with their vision.
Verification, on the other hand, focuses on confirming that
the specified requirements are technically feasible and
achievable within the given resources and constraints.
Management and Traceability: Managing requirements is
an ongoing process throughout the project life cycle. This
stage involves handling changes to requirements, tracking
their impact on the project, and maintaining version control
to ensure that the latest requirements are always available
to the project team. Requirements traceability is also
established, which allows the team to trace each
requirement back to its source and ensures that all
requirements are adequately addressed.
Negotiation and Prioritization: Stakeholders may have
different priorities and expectations for the project.
Negotiation and prioritization are crucial to manage
conflicting needs effectively. The project team collaborates
with stakeholders to understand their concerns and
preferences, making informed decisions on which
requirements to include and prioritize based on their
importance.

90
Validation and Verification: The fifth stage involves
validating and verifying the documented requirements.
Validation ensures that the requirements accurately
represent stakeholder needs and expectations. It involves
reviewing the requirements with stakeholders to obtain
their feedback and ensure alignment with their vision.
Verification, on the other hand, focuses on confirming that
the specified requirements are technically feasible and
achievable within the given resources and constraints.
Establish the Groundwork
Establishing the groundwork is a critical initial step in any
project or endeavor. It lays the foundation for the project's
success by defining its objectives, scope, and approach.
Whether it's a software development project, a business
initiative, or any other endeavour, establishing the
groundwork involves several key steps:
Define Project Objectives and Goals: Clearly articulate the
objectives and goals of the project. What do you aim to
achieve through this project? What problem are you trying
to solve, or what opportunity are you trying to seize?
Defining specific, measurable, achievable, relevant, and
time‐bound (SMART) goals provides a clear direction for the
entire team.
Identify Stakeholders: Identify all the stakeholders who
have an interest or involvement in the project. This includes
not only the project team but also end‐users, customers,
business owners, project sponsors, and other relevant

91
parties. Understand their needs, expectations, and
concerns to ensure that the project aligns with their
requirements.
Conduct a Feasibility Study: Before fully committing to the
project, conduct a feasibility study to assess its viability.
Evaluate technical, economic, legal, operational, and
scheduling aspects to determine if the project is feasible
within the given constraints. This study helps in making
informed decisions about whether to proceed with the
project.
Define Scope and Boundaries: Clearly define the scope of
the project by outlining what will be included and what will
be excluded. This helps manage expectations and prevents
scope creep. Identify project boundaries and constraints,
such as budget, time, and resources, to establish realistic
project limitations.
Formulate a Project Plan: Develop a detailed project plan
that outlines the step‐by‐step approach to achieving the
project objectives. The plan should include timelines,
milestones, deliverables, resource allocation, risk
assessment, and communication strategies. A well‐defined
project plan serves as a roadmap for the project's
execution.
Set Roles and Responsibilities: Define the roles and
responsibilities of each team member involved in the
project. Establish clear lines of communication and
decision‐making to ensure smooth collaboration among

92
team members. This clarity helps in avoiding confusion and
duplication of efforts.
Create a Risk Management Plan: Identify potential risks
and uncertainties that could impact the project's success.
Develop a risk management plan that outlines how these
risks will be monitored, assessed, and mitigated. By being
proactive in addressing risks, the project team can minimize
their impact on the project's progress.
Allocate Resources: Allocate the necessary resources, such
as human resources, technology, and budget, required for
the project's successful execution. Ensure that the
resources are available and properly allocated to support
the project's activities.
Obtain Stakeholder Buy‐In: Engage with stakeholders to
obtain buy‐in and support for the project. Communicate the
project's objectives, benefits, and impact clearly to gain
their approval and commitment. Address any concerns or
objections they may have to build trust and support.
Define Success Criteria: Clearly define the criteria for
measuring the project's success. How will you know if the
project has achieved its objectives? Establishing specific
success criteria allows the project team to monitor progress
and adjust as needed.
Establish Communication Channels: Set up effective
communication channels to facilitate collaboration and
information exchange among team members and
stakeholders. Regular and transparent communication is

93
essential for keeping everyone informed about the project's
progress.
Seek Expert Advice: If needed, seek advice from subject
matter experts or experienced professionals in the domain
of the project. Their insights can help refine the project
approach and avoid common pitfalls.
Quality Function Deployment (QFD)
Using this technique, customers are requested to prioritize
the requirements based on their relative importance to the
users of the proposed system. • QFD is a method that
transforms customer needs into technical requirements for
software engineering, classifying them into three types:
Normal requirements: These represent the objectives and
goals stated for the product or system during customer
meetings.
Expected requirements: These requirements are inherent
to the product or system and might be so fundamental that
the customer does not explicitly mention them.
Exciting requirements: These requirements go beyond
customer expectations and prove highly satisfying when
fulfilled.
During meetings with the customer, function deployment is
employed to assess the value of each function required for
the system. Information deployment identifies both the
data objects and events that the system must process.
Additionally, task deployment examines the system's
behavior in its environment, while value analysis

94
determines the relative priority of requirements from each
of the three deployments.
User Scenarios
As requirements are collected, a comprehensive depiction
of the system's functions and features starts to take shape.
• Developers and users collaborate to generate a series of
scenarios that outline the usage patterns for the system.
These scenarios aid the software engineering team in
understanding how end‐users will interact with the
functions and features of the system.
Elicitation Work Products
For many of the systems, the output comprises:
• A statement outlining the necessity and feasibility of
the project.
• A well‐defined scope of the system or product.
• An enumeration of the customers, users, and
stakeholders involved in requirements gathering.
• A comprehensive depiction of the system's technical
environment.
• A categorized list of requirements, along with the
domain constraints associated with each.
• A collection of usage scenarios that offer insights into
how the system or product will be used in diverse
operational situations.
• Any prototypes developed during the process to
further refine the requirements

95
CHAPTER 2.2. ELICITING ACCURATE
REQUIREMENTS

Introduction
Requirements extraction refers to the process of gathering
and defining requirements for a software system. The
primary objective of requirements identification is to
ensure that the software development process is built upon
a comprehensive understanding of the customer's needs
and requirements. The process of requirements extraction
entails identifying, collecting, analyzing, and refining the
requirements for a software system. This crucial step occurs
typically at the project's outset as a part of the software
development lifecycle. Stakeholders from various domains
within the organization, including business owners, end
users, and technical experts, are involved in requirements
extraction. The result of the requirements identification
process is a well‐defined, clear, and concise set of
requirements that serve as the groundwork for the design
and development of software systems. Requirements
derivation, considered the most intricate, error‐prone, and
communication‐intensive activity in software development,
heavily relies on effective collaboration between customers
and developers. The key to success lies in understanding
precisely what your users truly require.

96
Business requirements document:
A business requirements document (or BRD) is
a structured and formal description of an upcoming
project. This explains why a company needs to create new
software or business solution.
BRD also covers what problems the project will solve and
how much money it will bring in (or what loss the company
may lose if it does not build the software).
A business requirements document (BRD) is the starting
point for any software project or business decision. This
document introduces team members to what to build, why
to build and how to do it. BRD documents all stages of
product development, from brief descriptions to
expected results. Business requirements documents often
include:
 Current issues and project goals.
 The resources your company needs.
 Implementation phases and milestones of the project.
 Functional requirements (technical and non‐
technical) for the new solution.
 Project constraints (anything that could slow or
hinder project progress).
 Relevant Parties.
 danger.
 Expected ROI.

97
The structure of a business requirements document can vary
depending on the project type. For example, if the solution
we want to create is not software, we can reduce the technical f
eature requirements.
Requirements elicitation activities:
Requirements elicitation includes the subsequent activities.
Few of them are listed below –
 Knowledge of
he general areas to which the system applies.
 You must understand the details of
the exact problem of the client to which the
system will be applied.
 Interaction of the system with external requirements.
 A detailed study of user needs.
 Determine the limits of system development.
Requirements elicitation Methods
1. Interviews
2. Brainstorming Sessions
3. Facilitated Application Specification Technique (FAST)
4. Quality Function Deployment (QFD)
5. Use Case Approach
1. Interviews: The purpose of the interview is to
understand client's expectations of Software. Since it is no
t possible interview all stakeholders, group representatives
are selected based on experience and reliability.
•Interviews can be open‐ended or structured.
• Public interviews do not have a preset

98
agenda. Questions without context can be asked to
understand the problem.
•In a structured interview, the agenda is Enough open
questions have been prepared.
Sometimes the right questions subject of interview.
2. Brainstorming Sessions
 This is a group technique.
 Designed to generate many new ideas, providing a
platform for the exchange of opinions.
 A well‐trained facilitator is needed to deal with group
bias and group conflict.
 All ideas are documented for everyone to see.
 Finally, the following documents are being prepared. O
rganize with a list of requirements and their priorities.
3. Facilitated Application Specification Technique:
 The goal is to bridge
the expectations gap. Developers think
they should build, and customers think they'll get it. A
team‐oriented
approach was developed to gather requirements. Each
participant must complete a list of items.
 Eachparticipant creates their own list, merges other list
s, deletes duplicates, divides the team into
smaller subgroups to develop a mini‐spec, and
finally drafts the specification using all
the materials received from the meeting.

4. Quality Function Deployment:

99
 Customer satisfaction
is paramount in this technology, so we focus on
requirements that are valuable
to our customers. There are 3 types of requirements.
 Normal requirements –
At the same time, the purpose and objectives of the
proposed software are discussed with the
customer. yes. Common requirements for
a results management
system might be scoring, tabulation, etc.
 Expected requirements –
These requirements are so obvious that the
customer does not have to specify them. For example,
protection against unauthorized access.
 Exciting requirements –
It proves very satisfying when it includes features
that exceed customer expectations. Yes ‐ All processes
should be backed up and disabled if unauthorized
access is detected.

5. Use Case Approach:

This approach integrates text and visuals to enhance the
comprehension of your requirements. A use case focuses
on describing the system's "what" rather than the "how,"
offering a functional perspective. The components of use
case design encompass three primary elements: actors, use
cases, and use case diagrams.
Actor –
This is an external agent that is outside the system
but somehow interacts

100
with the system. It can be a learner, a machine, etc. He is
represented in the form of a rod. 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.
• Use cases –
Describes the sequence of interactions between actors
and actors. system. Record who (actors) and what (interac
tions) are doing. system. A complete set of use
cases defines all possible methods. use the system.

USECASE DIAGRAM:
A use case diagram is a graphical representation of what
happens when an actor interacts with a system.
• Capture functional aspects of the system.
• Stick figures are used to represent actors.

101
 • Ovals are used to represent use cases
• Lines are used to represent relationships
• Between actors and use cases.

Features of requirements elicitation:

• Stakeholder engagement
Requirements extraction involves interacting with
stakeholders such as customers, end users, project
sponsors, and subject matter experts to understand their
needs and requirements.
• Gathering information
Requirements elicitation includes gathering
information about the system being developed, the

102
business processes it will support, and the end users who
will use the system.
• Requirement prioritization
Requirements identification involves prioritizing
requirements according to their importance
to project success.
• Requirements documentation
Eliciting requirements involves documenting the
requirements in a clear and concise manner so that the
development team can easily understand and communicat
e them.
• Validation and verification
Requirements elicitation
involves reviewing and validating requirements with
stakeholders to ensure that they accurately
represent the needs and requirements.
• Iterative process
Requirements extraction is an iterative
process of continuously improving and updating
requirements based on stakeholder feedback.
• Communication and collaboration
Requirements extraction involves effective
communication and collaboration with stakeholders,
project team members, and other interested parties to
clearly understand and implement requirements.

103
• Flexibility
Requirements extraction requires flexibility to adapt to
changing requirements, stakeholder requirements, and
project constraints.

Advantages of Requirements Elicitation:

Accurate Understanding of Stakeholder Needs:
Requirements elicitation ensures that project teams have a
clear and accurate understanding of the needs and
expectations of stakeholders, including end‐users,
customers, and business owners. This leads to the
development of a solution that aligns with user
requirements.
Reduced Risk of Project Failure: By identifying and
clarifying requirements early in the project life cycle,
potential risks and misunderstandings can be addressed
proactively. This reduces the likelihood of project failure
due to poorly defined or misunderstood requirements.
Improved Communication: Effective requirements
elicitation involves engaging with stakeholders in a
collaborative manner. This improves communication
between the project team and stakeholders, leading to a
shared vision and a better understanding of project goals.
Scope Management: Clear requirements help in defining
the scope of the project accurately. This enables project
managers to control scope creep, preventing unnecessary
changes that may lead to delays and budget overruns.

104
Enhanced User Satisfaction: By focusing on user needs,
requirements elicitation ensures that the final product
meets the expectations of end‐users. This leads to higher
user satisfaction and increased adoption of the software or
system.
Cost and Time Savings: Identifying and resolving issues
related to requirements early in the project can save
significant time and cost. It reduces the need for rework and
prevents costly changes during later stages of
development.
Foundation for Design and Development: Well‐defined
requirements provide a solid foundation for the design and
development phases. Developers can use the requirements
as a guide to build the software or system accurately.
Customer Engagement and Involvement: Involving
customers and end‐users in the requirements elicitation
process fosters a sense of ownership and engagement. It
gives stakeholders the opportunity to shape the final
product according to their needs.
Flexibility to Changes: Agile requirements elicitation
methodologies allow for iterative and incremental
development, making it easier to adapt to changing needs
and priorities.
Higher Quality Deliverables: Clear and complete
requirements lead to higher quality deliverables. By
understanding the expectations upfront, the development
team can focus on meeting those requirements effectively.

105
Facilitates Prioritization: Effective requirements elicitation
aids in prioritizing features and functionalities based on
their importance to stakeholders. This helps in resource
allocation and managing project constraints.
Legal and Compliance Alignment: Requirements elicitation
ensures that the final product complies with legal
regulations and industry standards, reducing the risk of
legal disputes or non‐compliance issues.
Disadvantages of Requirements Elicitation:
Incomplete Requirements: Despite best efforts, it can be
challenging to capture all stakeholder needs
comprehensively. Some requirements might remain
undiscovered, leading to incomplete specifications and
potential functionality gaps.
Ambiguity and Misinterpretation: Ambiguous or poorly
defined requirements can lead to misunderstandings
between stakeholders and the development team. This
ambiguity might result in the implementation of incorrect
features or functionalities.
Changing Requirements: Requirements can evolve
throughout the project, especially in dynamic
environments. Frequent changes can lead to increased
project complexity, impacting timelines and budgets.
Scope Creep: If requirements are not effectively managed,
the project might experience scope creep. Additional
functionalities or changes might be introduced, extending
the project timeline and increasing costs.

106
Conflicting Requirements: Different stakeholders might
have conflicting needs and priorities. Resolving these
conflicts requires careful negotiation and might result in
compromises that do not fully satisfy all parties.
Limited User Representation: Engaging end‐users in the
requirements elicitation process can be challenging, leading
to a lack of representation of actual user needs.
Time and Resource Intensive: Thorough requirements
elicitation demands significant time and resources, which
can potentially delay the project's start or consume
valuable development time.
Subjectivity and Bias: The understanding of requirements
might be influenced by individual bias or perceptions,
affecting the accuracy and objectivity of the elicitation
process.
Why are Business Requirement Documents
Important?
BRD paints a complete picture of a potential
project. This document brings together all the teams involved in
project initiation and ensures successful implementation of the
project. In fact, the Project Management Institute found that
teams without preplanning are twice as likely to fail
Projects as prepared teams.
BRD also allows teams to:
• Monitor the overall health of the project.

107
• Bring stakeholders and team members together
to build consensus and collaboration. • Avoid the risk of
unexpected project changes.
• Understand your budget and projected ROI.
• Understand your project's limitations and
find the best solution to overcome them.
• Encourage team accountability by
setting clear and transparent goals.
How to Write a Business Requirement Document
Writing a Business Requirement Document (BRD) is a
critical step in the software development and project
management process. A BRD serves as a formal document
that outlines the objectives, scope, and detailed
requirements for a project or software system. It acts as a
foundation for the development team to design and
implement the solution effectively. Here's a step‐by‐step
guide on how to write a Business Requirement Document:
Project Overview: Start the document with a concise
project overview. Include the project's purpose, goals, and
a brief description of the intended solution. Provide
background information to give context to the
requirements.
Scope and Objectives: Clearly define the scope of the
project and its limitations. Specify what is within the
project's boundaries and what is excluded. State the
objectives that the project aims to achieve.

108
Stakeholder Analysis: Identify and describe the key
stakeholders involved in the project. This may include end‐
users, customers, project sponsors, business owners, and
other relevant parties. Understand their needs and
expectations to ensure the requirements cater to their
requirements.
Functional Requirements:
Detail the functional requirements that the system or
software must fulfill. Use clear and unambiguous language
to describe the desired behavior, features, and
functionalities of the solution. Organize requirements into
categories for easy navigation.
Non‐Functional Requirements:
Describe the non‐functional requirements, which focus on
qualities and constraints rather than specific functionalities.
These may include performance, security, usability,
scalability, and other system characteristics.
Use Cases and Scenarios: Provide use cases and scenarios
to illustrate how the system will be used in real‐life
situations. Use case diagrams, flowcharts, or narrative
descriptions to represent interactions between users and
the system.
Data Requirements: Specify the data needed by the
system, including data sources, formats, and data flow.
Define data entities and attributes required for the system's
operation.

109
User Interface (UI) Design: If applicable, include UI design
requirements, such as layout, color schemes, fonts, and
user interaction elements. Wireframes or mockups can be
included to visualize the UI.
Assumptions and Constraints: Document any assumptions
made during the requirements gathering process and
outline any limitations or constraints that may affect the
project's implementation.
Dependencies and Integration: Identify any dependencies
on external systems, APIs, or integrations with other
software. Describe how the system will interact with these
dependencies.
Testing and Quality Assurance: Outline the testing
requirements to ensure that the final solution meets the
specified requirements. Mention any specific testing
methodologies or acceptance criteria.
Change Management and Version Control: Include
guidelines for managing changes to the requirements and
how version control will be handled throughout the
project's life cycle.
Approval and Sign‐off: Define the process for obtaining
approval and sign‐off on the Business Requirement
Document. This ensures that stakeholders agree with the
documented requirements.
Review and Validation: Conduct thorough reviews and
validations of the BRD with relevant stakeholders to ensure

110
its accuracy, completeness, and alignment with business
needs.
Document Maintenance: Establish a plan for maintaining
the BRD throughout the project, ensuring it remains up to
date with any changes or updates.

111
CHAPTER 2.3. DEFINING USER
REQUIREMENTS‐VALIDATING
REQUIREMENTS

Introduction: ‐
Requirements definition is the process of gathering,
documenting, and analyzing the needs and constraints of a
project or system to determine what must be done to meet those
needs. This involves identifying the functional and non‐functional
requirements of the system, as well as any other constraints or
limitations that may impact the design and implementation.
The goal of requirements definition is to create a clear and
concise specification of what the system or project should do,
and what it should not do. This includes identifying the specific
features and capabilities that are required, as well as any
performance, reliability, security, or other non‐functional
requirements.
The requirements definition process typically involves
several stages, including:
1. Requirements gathering: Collecting information from
stakeholders, users, and other sources to understand the needs
and goals of the project.
2. Requirements analysis: Analyzing the gathered
information to identify the functional and non‐functional
requirements of the system.
3. Requirements documentation: Documenting the
requirements in a clear and concise manner, using standard
formats such as user stories, use cases, or functional
requirements specifications.

112
4. Requirements validation: Ensuring that the
requirements are complete, consistent, and feasible, and that
they meet the needs of all stakeholders.
Effective requirements definition is critical to the success of
any project or system, as it provides a clear roadmap for
development and helps to ensure that the final product meets
the needs of its users.
Types of Requirements:
There are several types of requirements, including:
 Functional Requirements: These are the specifications
that define what the system or product must do. They describe
the behaviour of the system in response to certain inputs or
actions.
 Non‐Functional Requirements: These requirements
define how the system must perform and specify the constraints
or conditions that the system must meet. Examples include
performance, reliability, security, usability, and accessibility
requirements.
 Business Requirements: These are the requirements
that specify what the system or product must achieve for the
business or organization. They define the goals and objectives
that the system must meet, and they help ensure that the system
is aligned with the business strategy.
 User Requirements: These requirements describe the
needs and expectations of the users of the system or product.
They specify the user interface, interactions, and user
experience.
 System Requirements: These are the technical
requirements that specify the hardware, software, and network
infrastructure required to support the system or product. They
define the architecture, components, and system integration.
 Design Requirements: These are the specifications that
define how the system or product should be designed. They

113
include the design principles, patterns, and guidelines that the
development team should follow.
 Performance Requirements: These requirements specify
how the system or product should perform under different
conditions, such as under high load or stress. They may include
requirements for response time, throughput, and scalability.

User Requirements
User requirements are a type of requirement that describes the
needs and expectations of the users of a system or product. They
are typically expressed in terms of the tasks that users need to
perform, the features and functions they require, and the user
experience they expect. Here are some more details about user
requirements:
 User Personas: To understand user requirements, it is
important to first develop user personas. User personas are
fictional characters that represent the different types of users
who will interact with the system or product. They are based on
research and data, and help the development team understand
the needs and expectations of different types of users.
 User Scenarios: Once the user personas have been
developed, the development team can create user scenarios.
User scenarios are stories that describe how users will interact
with the system or product to achieve their goals. They are often
used to test the usability and functionality of the system or
product.
 Functional Requirements: User requirements are often
expressed as functional requirements. These are the
specifications that describe the features and functions that the
system or product must have to meet the needs of users. They
are typically expressed in terms of user stories, which are short
descriptions of a specific feature or function from the perspective
of the user.

114
 User Interface Design: User requirements also play a
critical role in user interface design. The user interface is the part
of the system or product that users interact with, and it needs to
be designed to meet the needs and expectations of users. User
requirements can help inform the design of the user interface,
ensuring that it is intuitive and easy to use.
 Usability Testing: Finally, user requirements are often
used to guide usability testing. Usability testing involves testing
the system or product with real users to identify any usability
issues or areas for improvement. By testing the system or
product with users who represent the different user personas,
the development team can ensure that it meets the needs and
expectations of all users.

How to Identify User Requirements

Identifying user requirements is an important step in the
software development process. Here are some steps that can be
taken to identify user requirements:
 Identify Stakeholders: The first step in identifying user
requirements is to identify the stakeholders. These are the
people who have an interest in the system or product, and who
will be affected by its development and use. Stakeholders can
include end users, customers, business owners, managers, and
other key decision‐makers.
 Conduct User Research: Once the stakeholders have
been identified, user research can be conducted to gather
information about their needs and expectations. This can involve
various methods such as surveys, interviews, focus groups, and
observations.
 Develop User Personas: Based on the user research, the
development team can develop user personas. User personas are
fictional characters that represent the different types of users
who will interact with the system or product. They help the
development team understand the needs and expectations of
different types of users.

115
 Create User Scenarios: Once the user personas have
been developed, user scenarios can be created. User scenarios
are stories that describe how users will interact with the system
or product to achieve their goals. They are often used to test the
usability and functionality of the system or product.
 Prioritize Requirements: Once the user requirements
have been identified, they need to be prioritized. This can be
done based on the importance of the requirement to the user,
the business value of the requirement, and the feasibility of
implementing the requirement.
 Validate Requirements: Finally, the user requirements
need to be validated to ensure that they meet the needs and
expectations of the users. This can involve testing the system or
product with real users to identify any usability issues or areas
for improvement.
By following these steps, the development team can identify
user requirements that meet the needs and expectations of the
users, and that are aligned with the business goals of the
organization.
Requirements validation involves verifying that the
documented requirements align with the expectations and
requests of the stakeholders. In other words, verification is
about checking whether the requirements are complete,
correct, and consistent. Validation answers the question,
“Are we building the right system?”. We perform
Requirement validation to check issues related to
requirements. It helps us to identify errors at the initial
stage of development so that it does not result in excessive
rework when detected later in the system development life
cycle.

Validation: whether the right requirements have been

116
specified.
Verification: whether the requirements have been
specified right.

In simpler terms, Requirements verification is the process

of confirming that the system requirements contain all the
necessary elements of well‐written requirements.
Requirements validation is the process of confirming that
the written requirements agree with the stakeholders’
requests.

There are several checks that can be carried out to validate

requirements during the software development process.
Here are some of them:

 Consistency Check: This involves ensuring that

there are no conflicts or contradictions in the requirements.
All requirements should be checked to ensure that they are
consistent with one another and that they do not conflict
with other requirements.
 Feasibility Check: This involves ensuring that the
requirements can be implemented within the constraints of
the project, such as time, budget, and technical limitations.
Each requirement should be checked to ensure that it is
feasible and can be implemented within the given
constraints.
 Clarity Check: This involves ensuring that the
requirements are clear and unambiguous. Each
requirement should be checked to ensure that it is easy to

117
understand and that there are no ambiguities or
misunderstandings.
 Completeness Check: This involves ensuring that all
requirements have been identified and captured. Each
requirement should be checked to ensure that it is
complete and that there are no missing or incomplete
requirements.
 Traceability Check: This involves ensuring that each
requirement can be traced back to its source, such as a user
persona or a use case. Each requirement should be checked
to ensure that it is traceable and that there is a clear link
between the requirement and its source.
 Prioritization Check: This involves ensuring that the
requirements have been prioritized based on their
importance and relevance to the project goals. Each
requirement should be checked to ensure that it has been
prioritized correctly and that it is aligned with the business
goals of the organization.

By carrying out these checks, the development team can

validate the requirements and ensure that they are aligned
with the needs and expectations of the users, and with the
business goals of the organization.

Importance of Validating Requirements

Validating requirements is an essential part of the software

development process. Here are some of the reasons why
requirements validation is important:

118
 Ensures that the system meets user needs: Validating
requirements helps to ensure that the system is
developed to meet the needs and expectations of the
users. By validating the requirements, the development
team can ensure that the system is user‐friendly, easy
to use, and meets the specific needs of the target
audience.
 Reduces development time and costs: Validating
requirements can help to identify errors and omissions
early in the development process, which can reduce the
time and cost required to develop the system. By
identifying issues early, the development team can
make changes to the requirements before they are
implemented, which can prevent costly and time‐
consuming rework later on.
 Improves system quality: Validating requirements
helps to improve the quality of the system by ensuring
that the requirements are complete, consistent, and
feasible. By validating the requirements, the
development team can ensure that the system is
developed to a high standard and meets the needs of
the users.
 Increases stakeholder satisfaction: Validating
requirements helps to ensure that the system meets the
needs and expectations of all stakeholders, including
users, customers, and management. By ensuring that
the requirements are validated, the development team
can build trust and confidence with stakeholders, which
can lead to greater satisfaction with the system.
 Reduces project risks: Validating requirements helps to
identify potential risks and issues early in the
development process, which can reduce the risk of
project failure. By identifying issues early, the

119
 development team can make changes to the
requirements or the development approach to mitigate
risks and ensure project success.

Validation Techniques

Requirements validation techniques are methods used to

ensure that the requirements of a software system are
complete, correct, consistent, and feasible. Here are some
of the most common requirements validation techniques:

 Reviews and Inspections: This is a technique in which

the requirements are reviewed and inspected by a team
of experts to identify errors, omissions, and
inconsistencies. This technique involves the team of
experts, including the development team, subject
matter experts, and stakeholders, reviewing the
requirements document and discussing any issues that
arise.
 Prototyping: This is a technique in which a prototype or
a mockup of the system is developed based on the
requirements to test the usability and functionality of
the system. This technique helps to identify any
usability issues or areas for improvement before the
system is developed.
 Simulation: This is a technique in which the behavior of
the system is simulated to validate the requirements.
This technique involves creating a simulation model of
the system to test the functionality and performance of
the system.
 Testing: This is a technique in which the system is tested
against the requirements to validate its functionality
and performance. This technique involves developing

120
 test cases based on the requirements and testing the
system to ensure that it meets the requirements.
 Traceability: This is a technique in which the
requirements are traced back to their source to ensure
that they are complete and consistent. This technique
involves mapping the requirements to the user needs,
business goals, and other sources to ensure that all
requirements have been captured and that they are
consistent.

By using these techniques, the development team can

validate the requirements of the system and ensure that
they are complete, correct, consistent, and feasible. This
helps to ensure that the system meets the needs and
expectations of the users, and that it is aligned with the
business goals of the organization.

121
CHAPTER 2.4. ACHIEVING REQUIREMENTS
TRACEABILITY

Requirements traceability is defined as "The capacity to

describe and follow a requirement's life in both a forward
and backward direction (that is, from its inception through
development and specification, to its subsequent
deployment and use, and through periods of ongoing
refinement and iteration in any of these phases)".
There are several categories of requirement traceability,
including:
Forward traceability: Forward traceability tracks the
relationships between requirements and downstream
artifacts, such as design documents, test cases, and code. It
ensures that all requirements are satisfied by downstream
artifacts, enabling project teams to assess the impact of
changes on requirements.
Backward traceability: Backward traceability tracks the
relationships between downstream artifacts and their
corresponding requirements. It ensures that all artifacts are
traceable to requirements, enabling project teams to assess
the completeness of requirements and ensure that all
requirements are met.
Bidirectional traceability: Bidirectional traceability tracks
the relationships between requirements and both
upstream and downstream artifacts. It enables project

122
teams to assess the impact of changes on requirements and
downstream artifacts and to ensure that all requirements
are met by downstream artifacts.
Verification traceability: Verification traceability tracks the
relationships between requirements and their
corresponding verification activities, such as test cases and
inspections. It ensures that all requirements are validated
and verified and that the project delivers what is required.
Compliance traceability: Compliance traceability tracks the
relationships between requirements and compliance
standards and regulations. It ensures that the project meets
regulatory requirements and compliance standards, such as
ISO 9001, CMMI, and FDA regulations.
Each category of requirement traceability provides specific
benefits to project teams and enables them to manage
requirements effectively, make informed decisions, and
ensure project success.

Types of traceability in software development

• Source traceability – In essence, this refers to the

connections between requirements and the stakeholders
who put out these needs.

• Requirements traceability – These are the

connections between related needs..

123
• Design traceability – refers to the connections
between requirements and designs.

• Testing traceability – the relationship between test

cases and requirements that confirms each requirement
has been thoroughly verified.

• Code traceability – These are the connections

between the specifications and the actual code created to
implement those specifications.

• Version traceability – These are the connections

between several software or document versions that make
it possible to trace changes and updates across time.

• Release traceability – These are the connections

between the specifications and the particular software
version or release where they were implemented.

• Risk traceability – These are the connections

between the project's hazards and the risk‐mitigation steps
that were implemented.

• Business traceability – These are the connections

between the demands of the project and the overarching
aims of the company.

• Quality traceability – These connections between

the four phases of the software development process—
requirements, design, testing, and implementation—
ensure that quality is upheld.

124
Requirements Traceability Matrix (RTM)

A tool used in requirements traceability to keep track of the

connections between requirements and other project
artefacts, including test cases, design papers, and code, is
the Requirements Traceability Matrix (RTM). The RTM
offers a methodical methodology to record the
requirements and guarantees that they are all addressed
throughout the project lifecycle. So A document that
illustrates the connection between requirements and other
artefacts is known as a requirements traceability matrix. It
is employed to demonstrate that conditions have been met.

Additionally, it frequently records needs, tests, test results,

and problems. A table listing the criteria, their distinctive
identifiers, and the state of each requirement often makes
up an RTM. Columns in the table also allow you to link the
need to various project artefacts, including design papers,
test cases, and code. The RTM operates as a communication
tool for all parties involved in the project, ensuring that
everyone is aware of the requirements and how they relate
to other project artefacts. The following are some
advantages of an RTM for requirements traceability:

• Ensures completeness: The RTM ensures that all

requirements are documented, and their relationships
to other project artifacts are tracked. It helps to ensure
that all requirements are covered, and no requirements
are missed.

125
• Facilitates change management: The RTM facilitates
change management by allowing project teams to
identify the impact of changes on requirements and
other project artifacts. It helps project teams to assess
the risks and impacts of proposed changes, and make
informed decisions.

• Improves quality control: The RTM improves quality

control by ensuring that all requirements are validated
and verified. It enables project teams to track the status
of each requirement and ensure that all requirements
are met.

• Enhances project transparency: The RTM enhances

project transparency by providing a clear view of the
project requirements and their relationships to other
project artifacts. It helps project teams to communicate
effectively and ensures that all stakeholders have a
clear understanding of the project requirements.

Benefits of Requirements traceability

 Management of the solution scope. Managing the
solution scope is an integral part of the requirements

126
 traceability. It enables project teams to define, track,
and control the boundaries of the project and ensures
that the project delivers the desired outcomes within
the constraints of time, cost, and quality.
 Quick evaluation of potential changes. Requirements
traceability can facilitate quick evaluation of potential
changes by enabling project teams to understand the
impact of the changes on the project's requirements,
goals, and objectives. By using tools such as traceability
matrices, conducting impact analysis, prioritizing
requirements, assessing risks, and communicating with
stakeholders, project teams can evaluate potential
changes more efficiently and effectively.

 Reduced project risk. Requirements traceability can

help reduce project risk by providing a clear
understanding of the project requirements and their
relationship to the project goals and objectives. By
improving requirements management, increasing
project visibility, better change management,
enhancing communication, and improving quality
control, project teams can identify and mitigate
potential risks, and ensure project success.

 Promotes consistency between requirements.

Requirements traceability can promote consistency
between requirements by providing a mechanism for
tracking and validating relationships and dependencies
between different requirements. By cross‐referencing
requirements, verifying and validating them,

127
 performing impact analysis, managing them
consistently, and providing consistent documentation,
project teams can ensure that all requirements are
satisfied, and inconsistencies are eliminated.

 Allows monitoring and control across the lifecycle of

requirements. Requirements traceability allows for
monitoring and control across the lifecycle of
requirements by providing a systematic approach to
requirements management, enabling effective change
management, facilitating verification and validation,
enabling effective risk management, and ensuring
quality control. By tracking requirements and their
relationships, project teams can ensure that the project
meets its goals and objectives and is completed
successfully.

 Ensures alignment: Requirements traceability ensures

that all requirements are aligned with the project
objectives, business goals, and user needs. It helps to
verify that each requirement is consistent with the
project scope and that it supports the business case.

 Facilitates change management: Requirements

traceability helps to manage changes to the project by
ensuring that each requirement is tracked and
documented throughout the project lifecycle. It enables
the project team to assess the impact of changes and
ensure that all requirements are updated and validated
accordingly.

128
 Improves project quality: Requirements traceability
helps to improve the quality of the project by ensuring
that all requirements are verified, validated, and tested.
It enables the project team to identify gaps, ambiguities,
and inconsistencies in the requirements and to address
them before they become issues.
 Enhances communication: Requirements traceability
promotes effective communication among
stakeholders by providing a shared understanding of
the requirements and their relationship to project
objectives. It enables the project team to discuss and
resolve issues related to requirements in a collaborative
manner.
 Enables compliance: Requirements traceability is
essential for compliance with industry standards,
regulations, and best practices. It helps to ensure that
all requirements are met, and that the project meets
the necessary criteria for approval and certification.

Requirements Change Management

Requirements Change Management is the process of
systematically managing changes to project requirements
throughout the software development lifecycle. It involves
identifying, analyzing, evaluating, approving, and
implementing changes to requirements in order to
minimize their impact on project scope, schedule, cost, and
quality. The goal of requirements change management is to
ensure that all changes to requirements are carefully

129
considered and evaluated, and that the impact of changes
is fully understood before they are implemented. By
managing changes to requirements in a structured and
systematic way, project managers can ensure that project
outcomes are delivered on time, within budget, and to the
satisfaction of stakeholders.
Steps in changing management process in the organization
The steps involved in the change management process in an
organization may vary depending on the organization's size,
complexity, and culture. However, the following are some
common steps that are involved in a typical change
management process:
Identify the need for change: The first step in the change
management process is to identify the need for change.
This may be driven by external factors such as market
changes, technology advancements, or regulatory
requirements, or internal factors such as process
inefficiencies or customer feedback.
 Plan the change: Once the need for change has been
identified, the next step is to plan the change. This
involves identifying the scope of the change, defining
the objectives and goals of the change, and identifying
the resources and stakeholders needed to implement
the change.
 Assess the impact of the change: Before implementing
the change, it is important to assess its impact on the
organization. This involves identifying the potential risks
and benefits of the change, and assessing its impact on
the organization's operations, employees, customers,

130
 and stakeholders.
 Obtain buy‐in and support: To successfully implement
the change, it is important to obtain buy‐in and support
from stakeholders. This may involve communicating the
benefits of the change, addressing concerns and
objections, and engaging stakeholders in the change
process.
 Implement the change: Once the change has been
planned and approved, it can be implemented. This
involves putting the change into action, monitoring
progress, and adjusting as needed.
 Evaluate the change: After the change has been
implemented, it is important to evaluate its
effectiveness. This involves measuring the results of the
change, assessing its impact on the organization, and
identifying areas for further improvement.
 Maintain the change: To ensure the sustainability of the
change, it is important to maintain it over time. This may
involve establishing new processes and procedures,
providing training and support, and monitoring
performance to ensure that the change continues to
deliver its intended benefits. There are several
categories of requirement traceability, including:
Factors responsible for requirements change.
There are many factors that can lead to changes in project
requirements. Some of the common factors responsible for
requirements change include:
 Business environment changes: Changes in the business
environment, such as new regulations, market
conditions, or economic factors, can often lead to
changes in project requirements.
 Stakeholder feedback: Feedback from stakeholders,

131
 such as customers, end‐users, or project sponsors, can
often lead to changes in project requirements. This
feedback may be related to usability, functionality, or
other aspects of the project.
 Technology advancements: Advances in technology,
such as new software or hardware platforms, can often
lead to changes in project requirements. For example,
the need to support new mobile devices or operating
systems may require changes to the project's technical
requirements.
 Scope creep: Scope creep occurs when additional
requirements are added to the project without
corresponding adjustments to project timelines or
resources. Scope creep can often lead to changes in
project requirements as project teams seek to manage
the additional workload.
 Project team changes: Changes in project team
composition or skills can also lead to changes in project
requirements. For example, if a key team member
leaves the project, it may be necessary to revise project
requirements to accommodate the loss of expertise.
 Errors or omissions: Errors or omissions in the initial
requirements gathering process can also lead to
changes in project requirements. This may occur if key
requirements were missed or if requirements were not
clearly defined or understood by the project team.
Requirements change management process
There are 3 phases of effective handling of requirements
change management.
Phase 1: There are 3 preconditions.
Precondition 1: Flexible Planning

132
Impact of requirement change depends upon Project type
and project stage. It is obvious requirements are freeze in
early stage and depends upon type of the project. So,
flexibility for requirement change can be gained by
optimising the tasks and shifting decision to later project
stages.
Precondition 2: Changeable requirements
Changing requirements create risks, so it is needs to
analysis for each specific change. It includes following
Traceability: Record the interdependencies of
requirements and assessed the impact of change in the
software
Rationale: Check change is rationale or not
Owner: who is responsible for change in requirement and
should be able to connect all changes and links in the
different modules of the software.
Precondition 3: Requirements change management Policy
and Process
There are some key characteristics regarding requirement
change management policy and process.
 Change request: Who is eligible to make a
modification request? What details are required to include
in a modification request? ‐ Create a form for change
requests.
Who will be engaged in the decision‐making process for the
change control board? What shape will the communication
take? ‐ Establish a change management board.

133
How are decisions made? What factors are taken into
consideration? ‐ Create a template for a decision matrix.
Will the project's scope (budget and timeframe) alter after
approval? Who must consent to the modification? ‐ Involve
these parties as early as possible and persuade them of the
advantages of a necessary change.
Change plan ‐ What has to be done to implement the
change? When does it have to be done? How can it be
tracked? A change plan should tell you how to get from the
current situation to the desired situation
Phase 2 ‐ Dealing with Change Requests
Think before you act
When a modification request is received, chaos frequently
results. Your top aim should be to keep the project on track,
both financially and in terms of scheduling. Verify that the
new road is devoid of obstructions before departing from
the tried‐and‐true route. And make sure you get the
necessary stakeholders' consent. Follow your current
project plan's objectives till then.
Understand The Problem
Analyzing the effects of the desired modification may be
simple if you have guaranteed that your needs can be
traced back to their original form. Will the transformation,
however, last?
This question may be resolved by comprehending the
justification for the modification request. And the response
is helpful. After a few weeks, no one wants to modify a new

134
need once more because the initial modification did not
resolve the issue.
Consider Alternatives
If you comprehend the issue that led to the change request,
you could consider other fixes. It's possible that the change
request's suggested fix is not the best one for the issue.
Most likely, you'll discover a solution that satisfies the
requirements of the request and simplifies your life.
Create Involvement
You could consider other alternatives if you comprehend
the issue that led to the modification request. The change
request's suggested fix might not be the best way to handle
the issue. Most likely, you'll discover a solution that
accommodates the request's requirements while also
simplifying your life.
Get the approval.
It's time to stop thinking and start doing at some point.
Before putting the modification into effect, one more action
needs to be taken: approval.
You should now be aware of whether the modification is
advantageous and essential. Will the timetable and the
budget also be impacted? You will need the consent of
certain of your stakeholders in the event that the project's
completion date is pushed back or you need to spend extra
money. The moment has come to acquire it.
Make a plan

135
You are already aware of your location. Additionally, you
are now aware of your new location. However, how do you
get there? A change constitutes a project. Treat it with
respect. Learn what must be done. Specify who will do it,
when it must be finished, how the progress will be assessed,
and who will do it. As well as documenting everything in
requirements change plan, which might be as
straightforward as an activity list.
Phase 3 Implementing Change
Configuration Management
It can be a good idea to capture the setup before you begin
applying any changes. especially if it is a functional one.
After then, it is advised to record any changes. A change log
will be a wealth of information to get back on track if
something does go wrong at some time. And not just about
software projects.
Communication
If you haven't already, the moment has come to notify
everyone who will be impacted by the change. What details
must be provided? Just a few queries to ask when changes
occur are as follows: What the issue was? What is the
remedy? How does the remedy address the issue? What
impact do I feel? What should I do? When must it be
completed? There shouldn't be just one means of
communicating. While change is being introduced, have an
open ear. Unexpected occurrences could be discovered
before they cause harm.

136
Monitoring
One suggestion was to create a well‐defined plan for
executing the change. Monitoring will ensure adherence to
this plan, but it serves another crucial purpose as well. It is
highly likely that during implementation, certain aspects
may not progress as anticipated. By closely monitoring the
process, you gather essential information to respond
effectively to unexpected developments. This allows you to
adjust and adapt the plan accordingly.
Verification
How can you measure the effectiveness of your
requirements change management activities?
One criterion is that the problem is solved. How can you
verify this? Perform a formal check‐out review within the
change control board. Of course, the originator of the
change should participate. Once you verified that the
problem is solved, formally close the change process.

137
CHAPTER 2.5. REVIEWS, WALKTHROUGHS
AND INSPECTIONS, SRS VS USER STORIES

In the ever‐evolving landscape of software

development, ensuring the delivery of high‐quality
products has become paramount. Developers face
numerous challenges, including meeting tight deadlines,
addressing complex requirements, and managing project
constraints. To overcome these challenges and deliver
reliable and robust software, development teams often
employ various techniques such as Reviews, Walkthroughs,
and Inspections. These practices play a crucial role in
detecting defects, improving collaboration, and fostering a
culture of continuous improvement within development
teams. In this article, we will delve into the significance of
Reviews, Walkthroughs, and Inspections in software
development and explore how they contribute to
enhancing software quality.
Reviews
Reviews are structured evaluations of software artifacts
carried out by a group of stakeholders. The primary
objective of reviews is to identify defects early in the
development process and ensure that the software meets
its specified requirements. They can be conducted at
various stages of the development lifecycle, such as
requirements review, design review, code review, and

138
documentation review. Reviews can be informal, like a
quick peer review session, or formal, involving documented
processes and specific roles.
Benefits of Reviews:
Early detection of defects: By catching issues at an early
stage, developers can reduce the cost and effort required
to rectify them later in the development cycle.
Knowledge sharing: Reviews provide an excellent
opportunity for team members to learn from each other,
exchange ideas, and improve their understanding of the
project.
Improved collaboration: Review sessions foster better
communication among team members and facilitate the
sharing of diverse perspectives, leading to a stronger, more
cohesive team.
Walkthroughs
Walkthroughs involve a detailed, step‐by‐step examination
of the software product or its components, typically led by
the author of the artifact. The focus here is to familiarize
the audience with the software's functionality, design, and
underlying logic. Walkthroughs are more informative in
nature and do not aim to identify defects explicitly. Instead,
they are meant to provide a better understanding of the
software's architecture and design decisions.
Benefits of Walkthroughs:
Enhanced understanding: Walkthroughs help team
members comprehend complex parts of the software,

139
making it easier for them to contribute effectively to the
development process.
Feedback solicitation: Since walkthroughs encourage
questions and discussions, they can provide valuable
feedback to the author and help improve the quality of the
artifact.
Early validation: Walkthroughs can help identify potential
issues or misunderstandings before they turn into costly
defects.
Inspections
Inspections are systematic, formal assessments
conducted by a team of peers who evaluate a software
artifact to detect defects and assess its adherence to coding
standards and best practices. Unlike reviews, inspections
follow a predefined process that includes roles, checklists,
and specific meeting guidelines. The inspection team is
usually composed of individuals who have not been directly
involved in the artifact's creation, thus bringing fresh
perspectives to the evaluation.
Benefits of Inspections:
Thorough defect identification: Inspections are highly
effective in uncovering defects due to their systematic and
rigorous nature.
Process improvement: As inspections are guided by
checklists and predefined processes, they help enforce
coding standards and best practices, leading to higher
quality code and improved development processes.

140
Objective decision‐making: Inspections rely on data and
evidence rather than personal opinions, making them more
reliable for critical decisions in software development.
Requirement Engineering Process
a. Feasibility Study
b. Requirement Gathering
c. Software Requirement Specification
d. Software Requirement Validation

Software Requirement Specification (SRS)

A system analyst compiles the SRS after gathering the

requirements from various stakeholders. The
specifications we obtain from clients are expressed in
everyday language. The system analyst must write
down the requirements in technical terms so that the
software development team can understand and make
use of them.

Characteristics of SRS

 Complete: Both functional and non‐functional

needs should be included in the SRS for the
software system.
 Consistent: The SRS should not include any conflicts
and should utilise consistent terminology and
layout.

141
 Clear and explicit terminology should be used
throughout the SRS to avoid any ambiguity.

To make sure that all criteria are being satisfied, the

SRS should be traceable to other papers and artefacts,
such as use cases and user stories.

 Verifiable: The requirements in the SRS should be

able to be checked and validated to make sure they
are being met.
 Modifiable: In order to be updated and changed as
the software development process moves forward,
the SRS should be able to be modified.
 Prioritised: The SRS should rank the needs in order
of importance, starting with the most critical ones.
 Testable: The SRS has to be written in a way that
makes it possible to test and validate the
requirements.

Both high‐level and low‐level needs should be included

in the SRS, including both the former (such as the
overall system objectives) and the latter (such as the
specific functional requirements).

 Relevant: The SRS shouldn't contain any

information that is unneeded or irrelevant for the
software system that is being created.
 Human‐readable: The SRS needs to be written in a

142
 way that non‐technical stakeholders may easily
read and comprehend it.
 Alignment with organizational goals: The SRS
should be in line with the organization's broader
organizational goals and objectives to ensure that
the software system satisfies the requirements of
the company.
 Agile techniques: Agile approaches offer an
iterative approach to requirements gathering and
validation, where needs are recorded and validated
in tiny pieces of functionality and feedback.

Features of SRS

User Requirements are expressed in natural

language.

 Within the organization, structured language is

utilized to convey technical needs.
 Pseudo code should be used to write design
descriptions.
 Forms and GUI screen prints format.
 mathematical and conditional notations for DFDs,
etc.

Problems with SRS

 If you complete the SRS (software requirements

spec) before beginning the implementation, it
delays the first time you can see the software

143
 running and get feedback on whether the design is
a good one or not.
 Most customers cannot reveal their actual
requirements even under torture. The SRS may be
more about what the developers think, and much
less about what the customer wants.
 It’s easy to miss an important stakeholder like the
sales folks and not collect all the requirements.
 The hardest thing to see when reviewing an SRS is a
missing requirement.

User Stories

 User stories are short descriptions that focus on a

specific user and what they want to achieve. User
stories are placed in the SRS as a way of defining the
product’s features.
 User stories are part of an agile approach that helps
shift the focus from writing about requirements to
talking about them.

144

Format of user story
 As a [consumer], I desire [a shopping cart function]
so that [I can conveniently make online purchases].
 I want to [create a report] as a manager so that [I
can see which departments require additional
resources].
 I want to [get an SMS when the item is delivered] as
a [customer] so that [I can go pick it up immediately
away]
 I want to [withdraw the cash with a button push] as
a [bank client] so that [I can swiftly wrap up my
session without having to go through a bunch of
menu selections]
 Major distinction between user stories and
requirements
 How is it written?
 The user narrative is concerned with the user's
experience, or what they wish to be able to
accomplish when using the product. Traditional
specifications concentrate on functionality, or what
the product should be able to achieve.
 User stories should be written in one or two words
and should describe the user, their goals, and their
motivations. A straightforward framework for
designing features or user stories may resemble
this: I wish to accomplish ____ as a ____ to
experience the following advantage of ___.

145
 It usually takes longer to write requirements since
they are so specific. These frequently go into
detailed detail on how the software should operate
(sometimes in extremely technical terms). The
development team is then directed by those
specifics on how to create a new feature or
capability.

When are they written?

User stories are created when a product is being

developed. Additionally, the stories may be updated at
any moment (or new ones added). The functionality
that must be built is prioritized in the product backlog
for agile teams.

Additionally, requirements can be created at any

moment. However, if both stories and requirement
specification are necessary, it is ideal to explain what is
sought from the user's perspective first.

Who write it?

1. User stories may be created by pretty much

anybody familiar with the programme, such as
engineers who raise concerns or QA testers who
see a UX mistake, as long as they represent the
viewpoint of the end user.
2. The product manager, product owner, or business
analyst draughts requirements. Technical leaders

146
and the engineers who will be working on the
features or upgrades are frequently engaged.

147
CHAPTER 2.6. AGILE MODELLING, EXTREME
PROGRAMMING

Introduction:‐

What Is Agile Modeling?

Agile Modeling (AM) is a practices‐based process that

describes how to be an effective modeler.
AM helps you find the modeling sweet spot, where you
have modeled enough to explore and document your
system effectively, but not so much that it becomes a
burden that slows the project down.

At “The Official Agile Modeling Site,” Scott Ambler

[Amb02a] describes agile modeling (AM) in the following
manner:

“Agile Modeling (AM) is a practice‐based methodology for

effective modeling and documentation of software‐based
systems. Simply put, Agile Modeling (AM) is a collection of
values, principles, and practices for modeling software that
can be applied on a software development project in an
effective and light‐weight manner. Agile models are more
effective than traditional models because they are just
barely good, they don’t have to be perfect.”

The Principles for Agile Software Development

 Customer satisfaction is our first focus, and we achieve
this via timely and consistent delivery of high‐quality
software.
 Accept modifying requirements, even after work is

148
 complete. Agile methodologies harness change for the
benefit of the customer's competitiveness.
 Deliver functional software on a regular basis,
preferably within a few weeks rather than a few
months.
 Throughout the project, business professionals and
developers must collaborate everyday.
 Centre initiatives on motivated people. Trust them to do
the task and provide them with the atmosphere and
assistance they require.
 Face‐to‐face communication is the most effective and
efficient way to share
 Working software is the main indicator of development.
 Agile methods encourage sustainable growth. It should
be possible for the sponsors, developers, and users to
continue at the same pace indefinitely.
 Constant focus on technical perfection and smart design
increases agility.
 Simplicity is crucial since it is the art of maximizing the
amount of labor avoided.
 Self‐organizing teams produce the finest architectures,
needs, and designs.
 The team tunes and modifies its behavior in response to
periodic reflections on how to be more successful.

Agile Modeling is an approach to software development

that emphasizes flexibility, collaboration, and iterative
development. It is an extension of Agile methodologies,
such as Scrum and Kanban, specifically focusing on the
modeling aspects of the software development process.

Agile Modeling recognizes that traditional, heavyweight

modeling approaches can be rigid and time‐consuming,

149
often leading to documentation that becomes outdated or
irrelevant as the project progresses. Instead, Agile
Modeling promotes the idea of creating models that are
just good enough for the current needs of the team and the
project.

Key principles of Agile Modeling include:

 Simplicity: Agile Modeling advocates for keeping

models simple and avoiding unnecessary complexity.
Models should be easy to understand and
communicate.
 Iterative and Incremental: Models are developed in
small iterations, building upon and refining previous
models. This allows for feedback and adaptation as the
project evolves.
 Active Stakeholder Involvement: Agile Modeling
encourages collaboration and active involvement of
stakeholders throughout the modeling process. This
ensures that models accurately reflect the needs and
requirements of the project.
 Just‐in‐Time (JIT) Model Creation: Models are created
when they are needed and not before. This reduces
waste and ensures that models are relevant and up to
date.
 Model with a Purpose: Each model should have a clear
purpose, such as facilitating communication, supporting
decision‐making, or capturing specific requirements.
Unnecessary models or excessive detail should be
avoided.
 Agile Modeling techniques include various diagramming
notations, such as UML (Unified Modeling Language),
user stories, use cases, sketches, and prototypes. The

150
 choice of technique depends on the needs of the project
and the preferences of the team.
 Overall, Agile Modeling promotes an adaptive and
flexible approach to modeling, aligning with the
iterative nature of Agile software development
methodologies. By focusing on lightweight and
purposeful models, teams can improve collaboration,
responsiveness, and the overall effectiveness of their
development efforts.
 Agile Modeling offers several advantages for software
development teams. Here are some of the key benefits:
 Flexibility: Agile Modeling allows for flexibility and
adaptability throughout the development process. As
project requirements evolve, the models can be easily
adjusted and updated to reflect the changes, ensuring
that the team is always working with the most accurate
and relevant information.
 Collaboration: Agile Modeling promotes collaboration
among team members and stakeholders. By involving
stakeholders in the modeling process, the team can gain
valuable insights and feedback, leading to a better
understanding of requirements and improved
communication.
 Reduced Documentation Overhead: Traditional
modeling approaches often involve extensive
documentation, which can become time‐consuming
and burdensome. Agile Modeling focuses on creating
just‐enough documentation that fulfills the immediate
needs of the team. This reduces unnecessary overhead
and allows the team to focus more on delivering
working software.
 Improved Communication: Agile Modeling emphasizes
the use of visual models and diagrams, making it easier

151
 to convey complex ideas and concepts. Visual
representations help facilitate clearer communication
among team members, stakeholders, and even non‐
technical individuals, fostering a shared understanding
of the software being developed.
 Early Validation: Agile Modeling encourages the
creation of lightweight prototypes and mockups. These
early representations of the software allow for quick
validation of ideas and requirements. By validating the
models early on, the team can identify and address any
misunderstandings or issues before significant time and
effort are invested in implementation.
 Incremental Development: Agile Modeling supports an
iterative and incremental development approach. By
developing models in small increments, the team can
continuously refine and improve their understanding of
the system. This iterative feedback loop enables faster
learning, reduces the risk of costly mistakes, and
ensures that the final product meets the needs of the
stakeholders.
 Adaptability to Change: Agile Modeling aligns with
Agile development methodologies, which are designed
to embrace change. As requirements evolve or new
insights emerge, Agile Modeling allows for rapid
adjustments to the models. This adaptability helps the
team respond effectively to changing priorities and
deliver software that aligns with the evolving needs of
the project.
Overall, Agile Modeling offers the advantages of increased
flexibility, collaboration, efficient documentation,
improved communication, early validation, incremental
development, and adaptability to change. These benefits
contribute to a more responsive and effective software

152
development process.

Extreme Programming
An agile development methodology XP is “a lightweight
methodology for small to medium‐sized teams developing
software in the face of vague or rapidly changing
requirements.
It works by bringing the whole team together in the
presence of simple practices, with enough feedback to
enable the team to see where they are and to tune the
practices to their unique situation?

Hence XP is a lightweight (agile) process:

¨Instead of lots of documentation nailing down what

customer wants up front, XP emphasizes plenty of
feedback

¨Embrace change: iterate often, design and redesign, code

and test frequently, keep the customer involved

¨Deliver software to the customer in short (2 week)

iterations ¨Eliminate defects early, thus reducing costs

The XP Process

153
Extreme Programming uses an object‐oriented approach as
its preferred development paradigm and encompasses a set
of rules and practices that occur within the context of four
framework activities: planning, design, coding, and testing
Planning
The planning activity begins with listening—a requirements
gathering activity that enables the technical members of
the XP team to understand the business context for the
software and to get a broad feel for required output and
major features and functionality.
Listening leads to the creation of a set of “stories” (also
called user stories) that describe required output, features,
and functionality for software to be built
Design

XP design rigorously follows the KIS (keep it simple)

principle. A simple design is always preferred over a more
complex representation.
XP encourages the use of CRC (class‐

154
responsibilitycollaborator) cards as an effective mechanism
for thinking about the software in an object‐oriented
context

Coding
After stories are developed and preliminary design work is
done, the team does not move to code, but rather develops
a series of unit tests that will exercise each of the stories
that is to be included in the current release.
Once the unit test has been created, the developer is better
able to focus on what must be implemented to pass the
test Once the code is complete, it can be unit‐tested
immediately, thereby providing instantaneous feedback to
the developers.

Testing
The unit tests that are created should be implemented
using a framework that enables them to be automated
(hence, they can be executed easily and repeatedly).
This encourages a regression testing strategy whenever
code is modified (which is often, given the XP refactoring
philosophy).
XP acceptance tests, also called customer tests, are
specified by the customer and focus on overall system
features and functionality that are visible and reviewable by
the customer.
Extreme Programming (XP) is an Agile software
development methodology that emphasizes teamwork,
collaboration, and adaptability. XP offers several
advantages to development teams.

Here are some key benefits of Extreme Programming:

155
 Customer Satisfaction: XP focuses on satisfying the
customer by delivering working software frequently.
The continuous feedback loop with customers ensures
that their requirements and priorities are met
effectively. This customer‐centric approach improves
customer satisfaction and builds a strong partnership
between the development team and the customer.
 Adaptability to Changing Requirements: XP embraces
changing requirements as a natural part of the software
development process. It enables teams to respond
quickly to new insights, market demands, and evolving
business needs. By employing techniques like short
iterations and frequent releases, XP allows for flexibility
and easy adaptation to changing requirements.
 Continuous Feedback: XP emphasizes continuous
feedback throughout the development cycle. Frequent
communication with customers, regular testing, and
continuous integration enable early detection of issues,
bugs, and misunderstandings. This feedback loop helps
in course correction, reducing rework, and improving
the overall quality of the software.

 Collaboration and Teamwork: XP promotes close

collaboration and teamwork among developers,
customers, and other stakeholders. Pair programming,
where two developers work together on the same code,
fosters knowledge sharing, improves code quality, and
reduces the chances of errors. Collective code
ownership encourages all team members to take
responsibility for the codebase, facilitating
collaboration and fostering a sense of shared
ownership.
 Emphasis on Quality: XP places a strong emphasis on

156
 delivering high‐quality software. Practices such as Test‐
Driven Development (TDD) ensure that tests are written
before the code, helping to detect issues early and
validate the correctness of the implementation. The
focus on code simplicity, refactoring, and continuous
integration supports the maintenance of clean,
maintainable, and robust code.
 Predictability and Transparency: XP provides a
structured framework for development, enabling better
predictability in terms of progress and delivery. With
short iterations and regular releases, the team can track
their velocity and adjust their plans accordingly. The
transparency offered by practices like information
radiators (visual representations of project status)
ensures that everyone involved has visibility into the
project's progress and challenges.
 Reduced Risk: XP's practices, such as frequent releases,
continuous integration, and automated testing, help in
mitigating project risks. Early and regular feedback from
stakeholders and customers reduces the chances of
building the wrong product. The focus on small,
incremental changes and delivering value early helps in
managing project risks effectively.
 Developer Satisfaction and Productivity: XP prioritizes
the well‐being and satisfaction of developers. By
promoting sustainable pace and work‐life balance, it
helps prevent burnout and maintains a motivated team.
The collaborative environment, clear communication,
and shared ownership foster a positive and productive
working atmosphere.
Overall, Extreme Programming offers advantages such as
increased customer satisfaction, adaptability to change,
continuous feedback, collaboration, emphasis on quality,

157
predictability, risk reduction, and developer satisfaction.
These benefits contribute to faster delivery of high‐quality
software that meets customer needs in a dynamic and
changing environment.

158
CHAPTER 3.1. SCRUM
Scrum is a methodology for addressing complex adaptive
challenges while producing high‐value solutions in a productive
and creative manner.
Scrum is a process framework that has been used since the early
1990s to manage complicated product development. Scrum is
neither a process or a technique for creating goods; rather, it
provides a framework within which multiple processes and
techniques can be used. Scrum reveals the relative effectiveness
of your product management and development techniques,
allowing you to improve.
Scrum Teams with their associated roles, events, artifacts, and
rules comprise the Scrum framework. Each component of the
framework serves a distinct purpose and is critical to the success
and use of Scrum.
Scrum rules link together events, roles, and artifacts, controlling
their relationships and interactions.

Scrum standards
• Scrum is made up of three roles: product owner,
ScrumMaster, and development/engineering team. The next
sections will focus on the roles and responsibilities of each role.

159
 • Scrum employs sprints, which are fixed‐length iterations
lasting one week to four weeks (or 30 days).
• Scrum teams should have 7 +/‐ 2 members.
• Sprint cannot last longer than 30 days.
• Sprint is a timed event.
• The Scrum team strives to complete a potentially shippable
product by the conclusion of each sprint. • The daily Scrum /
Stand‐up meeting should be no more than 15 minutes, and the
team should remain standing during the meeting.
Roles and Responsibilities in Scrum
Product owner is in charge of the release burn‐down chart.
• In charge of the product vision.
• The person who maintains the product backlog and is
responsible for it.
• The only person who can decide whether or not the
product is ready to ship.
• The only person with authority to make a choice regarding
immediately discontinuing/stopping the sprint.
• The person is charge of providing clarification on the user
story to the development team as needed.
• The only person with authority to decide whether or not to
add new features to the product backlog.
• Someone who is continuously reprioritizing the product
backlog.
ScrumMaster • Scrum process facilitator.
• Assists in the resolution of any challenges or impediments
encountered by the Scrum team.
• Protects the team from outside interferences and
diversions.

160
 • Fosters a favorable climate in which the team can self‐
organize.
• Enforces time limits. • Person in charge of sprint burn‐down
/ burn‐up charts.
• The person in charge of facilitating the essential meetings.
• Has no management responsibility over the team (e.g., he
or she cannot order the team to complete a specific assignment).
• Encourages better engineering techniques.
• The exclusive point of contact for escalations.
• The only person who can handle escalations or requests to
upper management.
Development Team
• The development team should be self‐organizing and cross‐
functional (it should include personnel with testing,
development, business analyst, domain experience, and so on).
• The team's tasks should be self‐managed.
• Should address any people management concerns within
the team and only bring it to the ScrumMaster if it has gotten out
of the team's control.
• Collaborates with the product owner to reprioritize the
product backlog items.
• Comprises 7+/‐ 2 members. • Accountable for completing
the sprint's assigned tasks.
Sprint Phases
1. Product Backlog
The product backlog is a list of functionalities with short
descriptions drawn from the project's needs and roadmap, and it
is presented in the form of user stories. The product backlog is
the one source of requirements for all changes to the final

161
product. The product owner prioritizes user stories in
consultation with the development team, taking into account the
business priority of those user stories as well as any
dependencies on other stories. The product owner is in charge of
managing the product backlog.
2. Sprint Preparation
The product owner, ScrumMaster, and development team all
attend the sprint planning meeting. The sprint planning meeting
will last the amount of time determined by the following rule of
thumb: 'Multiply the number of weeks in your sprint by 2 hours'.
How and when will it be decided what the sprint time should be
and how many sprints the project should be broken into to fulfill
the requirements in the product backlog? What exactly is 'Sprint
0'? Sprint 0 is the phase in which resource planning, project
planning, sprint duration, and the number of sprints are
determined, as well as a little more debate on the product
backlog items. Sprint planning is fundamentally.
Sprint Goal, Sprint Backlog
Sprint Goal: The first half of sprint planning goes with deciding
the sprint goal. Here the team discusses on what needs to be
achieved at the end of that particular sprint. It is discussed and
decided collaboratively by the team and the product owner.
Sprint goal can be used for quick reporting on what has been
decided to complete as part of that sprint to the interested
stakeholders who are keen to know what is happening. Sprint
Backlog: This is the other output of sprint planning. The Sprint
backlog is the list of the product backlog item for which the
development team commits to deliver as part of that particular
sprint.

162
Sprint Velocity: Sprint velocity is the development team's
capacity to deliver the number of user stories based on expected
story points. The sprint velocity of the first sprint determines the
development team's capacity and will thus be beneficial for
arranging subsequent sprints accordingly.
3. Sprint Backlog:
The Sprint Backlog is a set of product backlog items that the
Development team has committed to delivering during that
particular sprint.
4. Sprint
Time frame during which the specific committed work must be
done. Sprints are timed and cannot be extended under any
circumstances, regardless of whether all committed user stories
are delivered or not. If any user story or part of a user story is still
waiting at the conclusion of the sprint, it will be pushed back to
the product backlog for reprioritization.
5. Scrum daily
In Scrum, the team holds a meeting called the Daily Scrum on
each day of the sprint. This gathering is usually held at the same
place and time every day. This meeting is strictly limited to 15
minutes. Each team member will discuss/answer the following
three questions at this meeting. a. What I did the day before. b.
What I plan to do today c. Any potential roadblocks The meeting
is mandatory for all team members, as well as the product owner
and ScrumMaster. Any issues raised during the Daily Scrum are
the ScrumMaster's responsibility to resolve as quickly as feasible
by hosting another meeting with the relevant group of people.
Daily Scrum meetings are not utilized for problem‐solving or

163
issue discussion. To resolve any difficulties, a separate meeting
should be conducted outside of Daily Scrum.
6. MVP stands for Minimum Viable Product.
The team hopes to have a possibly shippable product at the end
of each sprint. At the outset of each sprint, user stories are
chosen in such a way that, at the end of the sprint, they will be
able to create a possibly shippable product that can be sent and
used, hence increasing ROI.
7. Sprint Review
After each sprint, the Scrum team holds a sprint review meeting
to demonstrate the working product that was built and tested
throughout the sprint. Attendees included the ScrumMaster,
product owner, and Scrum team, as well as all
stakeholders/sponsors and customers. Multiply the amount of
weeks in your sprint by one hour.
8. Retrospective on the Sprint
There is always space for improvement no matter how good a
Scrum team is. After each sprint, the Scrum team arranges an
internal meeting, which is the sprint's final meeting, to analyze
what went wrong and what went well. This meeting is facilitated
by the ScrumMaster, who asks everyone to describe their ideas.
Participants included the ScrumMaster, the product owner, and
the Scrum team. Multiply the amount of weeks in your sprint by
one

164
CHAPTER 3.2. KANBAN

The main aim of this session is to discuss user stories. After

completing this session, students will have a clear understanding
of Kanban and its significance. They will also grasp the
advantages and disadvantages, as well as the features of Kanban.
Introduction:
The Agile methodology offers a project management approach
that involves breaking a project into phases and emphasizes
continuous collaboration with stakeholders. Throughout the
process, teams plan, execute, and evaluate, aiming for constant
improvement. Collaboration is crucial both within the team and
with project stakeholders. The Agile Manifesto, established in
2001, laid the foundation for Agile methodologies, focusing on
values such as individuals and interactions, working software,
customer collaboration, and adaptability to change. Agile project
management is known for its flexibility, adaptability, and
customer‐centric approach.
Agile Methodologies Frameworks:
Agile project management encompasses various frameworks,
including Scrum, Kanban, Extreme Programming (XP), and
Adaptive Project Framework (APF).
KANBAN:
Kanban is a method designed to manage, improve, and visualize
flow systems for knowledge work. It enables organizations to
initiate evolutionary change by using visual signaling mechanisms
known as kanban to control work in progress. Kanban finds

165
practical application in knowledge work settings, especially when
dealing with unpredictable work arrival and the need to deploy
work as soon as it's ready.
Values:
Teams adopting Kanban to enhance their services embrace the
following values: transparency, balance, collaboration, customer
focus, flow, leadership, understanding, agreement, and respect.
Principles:
Kanban addresses the resistance to change with the following
change management principles: start with the existing process,
pursue improvement through evolutionary change, and
encourage acts of leadership at every level. Additionally, the
service delivery principles focus on the work rather than the
individuals doing the work, emphasizing customer needs, self‐
organization, and evolving policies for better outcomes.
Practices:
Essential activities to manage a kanban system include
visualization using kanban boards, limiting work in progress,
managing flow, making policies explicit, implementing feedback
loops, and promoting collaborative improvement through
experimental evolution.
Roles:
Kanban doesn't prescribe explicit roles but rather encourages
teams to use their existing roles. However, two roles have
emerged in practice: the Service Request Manager, responsible
for understanding customer needs and selecting work items, and
the Service Delivery Manager, in charge of work flow and delivery
planning.
Lifecycle:

166
The lifecycle of the Kanban method revolves around feedback
loops, including the Strategy Review (quarterly), Operations
Review (monthly), Risk Review (monthly), Service Delivery
Review (bi‐weekly), Replenishment Meeting (weekly), Kanban
Meeting (daily), and Delivery Planning Meeting (per delivery
cadence). Each feedback loop serves a specific purpose in
optimizing the kanban system and improving service delivery.

167
CHAPTER 3.3. SAFE METHODOLOGY
The Scaled Agile Framework (SAFe) is a comprehensive and
widely adopted methodology for implementing Lean‐Agile
practices at scale in large organizations. It provides a structured
approach to address the challenges of coordinating and
delivering complex software and systems in a highly collaborative
and efficient manner. SAFe brings together principles, values,
practices, and roles from Agile, Lean, and systems thinking to
create a framework that can scale across teams, programs, and
the entire enterprise.
Core Values and Principles of SAFe:
At the heart of SAFe are its core values and principles, which
guide decision‐making and behavior throughout the
organization. These values and principles align with those in the
Agile Manifesto, emphasizing customer‐centricity, collaboration,
and continuous improvement.
 SAFe House of Lean:

SAFe is built on the foundation of Lean principles, which focus on

maximizing customer value while minimizing waste. The SAFe
House of Lean illustrates the five primary dimensions of Lean that
form the pillars of the framework:
a. Value: Understanding what customers truly value and
delivering it quickly and effectively.
b. Respect for People and Culture: Empowering individuals
and fostering a culture of innovation, learning, and respect.
c. Flow: Creating a smooth flow of work through the value
stream to improve efficiency and reduce delays.

168
 d. Innovation: Encouraging relentless improvement and
continuous learning.
e. Relentless Improvement: Striving for excellence through
continuous improvement.
 SAFe Agile Release Train (ART):

The Agile Release Train is a key construct in SAFe and serves as

the primary value delivery pipeline. It represents a long‐lived
team of Agile teams, typically spanning 50‐125 people, working
together to deliver value incrementally, predictably, and on a
regular schedule. The ART operates on fixed‐length iterations,
typically two weeks, called Program Increments (PIs). Each PI
ends with a System Demo and Inspect and Adapt (I&A) event,
allowing teams to showcase their work and make improvements.
 Portfolio, Value Stream, and ART:
At the highest level, SAFe aligns the portfolio, value streams,
and Agile Release Trains to create a cohesive and streamlined
approach to value delivery.
a. Portfolio: The portfolio level focuses on aligning business
strategy with execution by identifying and prioritizing value
streams, establishing budgets, and tracking performance. The
portfolio provides strategic themes that guide the development
efforts of value streams.
b. Value Stream: A value stream represents the series of
steps an organization undertakes to create value for a customer.
It typically includes multiple Agile Release Trains that work in
concert to deliver a solution or product.
c. ART: Agile Release Trains, as mentioned earlier, deliver
value incrementally and consistently through fixed‐length

169
iterations. They operate independently, but the coordination
between ARTs occurs through the value stream level.
SAFe Roles:
SAFe introduces several roles to ensure the smooth functioning
of the framework:
a. Release Train Engineer (RTE): Facilitates the Agile Release
Train's processes and execution, ensuring alignment,
communication, and coordination among teams.
b. Product Owner (PO) and Product Manager (PM): The PO
and PM roles work together to define and prioritize features and
stories, maximizing the value delivered to customers.
c. Scrum Master (SM): A servant leader and Agile coach who
supports the teams in their Agile journey and ensures they follow
Scrum practices.
d. System Architect/Engineer (SA/SE): Responsible for
guiding technical decisions, defining the architectural vision, and
ensuring system integrity.
SAFe Practices:
SAFe incorporates a set of well‐defined practices to enhance
Agile development and continuous delivery. These practices
include:
a. Program Increment (PI) Planning: A two‐day event that
aligns all team members with the goals and objectives for the
upcoming Program Increment.
b. Inspect and Adapt (I&A): A regular event held at the end of
each PI to assess the current state of the ART and identify areas
for improvement.

170
 c. Scrum of Scrums (SoS): A coordination meeting where
Scrum Masters from different teams discuss and resolve cross‐
team issues and dependencies.
d. DevOps and Release on Demand: Practices that emphasize
integrating development and operations to deliver new features
and fixes rapidly and reliably.
SAFe Configurations:
SAFe offers various configurations to suit different types of
organizations and industries. The most commonly used
configurations are:
a. Essential SAFe: This is the basic configuration, providing
the fundamental elements to get started with SAFe.
b. Large Solution SAFe: Suitable for organizations working on
large and complex solutions, it extends Essential SAFe with
additional roles, practices, and guidelines.
c. Portfolio SAFe: Tailored for organizations managing
multiple value streams and portfolios.
The Scaled Agile Framework (SAFe) provides a structured
approach to scaling Agile practices across large enterprises. Its
core values and principles align with the Agile Manifesto, and it
incorporates Lean principles to maximize value delivery while
minimizing waste. The SAFe Agile Release Train (ART) is a key
construct for value delivery, and roles, practices, and
configurations help organizations implement SAFe effectively. By
adopting SAFe, organizations can achieve greater collaboration,
flexibility, and efficiency in delivering valuable products and
solutions to their customers.

171
CHAPTER 3.4. JIRA TOOLS
Jira is a powerful and popular issue and project tracking software
developed by Atlassian. It is widely used by software
development teams and other project‐oriented organizations to
plan, track, and manage their work efficiently. Jira provides a
highly customizable and flexible platform that can be adapted to
various workflows, making it suitable for different industries and
teams. In this explanation, we will cover the key features,
benefits, and use cases of Jira.
Key Features of Jira:
Issue Tracking: Jira's primary function is to track and manage
issues or tasks. These issues can represent bugs, new features,
improvements, or any other work item that requires attention.
Each issue is assigned a unique identifier, and users can add
relevant details, attachments, comments, and tags to provide
comprehensive information.
Customizable Workflows: Jira allows users to define their own
workflows that reflect the stages and steps their work goes
through. Workflows can be simple or complex, with various
statuses and transitions, enabling teams to tailor the process
according to their specific needs.
Scrum and Kanban Boards: Jira supports Agile project
management methodologies, providing Scrum and Kanban
boards to visualize and manage work. Scrum boards represent
sprints and their associated tasks, while Kanban boards visualize
the flow of work through different stages.
Roadmaps and Releases: Jira offers roadmap and release
planning features, allowing teams to plan and track progress over

172
time. Roadmaps provide a high‐level view of upcoming features
and initiatives, while releases help manage versioning and
deployment.
Integration with Development Tools: Jira seamlessly integrates
with various development and collaboration tools like Bitbucket,
GitHub, Confluence, and others. This integration streamlines the
development process and provides a unified environment for
developers and other team members.
Reporting and Dashboards: Jira offers a range of built‐in reports
and the ability to create custom dashboards. These visualizations
help teams analyze performance, identify bottlenecks, and make
data‐driven decisions for continuous improvement.
Permissions and Access Control: Jira allows administrators to
manage user permissions and access control. Teams can define
who can view, edit, and transition issues, ensuring data security
and compliance.
Benefits of Jira:
Improved Collaboration: Jira provides a centralized platform for
teams to collaborate and communicate effectively. Team
members can discuss issues, share progress, and make decisions
within the tool, fostering better teamwork.
Enhanced Visibility: Jira's customizable dashboards and reports
offer real‐time insights into project status and performance. This
visibility helps stakeholders and team members stay informed
and aligned.
Increased Efficiency: With streamlined workflows and
automation, Jira reduces manual overhead and administrative
tasks, allowing teams to focus more on value‐adding activities.

173
Flexibility and Scalability: Jira's flexibility allows it to adapt to
various industries and workflows. It can scale from small teams
to large enterprises with complex projects and multiple teams.
Agile Project Management: Jira's support for Agile
methodologies like Scrum and Kanban enables teams to embrace
iterative and incremental development, leading to faster delivery
and customer satisfaction.
Traceability and Accountability: Jira maintains a comprehensive
history of issue changes and user actions, providing full
traceability and accountability for each work item.
Use Cases of Jira:
Software Development: Jira is widely used by software
development teams to track and manage bugs, features, and
user stories throughout the development lifecycle. It facilitates
collaboration between developers, testers, product owners, and
other stakeholders.
IT Service Management (ITSM): IT teams leverage Jira to handle
IT‐related issues, incidents, and service requests. It streamlines
IT processes and ensures efficient resolution of problems.
Project Management: Jira's flexibility extends beyond software
development, making it suitable for managing various types of
projects, whether they involve marketing campaigns, event
planning, or any other project‐oriented work.
Agile Transformation: Organizations undergoing Agile
transformations use Jira to support their Agile practices,
implement Scrum or Kanban methodologies, and foster a culture
of continuous improvement.

174
Bug Tracking and Quality Assurance: QA teams use Jira to log
and track defects found during testing, ensuring that issues are
resolved before the final product release.
HR and Recruitment: Some HR teams utilize Jira to manage
recruitment processes, track candidate progress, and coordinate
hiring activities.
Jira is a versatile and feature‐rich issue and project tracking tool
that has become a standard choice for many development and
project‐oriented teams. Its customizability, integration
capabilities, and support for Agile methodologies make it a
valuable asset for organizations seeking to improve
collaboration, visibility, and efficiency in their work processes.

175
CHAPTER 3.5. DESIGN PATTERNS

Design patterns are reusable solutions to common software

design problems that arise during the development process. They
are well‐proven approaches that have evolved over time and
help developers create scalable, maintainable, and flexible code.
Design patterns abstract and formalize design principles, making
it easier for developers to communicate and share best practices.
In this explanation, we will explore some of the most commonly
used design patterns, their categories, and their benefits.
Categories of Design Patterns: Design patterns can be
categorized into three main groups:
Creational Patterns: Creational patterns focus on object creation
mechanisms, providing ways to create objects in a manner that
is flexible and decoupled from the client code. Examples of
creational patterns include:
Singleton Pattern: Ensures that a class has only one instance and
provides a global point of access to that instance.
Factory Method Pattern: Defines an interface for creating
objects, but lets subclasses decide which class to instantiate.
Abstract Factory Pattern: Provides an interface for creating
families of related or dependent objects without specifying their
concrete classes.
Structural Patterns: Structural patterns deal with the
composition of classes and objects to form larger structures,
while keeping the system flexible and efficient. Examples of
structural patterns include:
Adapter Pattern: Allows incompatible interfaces to work
together by providing a bridge between them.

176
Decorator Pattern: Adds additional responsibilities to objects
dynamically, without modifying their code.
Facade Pattern: Provides a simplified interface to a complex
subsystem, making it easier to use.
Behavioral Patterns: Behavioral patterns focus on the
interaction and communication between objects, defining how
they collaborate and distribute responsibilities. Examples of
behavioral patterns include:
Observer Pattern: Allows one‐to‐many dependency between
objects, so that when one object changes state, all its dependents
are notified and updated automatically.
Strategy Pattern: Defines a family of algorithms and makes them
interchangeable, allowing clients to use different algorithms
without modifying their code.
Command Pattern: Encapsulates a request as an object, allowing
parameterization of clients with different requests, queuing of
requests, and logging of their execution.
Benefits of Design Patterns:Using design patterns in software
development offers several advantages:
Code Reusability: Design patterns promote the reuse of tried and
tested solutions, reducing the need to reinvent the wheel for
common problems.
Scalability and Maintainability: By following established
patterns, developers create code that is easier to scale and
maintain, reducing the risk of introducing errors during
modifications.
Clear Communication: Design patterns provide a common
vocabulary and set of guidelines for software design, enabling

177
developers to communicate more effectively and share best
practices.
Flexibility: Design patterns promote loose coupling between
classes, making the codebase more adaptable to changes and
reducing the impact of modifications on other parts of the
system.
Performance Improvement: Some design patterns, like the
Flyweight pattern, help optimize memory and improve
performance by sharing common data among multiple objects.
Testability: Code developed using design patterns tends to be
more testable, as dependencies are often well‐abstracted and
can be easily replaced with mock objects for testing purposes.
Examples of Design Patterns:
Let's briefly look at some practical examples of design patterns:
 Singleton Pattern:

The Singleton pattern ensures that a class has only one

instance and provides a global access point to that instance. It is
used when you need to control the number of instances for a
resource‐intensive object or to share a common resource across
multiple parts of the system. For example, a logging class can be
implemented as a Singleton to ensure that all parts of the
application share the same log instance.
 Observer Pattern:

The Observer pattern establishes a one‐to‐many dependency

between objects, allowing multiple observers (listeners) to be
notified and updated when the subject (observable) changes
state. This pattern is commonly used in graphical user interfaces
and event‐driven systems. For instance, in a weather monitoring
application, various displays (observers) can subscribe to a

178
weather station (subject) to receive updates whenever weather
conditions change.
 Factory Method Pattern:

The Factory Method pattern provides an interface for

creating objects but allows subclasses to decide which class to
instantiate. It is useful when you want to delegate the object
creation process to subclasses, providing a higher level of
abstraction for the client code. For example, in a document
processing application, a document factory can be implemented
as a Factory Method to produce different types of documents
(e.g., text documents, spreadsheets, presentations) based on the
user's choice.
 Decorator Pattern:

The Decorator pattern allows additional behavior to be

added to objects dynamically, without modifying their code. It is
useful when you need to extend the functionality of an object in
a flexible way. For example, in a UI framework, you can use the
Decorator pattern to add various decorators (e.g., borders,
shadows, tooltips) to a base UI element, enhancing its
appearance and behavior.
 Strategy Pattern:

The Strategy pattern defines a family of algorithms and

makes them interchangeable, allowing clients to choose different
algorithms at runtime. This pattern is helpful when you have
multiple algorithms that perform the same task but have
different implementations. For example, in a sorting application,
you can use the Strategy pattern to allow users to choose

179
different sorting algorithms (e.g., bubble sort, quicksort, merge
sort) based on their preferences or data size.
Design patterns are essential tools in a developer's arsenal,
offering proven solutions to recurring software design
challenges. By leveraging design patterns, developers can create
more maintainable, scalable, and flexible codebases, fostering
efficient collaboration and communication among team
members. The use of design patterns ensures that best practices
are followed and that software applications are built on solid and
reliable foundations.

180
CHAPTER 3.6. ARCHITECTURAL PATTERNS
Architectural patterns are high‐level design solutions that
address the overall structure and organization of software
systems. They define the fundamental principles and guidelines
for designing scalable, maintainable, and robust applications.
These patterns help in dividing the system into smaller
components, defining their relationships, and facilitating the
communication between them. In this explanation, we will
explore some commonly used architectural patterns, their
characteristics, and their benefits.
1. Layered Architecture:
The Layered Architecture pattern organizes the application into
horizontal layers, where each layer is responsible for specific
tasks and has a defined set of responsibilities. The layers typically
include the presentation layer, business logic layer, and data
access layer. This separation allows developers to work on
different layers independently, leading to improved modularity
and maintainability. The flow of data and communication
between layers is strictly controlled through well‐defined
interfaces.
Benefits:
Modularity: The application's components are organized into
separate layers, making it easier to understand, maintain, and
extend the system.
Separation of Concerns: Each layer focuses on specific
responsibilities, reducing complexity and enhancing code
readability.

181
Scalability: Layers can be distributed across multiple servers or
clusters, enabling horizontal scaling.
2. Model‐View‐Controller (MVC):
The Model‐View‐Controller pattern separates the application
into three components: Model, View, and Controller. The Model
represents the data and business logic, the View is responsible
for displaying the data to the user, and the Controller handles
user input and updates the Model and View accordingly. This
separation of concerns promotes maintainability, code
reusability, and testability.
Benefits:
Separation of Concerns: MVC cleanly separates data, user
interface, and application logic, making the codebase easier to
manage and maintain.
Code Reusability: With clear boundaries between components,
developers can reuse models and views in different parts of the
application.
Testability: The separation of concerns allows for easier unit
testing of individual components.
3. Microservices Architecture:
The Microservices Architecture pattern divides a large
application into small, independent, and loosely coupled
services, each responsible for a specific business capability. These
services communicate through well‐defined APIs, and each
service can be developed, deployed, and scaled independently.
This pattern promotes agility, flexibility, and fault isolation,
making it suitable for complex and large‐scale applications.
Benefits:

182
Scalability: Microservices can be scaled independently, allowing
each service to handle varying workloads.
Flexibility: Teams can choose different technologies for each
microservice, enabling flexibility and experimentation.
Fault Isolation: If one service fails, it does not impact the entire
system, as other services can continue to function.
4. Event‐Driven Architecture (EDA):
The Event‐Driven Architecture pattern relies on events and event
handlers to communicate between components and services.
When an event occurs, it triggers one or more event handlers,
allowing for loose coupling between components and promoting
asynchronous communication. EDA is particularly useful in
distributed systems, where different components may be
geographically separated.
Benefits:
Loose Coupling: Components are decoupled, enabling
independent development and evolution.
Scalability: EDA can handle a high volume of events and scale
effectively.
Asynchronous Communication: Event‐driven systems can handle
requests in a non‐blocking manner, improving performance and
responsiveness.
5. Service‐Oriented Architecture (SOA):
The Service‐Oriented Architecture pattern structures the
application as a set of services that communicate through
standardized protocols. Each service represents a specific
business capability and provides well‐defined interfaces for other
services to interact with. SOA promotes service reusability and
interoperability across different platforms and technologies.

183
Benefits:
Reusability: Services can be reused in different applications,
reducing development effort and promoting consistency.
Interoperability: SOA enables communication between services
developed in different languages and running on different
platforms.
Scalability: Individual services can be scaled independently,
providing flexibility in resource allocation.
6. Hexagonal Architecture (Ports and Adapters):
The Hexagonal Architecture pattern, also known as Ports and
Adapters, separates the application into three main components:
the application core, input ports, and output ports. The
application core contains the business logic, while the input ports
and output ports define the interfaces through which the
application interacts with external systems and users.
Benefits:
Separation of Concerns: The core business logic is isolated from
external dependencies, improving modularity and
maintainability.
Testability: External dependencies can be mocked, allowing for
easier testing of the application core.
Flexibility: Different input and output adapters can be plugged
into the application without affecting its core functionality.
Architectural patterns are essential tools for software architects
and developers to design scalable, maintainable, and flexible
applications. Each pattern addresses specific design challenges
and provides a set of guidelines and best practices to follow. By
choosing the appropriate architectural pattern for a given
project, developers can build robust and reliable software

184
systems that meet the requirements of modern software
development, including scalability, maintainability, and
adaptability.

185
CHAPTER 3.7. MODEL DRIVEN
ARCHITECTURE

Model‐Driven Architecture (MDA) is an approach to software

development that emphasizes the use of models as the central
artifacts for designing, specifying, and generating software
systems. MDA aims to improve productivity, maintainability, and
interoperability by providing a standardized and platform‐
independent way of expressing software designs. In this
explanation, we will delve into the key principles, components,
and benefits of Model‐Driven Architecture.
Key Principles of Model‐Driven Architecture:
 Platform‐Independent Models (PIMs):

At the core of MDA are platform‐independent models (PIMs).

These models represent the system's functionality, behavior, and
structure without being tied to any specific technology or
implementation. PIMs use standard modeling languages like
Unified Modeling Language (UML) or Domain‐Specific Modeling
Languages (DSMLs) to provide a clear, abstract representation of
the software.
 Platform‐Specific Models (PSMs):

MDA bridges the gap between the abstract PIMs and the
actual implementation on specific platforms. Platform‐specific
models (PSMs) are derived from PIMs and represent the
software's design and implementation on a specific platform or
technology. PSMs use platform‐specific modeling languages and
capture the technical details required to generate executable
code.

186
Model Transformations:
Model transformations are a key aspect of MDA. They convert
PIMs into PSMs and vice versa, automating the process of
translating high‐level abstract models into platform‐specific
details and vice versa. Model transformations enable the
generation of code, configuration files, and documentation from
the models, saving time and reducing errors in the software
development process.
Metamodeling and Metamodels:
Metamodeling is the process of defining a formal model that
describes the syntax and semantics of a modeling language.
Metamodels serve as the foundation for creating modeling
languages and are themselves expressed using metamodeling
languages like the Meta‐Object Facility (MOF). Metamodels
provide the rules and constraints that govern the structure and
relationships of models.
Model‐Driven Engineering (MDE):
Model‐Driven Engineering is the overarching approach that
encompasses MDA. It emphasizes the systematic use of models
throughout the software development lifecycle. MDE advocates
using models as the primary artifacts for analysis, design,
implementation, and testing, promoting consistency and
traceability across the development process.
Components of Model‐Driven Architecture:
MDA comprises the following components:
 Computation‐Independent Models (CIMs):

CIMs represent the system's functionality, requirements, and

high‐level design in a technology‐neutral manner. These models
are created during the early stages of the software development

187
process and serve as a basis for understanding the system's
overall requirements and objectives.
 Platform‐Independent Models (PIMs):

PIMs are refined versions of CIMs and provide a more detailed

and abstract representation of the system. They capture the
logical design and behavior of the software without being tied to
any specific technology. PIMs are the primary models used in
MDA.
 Platform‐Specific Models (PSMs):

PSMs are derived from PIMs and capture the technical details
required for implementing the software on a specific platform or
technology. They include platform‐specific design elements,
configurations, and implementation details.
Model Transformation Rules
Model transformations are rules or algorithms that define
how to transform models from one level of abstraction to
another. These transformations convert PIMs into PSMs and vice
versa, enabling the generation of code and other implementation
artifacts.
Code Generators:
Code generators take PSMs as input and produce executable
code in the target language and platform. They automate the
process of translating models into actual software, improving
development speed and reducing manual coding efforts.
Benefits of Model‐Driven Architecture:
Improved Productivity: MDA reduces the manual effort required
in writing code by automating the generation of code and other
implementation artifacts from models. This leads to increased
productivity and faster development cycles.

188
Consistency and Maintainability: Using models as the central
artifacts ensures consistency throughout the development
process. Any changes made to the models are automatically
reflected in the generated code, reducing the chances of
introducing errors.
Platform Independence: By separating the design from the
implementation, MDA allows software to be developed
independently of specific platforms. This promotes
interoperability and portability across different technologies and
environments.
Abstraction and Understanding: Models provide a high‐level
abstraction of the software, making it easier for stakeholders to
understand and review the system's design and behavior.
Adaptability to Technology Changes: MDA's separation of
concerns between PIMs and PSMs makes it easier to adapt to
changes in technology and platforms. When the underlying
technology evolves, only the platform‐specific models need to be
updated, leaving the PIMs unchanged.
Model Reusability: Models can be reused in different projects or
scenarios, providing a repository of best practices and domain‐
specific knowledge that can be leveraged across the
organization.
Challenges of Model‐Driven Architecture:
Despite its benefits, MDA also presents some challenges:
Modeling Complexity: Creating comprehensive and accurate
models can be challenging, especially for complex systems. The
effort required in modeling should be balanced with the benefits
gained.

189
Tooling and Standardization: The availability of suitable
modeling tools and the standardization of modeling languages
can impact the adoption of MDA.
Maintenance of Models: Models also need maintenance and
updating as the software evolves, which requires investment in
keeping the models up‐to‐date.
Model‐Driven Architecture is a powerful approach that leverages
models as the central artifacts for software design and
development. By emphasizing platform‐independent models and
automated model transformations, MDA promotes productivity,
maintainability, and platform independence. MDA can be
particularly beneficial for complex and large‐scale projects where
consistency, scalability, and agility are essential. However,
successful adoption of MDA requires skilled modeling expertise,
appropriate tooling, and a clear understanding of the software's
requirements and objectives.

190
CHAPTER 4.1. A STRATEGIC APPROACH TO
SOFTWARE TESTING, STRATEGIC ISSUES

Introduction:

Software plays a vital role in the functioning of government,

society, and businesses on both national and international
levels. The modern world heavily relies on software for its
operations. Software, in the form of computer‐based
systems, controls national and international infrastructures
and utilities, and it is integrated into the majority of
electrical products for computation and control purposes.
Industries such as manufacturing, distribution, and finance
are completely computerized, while entertainment sectors
like music, computer games, films, and television heavily
depend on software. The widespread use of software‐
controlled mobile phones encompasses more than 70% of
the global population, and by 2016, nearly all areas had
adopted software with internet connectivity.

Software Testing Strategies

The Changing Role of Software:

In a general sense, software refers to a structured set of

instructions executed by a computing device to produce
desired outcomes through various processes and functions.
Testing, on the other hand, is the process of thoroughly
examining a program with the specific aim of identifying
and correcting errors before it is delivered to end‐users.

A software testing strategy serves as a roadmap, outlining

the necessary steps to conduct testing, when to carry them

191
out, and the required effort, time, and resources. It
encompasses test planning, test case design, test execution,
and the collection and evaluation of resultant data. A well‐
designed testing strategy should offer flexibility to
accommodate customized testing approaches while
maintaining enough structure for effective planning and
management throughout the project's progression. The
diagram below illustrates the key operations involved in the
testing process.

An Effective Approach to Software Testing:

The testing process will involve the following key aspects:

 To ensure thorough testing, effective technical reviews

should be conducted. This will help eliminate many
errors even before the formal testing begins.
 Testing starts at the component level and gradually
extends "outward" to encompass the integration of the
entire computer‐based system.
 Different testing techniques are suitable for various
software engineering approaches and different stages
of development.
 Testing is carried out by the software developer and, in
the case of large projects, by an independent test group.
 While testing and debugging are distinct activities, any
testing strategy must include provisions for debugging.

Verification and Validation:

The adaptability of software systems is one of the key

reasons why software is increasingly integrated into large,
complex systems. Unlike hardware, making changes to

192
manufactured hardware is costly and challenging. However,
software can be modified at any point during or after the
system's development process.

Verification and validation play critical roles in this context.

Verification involves a set of tasks that ensure the software
correctly implements a specific function. Validation, on the
other hand, encompasses a different set of tasks aimed at
ensuring that the software aligns with customer
requirements. In simpler terms:

Verification: "Are we building the product correctly?"

Validation: "Are we building the right product?"

Today, only a few software systems are entirely new;

continuous development and maintenance are common.
Software evaluation is an ongoing process where the
software is continually modified over its lifetime to meet
changing requirements.

The validation process is illustrated in the figure below.

193
 Fig: 4.1 Validation process for testing

Testing Strategy

The testing process with a focus on 'testing‐in‐the‐small'

and gradually transition to 'testing‐in‐the‐large'.

For conventional software:

 Initially, our attention is on individual modules

(components).
 The integration of modules follows this phase.

For Object‐Oriented software:

194
 When "testing in the small" for Object‐Oriented (OO)
software, our focus shifts from testing individual
modules (as in the conventional approach) to testing an
OO class that includes attributes and operations,
implying communication and collaboration.

Strategic Issues

Here are some strategic considerations:

• Clearly specify product requirements in a quantifiable

manner well before commencing testing.

• Explicitly state the testing objectives.

• Gain a deep understanding of the software's user base

and develop a profile for each user category.

• Create a testing plan that prioritizes "rapid cycle testing."

• Construct "robust" (healthy) software that is designed to

perform self‐testing.

• Use effective technical reviews as a filtering step before

testing.

• Conduct technical reviews to assess the test strategy and

test cases themselves.

• Implement a continuous improvement approach for the

testing process.

The testing strategy adopted by most software teams lies

between the two extremes. It follows an incremental

195
approach, beginning with the testing of individual program
units, then moving on to tests aimed at facilitating the
integration of these units, and finally conducting tests that
thoroughly exercise the assembled system.

Unit Testing

Unit testing focuses on verifying the smallest unit of

software design, which is the software component or
module.

Considerations for unit testing:

 Test the module interface to ensure that information

flows correctly into and out of the program unit being
tested.
 Exercise all independent paths through the control
structure to ensure that every statement in the module
is executed at least once.
 Test boundary conditions to ensure proper operation at
established limits or restrictions.
 Verify the functionality of all error‐handling paths.

Fig: 4.2 Unit Testing considerations

The Integration Process Steps:

 The integration process follows these steps:

196
 The main control module serves as the test driver,
while stubs replace all components directly
subordinate to the main control module.
 Depending on the chosen integration approach (depth
or breadth first), subordinate stubs are gradually
replaced with actual components, one at a time.
 Tests are performed as each component is integrated
into the system.
 After completing each set of tests, another stub is
replaced with the real component.
 To ensure that no new errors have been introduced,
regression testing (explained later in this section) may
be carried out.
 This process continues from step 2 until the entire
program structure is constructed.

Unit Test Procedures:

Unit testing is typically seen as an extension of the coding

phase. The design of unit tests can take place either before
coding begins or after the source code has been generated.
Reviewing the design information provides valuable
guidance for creating test cases likely to uncover errors in
the categories discussed earlier. Each test case should be
associated with a set of expected results.

Stubs and Drivers:

Both stubs and drivers are dummy modules created solely

for testing purposes. Drivers act as "calling" programs and
are used in a bottom‐up testing approach. They are dummy
code used when the sub‐modules are ready, but the main
module is not yet prepared. On the other hand, stubs are

197
small pieces of code that substitute other components
during testing. Using stubs provides consistent results,
facilitating easier test writing even when other components
are not yet functional.

Fig: 4.3 Representation of stubs and drivers

INTEGRATION TESTING

Integration testing is a critical phase in the software

development life cycle that focuses on verifying the
interactions and integration between different modules or
components of a software system. The main objective of
integration testing is to ensure that these individual units
work seamlessly together as a cohesive whole, validating
the functionality, data flow, and communication between
them. This testing phase is crucial in identifying defects and
issues that may arise when the components interact,
helping to build a robust and reliable software product.

During the software development process, developers

typically work on individual units or modules, each
responsible for specific functionalities. These modules are

198
 then integrated to create the complete software system.
Integration testing ensures that the integration process
does not introduce any unexpected errors, and that the
integrated system performs as expected.

Types of Integration Testing:

Integration testing can be classified into different types,

based on the scope and approach:

 Big Bang Integration Testing: In this approach, all the

modules are integrated simultaneously, and the entire
system is tested in one go. While it can be a time‐saver, it
can also be challenging to pinpoint the source of issues if
they arise.
 Top‐Down Integration Testing: This strategy tests the
higher‐level modules first, and then the lower‐level
modules are gradually integrated and tested. Stub modules
or simulators may be used to represent lower‐level
modules during this testing.
 Bottom‐Up Integration Testing: In contrast to top‐down,
this approach begins with the lower‐level modules, and
then the higher‐level modules are integrated progressively.
Drivers may be used to represent higher‐level modules
during this testing.
 Incremental Integration Testing: This method involves
integrating and testing modules incrementally in small
groups. It allows for a systematic and controlled approach
to integration.

Challenges in Integration Testing:

Integration testing can be complex and challenging due to

various factors:

199
 Dependency Management: Managing dependencies
between modules and ensuring that all required
components are available for testing can be difficult.
 Data Sharing and Data Flow: Proper data sharing and data
flow between integrated modules must be validated to
avoid data inconsistencies and corruption.
 Interface Compatibility: Ensuring that interfaces between
modules are compatible and that they interact correctly
can be a major challenge.
 Integration Points: Identifying and testing all possible
integration points between modules is crucial to detect
integration‐related defects.
 Environment Setup: Creating and maintaining a suitable
test environment that mirrors the production environment
can be time‐consuming.

Best Practices in Integration Testing:

To conduct successful integration testing, several best

practices should be followed:

 Early Planning: Plan integration testing early in the

development process to identify dependencies and
potential challenges.
 Test Environment: Set up a controlled and representative
test environment to simulate the production environment.
 Testing Stubs and Drivers: Develop stubs (for lower‐level
modules) and drivers (for higher‐level modules) to facilitate
testing when dependent components are unavailable.
 Incremental Approach: Adopt an incremental integration
approach to tackle integration complexity in manageable
chunks.
 Test Data Management: Ensure proper test data
management to test different scenarios effectively.

200
 Integration Testing Tools: Utilize automated testing tools
specifically designed for integration testing to improve
efficiency and accuracy.

Regression Testing:

Regression testing is a software testing technique used to

verify that recent changes or updates to a software
application do not negatively impact its existing
functionality. When new features are added, defects are
fixed, or code is modified, there's a risk of unintentionally
introducing new bugs or disrupting previously working
parts of the software. Regression testing aims to catch and
address these issues early, ensuring that the software
continues to work as intended after each change.
Purpose of Regression Testing:
The primary objectives of regression testing include:
 Detecting Regressions: The main purpose is to identify
any regressions, which are defects that have
resurfaced due to changes in the software.
 Validation of Changes: Regression testing validates
that the new features or changes have been correctly
implemented without causing unintended side effects.
 Maintaining Software Quality: By identifying and fixing
regressions promptly, regression testing helps
maintain the overall quality and reliability of the
software.
 Preventing Software Degradation: Ensuring that the
existing functionality remains intact and unaffected by
new changes helps prevent software degradation.

201
Regression Testing Process:
The regression testing process involves the following steps:
 Selecting Test Cases: Identify and select the test cases
that will be used to perform regression testing.
Typically, the focus is on critical test cases that cover
essential functionalities and areas that have been
affected by recent changes.
 Test Data Preparation: Ensure that appropriate test
data is available to execute the selected test cases
effectively.
 Executing Test Cases: Execute the selected test cases on
the updated version of the software. This can be done
manually or through automated testing tools.
 Comparing Results: Compare the actual results
obtained during regression testing with the expected
results from the previous version of the software.
 Identifying and Reporting Defects: If any discrepancies
are found between the actual and expected results,
they are recorded as defects and reported for
resolution.
 Defect Resolution: Developers investigate and fix the
reported defects, and the fixes undergo verification.
 Repeating the Process: The regression testing process
is repeated whenever there are new changes to the
software. It's an ongoing activity throughout the
software development life cycle.

Regression Testing Techniques:

Several techniques are employed to perform regression
testing:

202
 Retest All: In this approach, all existing test cases are
re‐executed from scratch. It ensures comprehensive
coverage but can be time‐consuming.
 Test Selection: This approach involves selecting only the
relevant test cases impacted by the recent changes. It
saves time compared to the "Retest All" approach.
 Test Case Prioritization: Test cases are prioritized based
on criticality and importance. High‐priority test cases
are retested first.
 Test Case Subset: This approach selects a subset of test
cases that provide sufficient coverage for the changes
made.
 Automated Regression Testing: Automation tools are
used to re‐run test cases efficiently, reducing the time
and effort required for regression testing.
Challenges in Regression Testing:
Regression testing can present several challenges:
 Time and Resource Constraints: Comprehensive
regression testing can be time‐consuming, especially for
large software systems.
 Test Data Management: Ensuring the availability of
appropriate and representative test data can be
challenging.
 Test Environment Stability: Maintaining a stable and
consistent test environment is crucial for accurate
testing.
 Test Case Maintenance: As the software evolves, test
cases may need to be updated to reflect changes in the
application.

203
CHAPTER 4.2. TEST STRATEGIES FOR
CONVENTIONAL SOFTWARE

Test strategies for conventional software involve the systematic

planning and execution of testing activities to ensure the quality,
reliability, and functionality of the software product. These
strategies are designed to identify defects, verify that the
software meets its requirements, and validate that it works as
intended. Here are some common test strategies for
conventional software:
 Requirement Analysis: Understanding and analyzing the
software requirements is the foundation of any testing
effort. Testers work closely with stakeholders to gather
requirements and ensure they are clear, complete, and
testable.
 Test Planning: This phase involves creating a comprehensive
test plan that outlines the testing scope, objectives,
resources, schedule, and test environment requirements.
The plan serves as a roadmap for the entire testing process.
 Test Design: Testers design test cases based on the software
requirements. Test cases describe the steps to execute, the
expected results, and the test data needed. It's important to
cover both positive and negative scenarios.
 Test Execution: During this phase, testers execute the
designed test cases on the software. They record the actual
results and compare them against the expected results.
Defects are identified and reported in a bug tracking system.
 Regression Testing: When new features are added, bugs are
fixed, or changes are made to the software, regression
testing ensures that existing functionalities still work as

204
 expected. It prevents the introduction of new issues while
making modifications.

 Integration Testing: This strategy tests how different

modules or components of the software work together as a
whole. It helps identify issues that may arise when
integrating individual parts.
 System Testing: System testing involves testing the entire
software system in an environment that closely resembles
the production environment. It aims to verify that the
software meets all specified requirements.
 User Acceptance Testing (UAT): UAT involves end‐users or
client representatives testing the software to ensure it meets
their needs and requirements. It is the final stage of testing
before the software is deployed.
 Performance Testing: This strategy evaluates the software's
performance under various conditions, such as load testing
(testing under expected user loads) and stress testing
(testing beyond expected loads).
 Security Testing: Security testing identifies vulnerabilities
and weaknesses in the software that may expose it to
potential threats. It includes testing for data breaches,
unauthorized access, and other security risks.
 Usability Testing: Usability testing assesses how user‐
friendly the software is. Testers observe real users as they
interact with the software and gather feedback to improve
the user experience.
 Automated Testing: Automated testing involves using
testing tools and scripts to automate the execution of
repetitive test cases. This approach saves time and resources
and ensures consistent testing.
 Exploratory Testing: Exploratory testing is a flexible
approach where testers explore the software dynamically,

205
 without relying on predefined test cases. It is used to uncover
unexpected issues and to supplement other testing
approaches.
 Code Review and Static Analysis: In addition to testing,
reviewing the source code and performing static analysis
helps identify potential coding errors and ensures adherence
to coding standards.

A successful test strategy is adaptive, comprehensive, and

tailored to the specific software project. It ensures that the
software meets its quality objectives and delivers a reliable and
satisfactory user experience.

206
CHAPTER 4.3. BLACK BOX & WHITE BOX
TESTING
Black box testing, also known as behavioral testing or
functional testing is a software testing technique where
testers evaluate the functionality of a software application
without having access to its internal code, structure, or
implementation details. Testers focus solely on the
software's externally visible behavior, treating the
application as a "black box" whose internal workings are not
visible or known. The primary goal of black box testing is to
assess the software's functionality, adherence to
requirements, and its ability to handle various inputs and
produce the expected outputs.
Key Characteristics of Black Box Testing:
 No Knowledge of Internal Code: Testers performing
black box testing have no knowledge of the underlying
code, architecture, or design of the software being
tested. They only rely on the software's specifications
and requirements.
 Functional Testing: Black box testing focuses on
verifying the functional aspects of the software,
ensuring that it performs according to the specified
requirements.
 User‐Centric Perspective: Black box testing is
conducted from an end‐user perspective, emphasizing
how the application behaves and responds to various
inputs and actions.

207
 Independent Testing: Black box testing can be
performed independently of the development team,
allowing for unbiased evaluation of the software.
 Multiple Testers: Testers with different backgrounds
and expertise can perform black box testing, providing
a diverse range of test scenarios.
Advantages of Black Box Testing:
 Early Testing: Black box testing can begin as soon as the
software requirements are available, even before the
code is developed.
 Tester Independence: Testers do not require
programming knowledge, making it easier to involve
individuals without coding skills in the testing process.
 Focus on User Requirements: Black box testing ensures
that the software meets user requirements and
behaves as expected.
 Encourages Creativity: Testers can approach testing
scenarios from diverse angles, promoting creativity in
test case design.

Common Black Box Testing Techniques:

 Equivalence Partitioning: Testers divide input data into
groups based on the assumption that the application
will respond similarly to any data within each group.
One representative test case from each partition is
selected for testing.
 Boundary Value Analysis: This technique focuses on the
boundaries of input data. Test cases are designed using
values at the lower and upper limits of the data ranges.

208
 State Transition Testing: It is used for applications that
have different states and undergo transitions. Test
cases are designed to cover various state transitions.
 Decision Table Testing: Testers create a decision table
to represent different combinations of inputs and
expected outputs, helping to identify all possible
scenarios.
 Use Case Testing: Testers design test cases based on use
cases to simulate end‐user interactions with the
software.
Limitations of Black Box Testing:
 Limited Coverage: Black box testing may not cover all
possible scenarios or test cases, as it relies on the
tester's creativity and understanding of requirements.
 Inefficient for Complex Logic: It may be challenging to
cover all aspects of complex business logic without
knowledge of the internal code.
 Redundant Test Cases: Some test cases may duplicate
functionality, leading to unnecessary repetition.
White Box Testing
White box testing, also known as clear box testing or
structural testing, is a software testing technique where
testers examine and evaluate the internal structure, code,
and design of a software application. Unlike black box
testing, white box testing requires knowledge of the
application's internal workings, allowing testers to design
test cases based on the application's internal logic and
structure. The primary objective of white box testing is to

209
ensure that the software's internal components function
correctly and that all possible paths and conditions in the
code are thoroughly tested.
Key Characteristics of White Box Testing:
 Access to Internal Code: Testers performing white box
testing have access to the application's source code,
design documents, and other implementation details.
 Code‐Centric Testing: White box testing is focused on
verifying the internal components, data structures, and
control flow of the software.
 In‐depth Testing: Testers can perform in‐depth code
analysis to identify potential issues, such as code
vulnerabilities, loops, and conditional statements.
 Code Coverage Metrics: White box testing often
involves measuring code coverage, which assesses the
percentage of code executed during testing.
Advantages of White Box Testing:
 Thorough Testing: White box testing allows for
comprehensive coverage of code paths, including
branches, loops, and conditional statements.
 Early Detection of Defects: Since white box testing can
begin during the development phase, it helps in early
detection and resolution of issues.
 Code Optimization: White box testing can identify areas
of the code that are inefficient or prone to errors,
allowing developers to optimize the code.
 Security Testing: Testers can identify potential security
vulnerabilities and loopholes by analyzing the code for
potential weaknesses.

210
Common White Box Testing Techniques:
 Statement Coverage: This technique ensures that each
statement in the code is executed at least once during
testing.
 Branch Coverage: Branches represent decision points in
the code (e.g., if‐else statements). Branch coverage
ensures that all possible branches are tested.
 Path Coverage: Path coverage involves testing all
possible paths from the entry point to the exit point in
the code.
 Loop Testing: This technique focuses on testing loops
with zero, one, and multiple iterations to validate their
correctness.
 Code Review and Static Analysis: While not traditional
testing techniques, code reviews and static analysis help
identify coding issues and ensure adherence to coding
standards.
Limitations of White Box Testing:
 Complexity: White box testing can be challenging and
time‐consuming, especially for large and complex
codebases.
 Inadequate Test Coverage: Despite comprehensive
testing, it may still be difficult to cover all possible code
paths and scenarios.
 Dependency on Implementation: Test cases may be
tightly coupled with the implementation, making them
less effective if significant changes are made to the
code.
DIFFERENTIATE BLACK BOX AND WHITE BOX TESTING

211
 Black box testing and white box testing are two distinct
software testing techniques that differ in their
approach, focus, and level of knowledge about the
software under test. Let's explore the key differences
between these two testing methods:
1. Knowledge of Internal Structure:
 Black Box Testing: Testers performing black box
testing have no knowledge of the internal code, design, or
implementation of the software application. They treat the
software as a "black box" and focus solely on its externally
visible behavior.
 White Box Testing: In contrast, white box testing
requires testers to have access to the internal code, design,
and implementation details of the software. They can
analyze the application's internal structure and logic.
2. Focus on Testing:
 Black Box Testing: This technique is primarily focused on
verifying the functionality of the software from an end‐
user perspective. Testers evaluate whether the
software meets specified requirements without
concern for how it is implemented.
 White Box Testing: White box testing is code‐centric.
Testers examine the internal components, data
structures, and control flow of the software to validate
its correctness and uncover any potential issues within
the code.
3. Test Case Design:
 Black Box Testing: Testers design test cases based on
the software's specifications and requirements, without

212
 relying on the knowledge of the underlying code. Test
cases are created to simulate various real‐world
scenarios and user interactions.
 White Box Testing: Test cases in white box testing are
designed based on the internal code and logic of the
software. Testers create test cases to exercise different
code paths, branches, and conditions to achieve higher
code coverage.
4. Independence from Development:
 Black Box Testing: Black box testing can be performed
independently of the development team since testers
do not require access to the internal code. This
independence helps maintain objectivity in the testing
process.
 White Box Testing: White box testing may require
collaboration with developers, as testers need access to
the source code and understanding of the application's
implementation details.
5. Test Coverage:
 Black Box Testing: Test coverage is based on the
external requirements and user scenarios. Testers focus
on validating the software's functionality as specified in
the requirements.
 White Box Testing: Test coverage is based on the
internal structure of the software. Testers aim to cover
all possible code paths, branches, and conditions in the
code to ensure thorough testing.
6. Time of Execution:

213
 Black Box Testing: Black box testing can be initiated
early in the software development life cycle, as soon as
the requirements are available.
 White Box Testing: White box testing is often performed
during the later stages of development when the source
code is available for analysis.
Conclusion:
Black box testing and white box testing are complementary
techniques in software testing. Black box testing evaluates
the software from an end‐user perspective, ensuring that it
meets specified requirements, while white box testing
delves into the internal code to verify correctness and
identify potential issues. Combining both approaches in a
testing strategy provides comprehensive coverage and
helps deliver high‐quality software products.

214
CHAPTER 4.4. VALIDATION TESTING

Validation testing, also known as acceptance testing or user

acceptance testing (UAT), is a crucial phase in the software
testing process. It focuses on evaluating whether the
software meets the intended business requirements and
whether it is acceptable for delivery to the end‐users or
customers. The primary objective of validation testing is to
ensure that the software aligns with the stakeholders'
expectations and is fit for its intended purpose.

Fig. 4. Validation Testing

Key Characteristics of Validation Testing:
 User‐Centric Perspective: Validation testing is
conducted from the perspective of the end‐users or
customers who will be using the software in real‐world
scenarios.
 Business Requirements: Testers evaluate the software
against the documented business requirements and
user expectations to ensure that it meets the desired
functionality.

215
 Functional and Non‐functional Aspects: Validation
testing assesses both functional aspects, such as
features and workflows, and non‐functional aspects,
like performance, security, and usability.
 Final Phase of Testing: Validation testing is usually the
last phase of testing before the software is released to
production or delivered to the end‐users.
Types of Validation Testing:
 User Acceptance Testing (UAT): UAT involves end‐users
or representatives from the client or customer side
testing the software to ensure it meets their needs and
requirements. It serves as the final sign‐off before
deployment.
 Alpha Testing: Alpha testing is conducted by the
internal development team in a controlled environment
to identify defects and issues before external testing.
 Beta Testing: Beta testing involves releasing the
software to a select group of external users to collect
feedback and uncover any remaining issues before the
official release.
 Regression Testing during Validation: During validation
testing, regression testing may also be performed to
ensure that the software's existing functionalities are
not adversely affected by recent changes or updates.
Validation Testing Process:
 Requirement Analysis: Understanding and analyzing
the software requirements is essential to ensure that
validation testing aligns with the intended functionality.

216
 Test Planning: A detailed test plan is created, outlining
the scope, objectives, test scenarios, test cases, test
data, and resources needed for validation testing.
 Test Case Design: Testers design test cases based on the
documented business requirements and user
expectations. Test cases focus on real‐world usage
scenarios.
 Test Execution: Testers execute the test cases,
recording actual results and comparing them against
expected results.
 Defect Reporting and Resolution: If any discrepancies
or defects are found, they are recorded in a bug tracking
system and resolved by the development team.
 User Feedback and Acceptance: During UAT, end‐users
provide feedback on the software's usability,
functionality, and overall performance. Acceptance
criteria are evaluated to determine whether the
software is ready for release.
Benefits of Validation Testing:
 Customer Satisfaction: By validating that the software
meets customer requirements, validation testing
ensures higher customer satisfaction.
 Early Detection of Defects: Validation testing helps
catch any discrepancies early in the software
development life cycle, allowing for prompt resolution.
 Reduced Business Risks: Ensuring that the software
aligns with business needs reduces the risk of costly
post‐release fixes and potential business losses.

217
CHAPTER 4.5. SYSTEM TESTING
System testing is a critical phase in the software testing
process that evaluates the complete and integrated
software system to ensure it meets the specified
requirements and functions as expected. This testing phase
assesses the entire software application, verifying its
behavior in a real‐world environment and validating its
compliance with both functional and non‐functional
requirements.
Key Objectives of System Testing:
 Functional Validation: System testing ensures that all
individual components and modules of the software
interact correctly when integrated, allowing the entire
system to function seamlessly.

 End‐to‐End Scenarios: It verifies that end‐to‐end

scenarios and workflows, spanning multiple modules,
are correctly implemented and produce the expected
outcomes.
 Non‐functional Testing: System testing also includes
testing for non‐functional aspects such as performance,
security, reliability, and scalability to ensure the
software meets desired performance levels.
 Compatibility Testing: It ensures that the software
functions properly across different platforms, browsers,
devices, and network environments.
Key Aspects of System Testing:

218
 Integration of Components: System testing involves
integrating all individual components of the software to
evaluate how they work together.
 Test Environment: It requires a stable and
representative test environment that closely resembles
the production environment to ensure accurate testing
results.
 End‐to‐End Scenarios: System testing focuses on testing
complete business scenarios that reflect real‐world user
interactions.
 Defect Management: Any defects identified during
system testing are recorded, reported, and managed in
a bug tracking system.
Types of System Testing:
 Functional Testing: This aspect ensures that the
software performs all its intended functions correctly,
adhering to the specified requirements.
 Usability Testing: System testing assesses the user‐
friendliness of the software, ensuring it provides an
intuitive and efficient user experience.
 Performance Testing: This aspect evaluates the
software's performance under various conditions,
including load testing, stress testing, and scalability
testing.
 Security Testing: System testing includes security
testing to identify vulnerabilities and weaknesses in the
software's security measures.
 Compatibility Testing: It ensures that the software
works seamlessly across different platforms, browsers,
and devices.

219
 Regression Testing: System testing involves regression
testing to verify that new changes or updates do not
adversely affect existing functionalities.
System Testing Process:
 Test Planning: A comprehensive test plan is created,
defining the scope, objectives, resources, and schedule
for system testing.
 Test Case Design: Testers design test cases to cover all
functional and non‐functional aspects of the software.
 Test Execution: Testers execute the test cases in the
system environment, recording actual results and
comparing them against expected outcomes.
 Defect Reporting and Resolution: Any defects
identified during testing are recorded, reported, and
resolved by the development team.
 Retesting and Regression Testing: After defects are
fixed, retesting and regression testing are performed to
verify that the issues are resolved and no new problems
arise.
 Acceptance: Once all test cases are executed, and the
software meets the acceptance criteria, it is ready for
user acceptance testing (UAT) or final release.
Benefits of System Testing:
 Software Reliability: System testing ensures that the
software is reliable and performs as expected in a real‐
world environment.
 Early Issue Identification: Identifying and resolving
issues during system testing helps avoid costly and time‐
consuming problems later in the development process.

220
 User Satisfaction: By validating the entire system's
functionality, system testing contributes to improved
user satisfaction.
 Compliance: System testing ensures that the software
complies with the specified requirements and industry
standards.

221
CHAPTER 4.6. RISK MANAGEMENT IN
SOFTWARE ENGINEERING PROJECT
Introduction
Risk management is a systematic process of identifying,
analyzing, and addressing potential risks that could impact
the success of a project or an organization. In the context of
software development, risk management aims to
proactively identify and mitigate risks associated with a
software project to ensure its successful completion and
delivery. The primary goal of risk management is to reduce
the probability and impact of negative events while
maximizing opportunities for positive outcomes.
Key Steps in Risk Management:
 Risk Identification: The first step in risk
management is to identify potential risks that could affect
the project. Risks can be technical, operational, financial,
schedule‐related, or related to external factors.
 Risk Analysis: After identifying risks, they are
analyzed to assess their potential impact on the project's
objectives. The likelihood of the risk occurring and the
severity of its impact are evaluated.
 Risk Assessment: In this step, risks are prioritized
based on their potential impact and likelihood. High‐priority
risks that have a significant impact and high probability of
occurrence receive more attention in risk mitigation.
 Risk Mitigation: Risk mitigation involves developing
strategies and action plans to address identified risks. These

222
strategies may include risk avoidance, risk transfer, risk
reduction, or risk acceptance.
 Risk Monitoring: Once risk mitigation strategies are
implemented, the project team continuously monitors and
assesses the effectiveness of these strategies. New risks
may also emerge during the project, requiring ongoing risk
management.
Benefits of Risk Management:
 Early Issue Identification: Risk management helps
identify potential issues early in the project, allowing for
proactive planning and mitigation.
 Improved Decision Making: By understanding
potential risks and their impact, project stakeholders can
make informed decisions to ensure project success.
 Cost and Time Savings: Addressing risks before they
occur helps avoid costly delays and rework.
 Increased Stakeholder Confidence: Effective risk
management instills confidence in project stakeholders, as
they know potential risks are being managed proactively.
 Maximized Opportunities: Risk management also
involves identifying positive risks or opportunities that
could benefit the project. Exploiting these opportunities
can lead to project improvements and added value.
Risk Management in Software Development:
In the context of software development, risk management
focuses on risks that could affect the successful completion,
delivery, and quality of the software product. Common risks
in software development include:

223
 Technical Risks: Risks related to the complexity of
software development, technology selection, and
integration challenges.
 Requirements Risks: Unclear, incomplete, or
changing requirements can lead to project delays and scope
creep.
 Schedule Risks: Risks related to meeting project
timelines and deadlines.
 Resource Risks: Insufficient or misallocated
resources can impact project progress and quality.
 Security Risks: Risks associated with potential
vulnerabilities or threats to the security of the software.
 Vendor Risks: For projects involving third‐party
vendors or external dependencies, risks related to vendor
capabilities and reliability.

Risk management process:

The risk management process is a systematic approach to
identify, analyze, evaluate, and address potential risks that
could impact a project, organization, or any endeavor. It
involves a series of steps that help project stakeholders
make informed decisions to mitigate, transfer, avoid, or
accept risks. The risk management process is essential for
minimizing the impact of uncertainties and maximizing
opportunities for success. Below are the key steps involved
in the risk management process:

224
 Fig. 4 Risk Management Process
1. Risk Identification:
The first step in the risk management process is to identify
potential risks that could affect the project or organization.
This involves brainstorming sessions, reviewing historical
data, conducting interviews, and analyzing various project
aspects. Risks can be categorized as internal (within the
organization or project) or external (outside influences or
events).
2. Risk Analysis:
Once risks are identified, they are analyzed to understand
their characteristics and potential impacts. Risk analysis
involves assessing the probability of the risk occurring and
the severity of its impact on the project's objectives.
Qualitative and quantitative risk analysis techniques are
used to rank risks based on their priority.

225
3. Risk Assessment:
In this step, risks are prioritized based on their level of
significance and the potential consequences they may have
on the project. High‐priority risks, which have a high
probability of occurrence and significant impact, receive
more attention during risk mitigation.
4. Risk Response Planning:
After assessing risks, the project team develops strategies
and action plans to address each identified risk. There are
four primary risk response strategies:
Avoidance: Taking actions to eliminate the risk or change
project plans to avoid the occurrence of the risk.
Mitigation: Implementing actions to reduce the probability
or impact of the risk.
Transfer: Shifting the risk and its consequences to another
party, such as through insurance or outsourcing.
Acceptance: Acknowledging the risk without implementing
any specific response, typically used for risks with low
impact or probability.
5. Risk Monitoring and Control:
Risk monitoring is an ongoing process throughout the
project's lifecycle. It involves tracking identified risks,
evaluating the effectiveness of risk responses, and
identifying new risks that may arise during the project. The
project team reviews the risk management plan regularly
and implements necessary adjustments to address changes
in the risk landscape.

226
6. Risk Reporting and Communication:
Effective communication is crucial in risk management. The
project team and stakeholders need to be informed about
identified risks, their status, and the actions being taken to
manage them. Regular risk reporting ensures that all
stakeholders are aware of potential risks and the project's
risk exposure.
Benefits of the Risk Management Process:
The risk management process offers several benefits to
organizations and projects, including:
 Proactive Decision Making: Risk management allows
stakeholders to make informed decisions and take
proactive actions to address potential issues before
they escalate.
 Resource Optimization: By identifying risks early,
resources can be allocated efficiently to mitigate or
respond to potential issues.
 Improved Project Success: Effective risk management
contributes to increased project success rates by
minimizing the impact of uncertainties.
 Cost and Time Savings: Addressing risks before they
occur helps avoid costly delays and rework.
 Stakeholder Confidence: Effective risk management
instills confidence in project stakeholders, as they know
potential risks are being actively managed.

RISK PREDICTION:
Risk prediction, also known as risk estimation, estimates the
impact of risks on the project and the product. This

227
estimation is done using a risk table that addresses risk in
terms of categories, probability, impact, and risk mitigation
measures.
Risk prediction involves the following steps:
 Estimate the probability (li) that the risk will occur.
 Estimate the consequences (xi) of the risk occurrence.
 Estimate the impact of the risk.
 Draw the risk table
Risk refinement:

Risk refinement, also called risk assessment, involves

reviewing the risk impact based on three factors ‐ nature,
scope, and timing. it refines the risk table to determine the
risk exposure (re) using the formula re = p * c, where p is
the probability and c is the cost of the project if the risk
occurs.
Risk mitigation, monitoring, and management (RMMM):
The goal of RMMM is to assist the project team in
developing a strategy for dealing with risks. it comprises
three main components:

Risk avoidance: this involves identifying and removing the

causes of risks to prevent their occurrence.
Risk monitoring: this activity ensures that predicted risks
are being properly addressed and data is collected for
future risk analysis.

228
Risk Management: this includes contingency planning and
actions to be taken if risk mitigation efforts fail and the risk
becomes a reality.
Risk management and planning are based on the
assumption that the mitigation effort may fail and the risk
may become a reality. in such cases, the project manager
takes responsibility for managing the risks and
implementing the risk mitigation monitoring and
management plan (RMMP). The risk register is a key
objective of the risk management plan, which identifies and
prioritizes potential risks to a software project.

the RMMM plan documents all work performed during risk

analysis, and each risk is documented individually using a
risk information sheet (RIS). The RIS is maintained in a
database system for effective risk management.

Risk management is a crucial aspect of software

engineering projects, involving the identification,
estimation, and mitigation of potential risks to ensure the
successful execution of the project and the delivery of a
high‐quality software product.

229
CHAPTER 4.7. PROJECT PLANNING ESTIMATION
Introduction
Project planning estimation is the process of predicting the
resources, time, and costs required to complete a project
successfully. It is a critical phase in project management, as
accurate estimations are essential for creating realistic
project schedules, allocating resources, and setting
expectations for stakeholders. The primary goal of project
planning estimation is to provide a roadmap for the
project's execution, ensuring that it stays on track and
meets its objectives within the allocated constraints.
Key Aspects of Project Planning Estimation:
 Scope Definition: Before estimation can begin, a clear
and well‐defined project scope must be established.
The scope outlines the project's deliverables,
objectives, and boundaries, providing a foundation for
the estimation process.
 Work Breakdown Structure (WBS): The project is
broken down into smaller, manageable components
called work packages in the WBS. Each work package
represents a specific task or activity that requires
estimation.
 Estimation Techniques: Various estimation techniques
are used, such as expert judgment, analogous
estimation (using historical data from similar projects),
parametric estimation (using mathematical models),
and three‐point estimation (using optimistic,
pessimistic, and most likely scenarios).

230
 Estimation Inputs: Estimation relies on several inputs,
including historical data, team expertise, resource
availability, and project constraints.
 Estimation Units: Estimations can be made for various
project aspects, such as effort estimation (person‐hours
or person‐days), duration estimation (calendar time),
and cost estimation (monetary value).
 Contingency Planning: Estimations are often
accompanied by contingency plans to account for
uncertainties and risks that may impact the project's
schedule, resources, or costs.
Challenges in Project Planning Estimation:
 Uncertainty: Projects are inherently uncertain, and
unforeseen events can lead to deviations from initial
estimations.
 Incomplete Information: In the early stages of a project,
detailed information may not be available, making
accurate estimations challenging.
 Changing Requirements: If project requirements
change during the course of the project, estimations
may need to be adjusted accordingly.
 Human Bias: Estimations can be influenced by biases or
unrealistic optimism, leading to over‐ or
underestimation of project efforts.
Importance of Accurate Estimation:
 Resource Allocation: Accurate estimations help in
allocating the right resources, including human
resources, equipment, and materials, for the project.

231
CHAPTER 1 to 6 - TERMINAL QUESTIONS:
1. Define Software. List out the Characteristics of S/W.
2. Explain in detail about various Software Application
Domains with examples.?
2. Define Software Process. What are the steps involved in
Software Process and explain.
3. Brief down the need of Umbrella Activities in software
process. And explain the phases of Umbrella Activities
in software process.
4. Summarize the different types of Software Myths.
5. Define Perspective process model. Describe various
process models with neat sketch.
6. Describe various Specialized process model with
diagrams.
7. Explain the importance of Unified Process model.
8. Various Challenges in Formal Methods Model.
9. Differentiate PSP and TSP
10. Explain the main objectives of reverse engineering and
provide examples of how it is applied in different
industries.
11. Describe the steps involved in conducting a reverse
engineering analysis of a software application without
access to its original source code.

CHAPTER 7 to 12 TERMINAL QUESTIONS:

1. Difference between Functional Requirements and Non-
Functional Requirements.
2. Define Requirements elicitation. Describe various
methods in requirements elicitation.
3. How can you ensure that business requirements are
documented accurately?
4. What techniques can be used to prioritize business
requirements during the documentation process?
5. How can traceability between requirements and other
project artifacts be maintained?

232
6. Define Requirement. How to identify User
requirements. List out types of requirements.
7. What are the key steps involved in the requirements
change management process?
8. Outline and explain different types of software reviews?
9. Rephrase and summarize about the walkthrough in
software development?
10. Analyze and summarize the key benefits of software
inspections.
11. Define Agile Modelling and Extreme Programming
(XP) in your own words.
12. List three key principles of Agile Modelling and explain
their significance in software development.
13. Identify the primary goals of Extreme Programming
(XP) and how they contribute to delivering high-quality
software.
14. Describe how Agile Modelling promotes adaptability
and customer collaboration in the software development
process.
15. Explain the concept of Test-Driven Development (TDD)
in Extreme Programming (XP) and how it ensures
reliable code.
16. Compare the iterative nature of Agile Modelling with the
incremental approach of Extreme Programming (XP).

CHAPTER 13 - 19 TERMINAL QUESTIONS:

1. What do you mean by Agile or Agile Methodology or Agile
Process?
2. What are the different types of Agile Methodology?
3. What is the difference between Agile, Scrum and SAFe.
4. Describe how Jira is useful for project management.
5. What are the key advantages of using Kanban over
other project management methodologies like Scrum or
Agile?

233
6. How effective is Kanban for software development
projects, particularly in terms of improving development
speed and reducing lead times?
7. Name the four levels of the latest version of SAFe.
8. What are the key features of the Kanban tool you are
using, and how do they help visualize and manage your
team's workflow effectively?
9. Can you explain how the Scrum tool facilitates Sprint
planning and backlog management? How does it assist
in organizing and prioritizing tasks for each iteration?
10. How does the Kanban tool handle Work in Progress
(WIP) limits, and how has it helped your team maintain
a balanced workflow while preventing overloading of
tasks?
11. Define design pattern. What are Characteristics of design
pattern?
12. Explain different types of architectural patterns?
13. Define Model Driven Architecture. And how is it
different from other architectures.
14. List and explain the key Principles of Model-Driven
Architecture

CHAPTER 20 - 26 TERMINAL QUESTIONS:

1. Define Software testing. List the various strategies
issues.
2. Why Unit testing plays a vital role in software
testing.How stub is different from driver.?
3. List the advantages of regression testing.?
4. What is the main objective of test strategies for
conventional software development?
5. Briefly explain the concept of risk-based testing and its
importance in conventional software testing.
6. Compare and contrast scripted testing and exploratory
testing in the context of conventional software projects.

234
7. How does test automation benefit conventional software
testing, and what are the key challenges associated with
it?
8. Why is performance testing crucial for conventional
software projects, and what aspects does it typically
evaluate?
9. List out various System testing methods with suitable
examples. What are the key steps involved in effective
risk management for software engineering projects?
10. Describe each step and explain their significance in
ensuring project success.
11. How can risk management be integrated into the
software development lifecycle? Discuss how risk
management activities can be aligned with different
phases of the project, from requirements gathering to
deployment and maintenance.
12. What methodologies or techniques do you use for project
estimation (e.g., bottom-up, top-down, analogous,
parametric, etc.)? Are you aware of the strengths and
weaknesses of each approach?
13. How do you identify and account for potential risks that
could impact the project's timeline and scope during
estimation?

235