1

MODULE 1

INTRODUCTION TO SOFTWARE ENGINEERING

1.1 Introduction
* As the importance of software has risen, millions of computer programmes have
been developed and will need to be fixed, changed, and enhanced. Nobody could
have predicted that these upkeep tasks would use up more time and energy than
developing brand new software. Therefore, people in the software industry have
been hard at work creating tools that make it easier, faster, and cheaper to build and
maintain high-quality computer programmes. However, the software community has
not yet succeeded in developing a single technology that can accomplish all of these
goals. Therefore, in order for us to accomplish this, we require a framework that
includes a procedure, a group of procedures, and a variety of instruments. The term
"Software Engineering" refers to this particular framework.

1.2 The Evolving Role of Software

* Today software takes a dual role
=> As a Product
=> A vehicle for delivering a product
(1) As a Product:
• Hardware local connection to a network of computers makes available the processing
power already present in the hardware.
• A programme is an information transformer if it produces, manages, acquires,
modifies, or transfers information; this is true whether the programme is in a mobile
phone or a supercomputer.
(2) A vehicle for delivering a product:
* Software provides one of the most important products of our time, information,
by doing things like:
=> It transforms personnel data [for example, an individual financial transaction]
=> It manages business information to improve competitiveness
=> It serves as a gateway to global information networks [for example, the
internet]
=>It provides a means of acquiring information in all of its forms
 2

* Software provides one of the most significant products of our day, information,
by doing things like:
=> It changes personnel data [for example, an individual financial
transaction]
=> It handles business

1.3 Adaptation of Software Engineering Practices:

* Extraordinary advances in hardware performance,
=> deep changes in computing design,
=> vast increases in memory and storage capacity,
=> exotic input and output possibilities

• All of these factors have contributed to the evolution of increasingly complex and
sophisticated computer-based systems.
• Sophistication and complexity yield desirable outcomes if the system works as
intended, but can pose serious challenges if the opposite is true.
• Large software companies now employ entire groups of specialists, each of whom
works on a specific aspect of the technology needed to complete a single application.
• The inquiries made of the lone programmer are identical to those made throughout the
development of contemporary computer systems.

They are,
(1) What factors contribute to the protracted time required to finish software?
(2) What aspects of development add to the staggering costs?
(3) Why is it that we are unable to detect all of the faults in the software before
releasing it to our clients?
(4) Why do we put forth a lot of time and energy to keep the programmes that are
currently in place going?

(5) Why do we still struggle to accurately measure the amount of progress made
when the software is being built and maintained?
 3

• The fact that these inquiries are being made demonstrates that businesses are
worried about software and its creation process. • This worry has prompted the
growth of software engineering practices.

1.4 Software:
Definition:
“ It is a set of instruction that when executed provide desired features, functions
and performance”
(Or)
“ It is a data structure that enable the programs to adequately manipulate
information”
(Or)
“ It is a documents that describe the operation and use of programs”

1.5 Software Characteristics:

The following are some ways in which software features differ from hardware
ones: (1) Software is not produced in the conventional sense; rather, it is developed
(or engineered).
(2) In both software and hardware production, high quality is accomplished
through good design.
(3) Whereas software rarely has quality issues, hardware often does
throughout the production phase.
(4) Although human beings are essential to the success of both endeavours,
the correlation between manpower and output is very different.
5) In both cases, something must be built.
(6) There is an investment of time and energy in both

(2) Software doesn’t “wear out”

Once problems are addressed, the failure rate stabilises for a while.
 4

Dust, Vibration, Abuse, Extreme Temperatures, and Time all add up to shorten the
lifespan of hardware components.
This leads to an increase in the failure rate; alternatively, the hardware "wears out." The
"Bathtub Curve" below illustrates this point.

“Infant “Wear Out”

Mortality”
Failure
Rate

Time

* The failure rate curve for software should take the form of a "idealised curve," as it is
not affected by environmental conditions in any way.

Increased Failure rate due

 5

to Side Effects

Failure
Rate
Actual Curve
Change

Idealized Curve
* In the beginning stages of a program's life, significant failure rates are caused by
Time
mistakes that have not yet been found.
* The curve will become flatter once these faults have been rectified (provided that no
new flaws are introduced).
Therefore, it is abundantly evident that:
• Software undergoes deterioration rather than complete obsolescence;
modifications occur throughout its lifespan; and the implementation of changes
introduces errors.
• In order for the curve to revert back to its initial steady state failure, an additional
modification is requested that induces another surge in the curve, thereby
escalating the failure rate. Consequently, this degradation impacts the software's
quality.
• Hardware components are replaceable with spare parts when they fail; however,
software components are not replaceable. This distinction renders software
maintenance a more challenging endeavour. • Hardware maintenance is less
complex in comparison to software maintenance.

(3) Although the industry is moving toward component – based construction, most
software continues to be custom built
Component reuse is a natural element of the engineering process in the world of
hardware, but in the world of software, it has to be performed on a large scale to be
effective.
 6

* It is recommended to build and develop a reusable software component that may be

utilized in a variety of different programmes.
Example:
Present-day user interfaces are constructed using reusable components, which facilitate
the following:
=> Window creation;
=> Pull-down menus; and
=> An extensive range of interaction mechanisms.

1.6 The Changing nature of Software

* There are seven primary classifications of computer software, each of which presents
its own unique set of obstacles to software developers.
(1) System Software: It is a collection of programmes that were written in order to
provide support for other programmes.
=> Some pieces of system software process information structures that are complex yet
determinable, whereas other pieces of system software process data that is mostly
undetermined.
As an example: Compilers, editors, and utilities for managing and organizing files

Characteristics:
=> Extensive connection with computer hardware
=> Prolonged and intensive use by a number of individuals
=> Structures of data that are complex
= Multiple connections to the outside world
=> Working in parallel at the same time

(2) Application Software:

* It is a self-contained application that caters to a particular organizational requirement. *
This piece of software can be used for either business or technical decision making. In
addition to this, it can be used to exercise real-time control over the operations of a
corporation. Here's an example:
=> Processing of sales transactions at the point of sale
 7

=> Real-time monitoring and management of the production process

(3) Engineering / Scientific Software:

Several applications utilise this software, including but not limited to
• astronomy,
• molecular biology, and a • utomated
manufacturing.

Contemporary scientific and engineering applications are increasingly diverging from

conventional numerical algorithms.
Aspects of system simulation, computer-aided design, and other interactive applications
have begun to incorporate real-time functionality.
(4) Embedded Software:
* This software is incorporated into a product.
* This software is integrated into a system. It is employed to execute and regulate
functionalities and features for both the system and the end user. For example:

=> A microwave oven's keypad control corresponds to a variety of digital functions found
in automobiles, including the gas lever and dashboard.
=> Such components as displays and the braking system are encompassed.

(5) Product-line Software:

* It is intended to give a certain competence, which may then be utilised by a wide
variety of consumers.
* This software addresses both the general consumer market as well as the more
specialized niche markets.
Here's an example:
=> Word processing
=> Spreadsheets
=> Presentation software Computer Graphics
=>Multimedia, Entertainment, and Other Things, etc.
 8

(6) Web Applications:

* The software's uses are extremely varied.
* Web applications are transforming into complex computing environments that
incorporate corporate database and business application in addition to providing end
users with stand-alone features, computing capabilities, and content.

(7) Artificial Intelligence Software:

* This piece of software employs methods that are not numerical in nature in order to
solve difficult situations. Applications that fall under this category include:
1) Robotics;
2) Expert Systems; 3) Pattern Recognition; and
4) Pattern Recognition.
The demonstration of theorems and the practise of games
************************************************************************
Note:
Legacy Software’s:
* Decades have passed since the development of this software system [i.e., older
programmes], and it has been continuously updated to accommodate shifting business
requirements and computing platforms.
* Such system proliferation causes headaches for large organisations due to the high cost
of maintenance and the inherent risk associated with their evolution.

***********************************************************************
*
1.7 Software Myths:
* Beliefs about software
* The procedure used to build it, which can be traced back to the earliest days of
computers
* The myth – has a number of characteristics that have contributed to them becoming
insidious [i.e. proceeding inconspicuously but harmfully]
* For example, myths give the impression of being factual claims that are rational [and
sometimes do contain aspects of truth].
 9

(1) Management Myths:

* Managers in most fields are frequently under pressure to keep budgets in check,
prevent schedules from falling behind, and enhance quality
* Software managers frequently cling to the assumption that certain software myths are
true in the hopes that this will reduce the amount of pressure they are under.
Myth 1:
There is already a book in our possession that is loaded with guidelines and processes
for the construction of software....Won't that provide the information that my people
require to make informed decisions?
Reality:
=> The book of standards might very well exist ......However, is it put to use?
=> Are those who work in the software industry aware of its existence?
=> Does it adhere to the practices of contemporary software engineering?
=> Does it have everything? Is it amenable to change?
=> Is it possible to streamline it in order to shorten the amount of time it takes to provide
while still concentrating on the quality?
* The answer to each of these questions will most likely be "No" in the majority of
instances.
Myth 2:
If we fall behind schedule, we have the ability to add more programmers and make up
the time [this strategy is sometimes referred to as the "Mongolian Horde Concept"].
Reality:
* Adding personnel to a software project that has already been delayed results in the
project being further behind schedule.
* By educating the newly added members, the time allocated for productive
development is diminished.
* While it is possible to add personnel, it is crucial that such additions are conducted in a
methodical and coordinated fashion.
Myth 3: By delegating the software development to a third-party firm, I can simply
sit back and unwind while the project is executed.
Reality:
Failure to comprehend internal software project management and control will inevitably
result in difficulties for an organisation when it attempts to outsource software projects.
 10

(2) Customer Myths:

The clientele requesting computer software might consist of,"

=> A person"
=> An technical crew
=> A sales or marketing department (Or)
=> an external provider
Customer misconceptions regarding software are common.
* Myths result in erroneous anticipations (on the part of the clientele) and, ultimately,
developer discontentment

Myth 1:
It suffices to commence programme writing with a broad statement of objectives.
The details can be completed later.
Reality:
• A statement that is equivocal, or has two meanings, gives rise to a multitude of
complications.
• However, unambiguous statements can only be generated via consistent and
efficient communication between the client and the developer.
• Consequently, it is not always feasible to formulate statements of requirements
that are exhaustive and consistent.
Myth 2:

Project requirements are subject to constant evolution; however, modifications can

be readily integrated due to the adaptable nature of software.
Reality:
• Early requests for requirements modifications, prior to the commencement of
design or code, result in a comparatively minimal cost impact.
• Requests for requirement modifications made after design (or code) has
commenced have an excessively high cost impact.
 11

• The proposed change has the potential to induce disruption, such as violent
change or disturbance, which may necessitate the allocation of supplementary
resources and substantial modifications to the design.

(3) Practitioners Myths

Myth 1:
After completing the program's development and testing, our work is complete.
Reality:
* According to industry data, between sixty and eighty percent of all software
development efforts will be repeated subsequent to the initial delivery of the product
to the client.
Myth 2:
Before the programme is operational, it is impossible for me to evaluate its quality.
Reality:
* Implement one of the effective software quality mechanisms during the project's
inception.
Software quality evaluations exhibit greater efficacy in identifying specific categories of
software errors when compared to testing.
Myth 3:
The working programme is the sole deliverable work product that ensures a
successful undertaking.
Reality:
Work programmes are components of software configuration, which comprises a
multitude of elements.
However, documentation merely serves as a cornerstone for effective software
engineering and support.
Myth 4:
Inevitably, software engineering will force us to generate copious amounts of
superfluous documentation, which will impede our progress.

Reality:
Software engineering focuses on producing high-quality software rather than mere
document creation.
 12

Thus, improved quality results in decreased rework.

* Decreased rework results in expedited delivery
In closing,
The fact that numerous software professionals acknowledge the fallacy (erroneous belief)
of software myths will indirectly contribute to the propagation of ineffective management
and technical practices.
However, acknowledging the realities of software is the initial stride in developing
pragmatic resolutions for software engineering.

A GENERIC VIEW OF PROCESS

1.8 Software Engineering – A Layered Technology:

(i) Quality Focus:

* Every engineering approach, software engineering included, must be founded upon an
organisational dedication to quality. Total quality management facilitates ongoing process
improvement, which in turn fosters the creation of efficient software engineering
 13

methodologies. A quality-oriented approach serves as the foundation that bolsters

software engineering.
(ii) Process:
The process layer serves as the cornerstone of software engineering, facilitating the
logical and expeditious development of computer software by acting as a cohesive agent
between the technology layers.
It establishes a framework that is necessary for the following:
=> Effective delivery of software engineering technology
* The software process serves as the foundation for management control.
It provides the framework within which

=> Technical methods are applied

=> Work products are produced [i.e. models, documents, data,

reports, forms etc..]

=> Milestones are established

=> Quality is ensured and change is probably managed

(iii) Methods:
The document encompasses a wide range of tasks, which comprise:
=> Communication
=> Requirement analysis
=> Design modeling
=> Program Construction
=> Testing and support *
It depends on a set of basic principles that
=> Govern each area of the technology
=> Include modeling activities and other descriptive techniques
(iv) Tools:
* It offers automated or partially automated assistance for the procedures and processes.
* When tools are incorporated, data generated by one tool becomes accessible to another.

1.9 A Process Framework:

 14

* It finds a small set of framework tasks that can be used on all software projects, no
matter how big or complicated they are.
*The process framework has a group of tasks that can be used throughout the whole
software development process.
Framework Activity:
* It has a set of software engineering actions [a group of related jobs that come together
to make a big piece of software engineering work].
Design is an action in software engineering.
Each action has its own set of tasks that need to be done. These tasks do some of the
work that the action implies.
 15

A Process Framework

1.10 Generic Framework Activities:

(1) Communication:
 16

Constant interaction and cooperation with the client is required, as well as the gathering
of requirements and other relevant tasks.
(2) Planning:
 17

*
It describes the

=> Technical tasks to be conducted

=> The risks that are expected

=> Resources that will be required

=> Work products to be produced

=> Work Schedule
(3) Modeling:
It explains how to build models that help both developers and clients visualise and discuss
software's desired features and functionality.
(4) Construction:
* It combines

=> Code generation [either manual (Or) automated]

=> Testing [Required uncovering errors in the code]

(5) Deployment:
* The customer receives the software and evaluates it.
The customer then gives feedback based on the evaluation.
These general framework tasks can be used during the

=> Development of small programs

=> Creation of large web applications
=> Engineering of large complex computer based systems *The
way the software is made is different each time, but the tasks that make up the framework
stay the same.
1.11 Umbrella Activities:
(1) Software project tracking and control:
* Let the software team make work on the project plan. If you need to, take steps to stay on
schedule.
(2) Risk Management:
*Look for risks that could affect how the job turns out or the quality of the product.
(3) Software quality assurance:
 18

*
*It lists and carries out the tasks needed to make sure the quality of software
(4) Formal Technical Reviews:
* Get rid of any mistakes that you find before moving on to the next action (Or)
activity.
(5) Measurements:
To aid the team in delivering software, it specifies and collects process, project, and
product measures, and it can be used in conjunction with other frameworks and
overarching tasks.
(6) Software configuration management:
Effectively handles change impact management for software development.
(7) Reusability management:
* It sets up a way to make parts that can be used again and again.
* It sets rules for reusing work products.
(8) Work product preparation and production:
* It includes the things that need to be done to make work goods, like
=> Models
=> Documents
=> Logs, forms and lists
 19

PROCESS MODELS
2.0 Process Models – Definition
* It's a separate collection of things you have to do, accomplish, and produce in order to
create high-quality software.
* While not flawless, these process models do provide a helpful framework for software
engineering projects.

2.1 THE WATER FALL MODEL

The term "classic life cycle" is occasionally used to describe it.
It recommends a methodical and sequential approach to software development, starting
with a detailed specification of the needs of the end user and continuing all the way
through

=> Planning
=> Modeling
=> Construction and
=> Deployment
Problems encountered in waterfall model:
(1) In practise, projects rarely progress in a linear fashion. Consequently, the team's
progress is muddled by the constant stream of changes.
(2) The consumer often has trouble articulating their needs in detail;
(3) The customer must be patient

* Because of the sequential structure of the water fall model, "Blocking State" occurs when
certain members of the project team must wait for others to finish dependent tasks. * In
certain contexts, the water-fall model can be utilized effectively as a model for the
process.
=> Requirements are fixed and work is to proceed to completion in a
linear manner
 20

2.2 INCREMENTAL PROCESS MODELS

* This model applies linear sequences in a staggered form as calendar time progresses *
This model combines aspects of the water fall model that are applied in an iterative
fashion
* The incremental model combines elements of the water fall model
* Each linear sequence results in the production of software "increments" that can be
delivered.
Main Point:
* The initial iteration of an incremental model is referred to as the "CORE PRODUCT"
when the model is used.
 21

meaning that the fundamental needs have been met, but the primary extra features have
not been given
* Either the fundamental product is put through extensive testing by the customer, or the
customer uses it.
* As a direct outcome of the evaluation, a strategy for the subsequent increment is
prepared.

=> Communication

=> Planning

=> Modeling {Analysis, Design}

=> Construction {Code, Test}

=> Deployment {Delivery, Feedback}

Unlike the prototyping model, which prioritises the delivery of a functional product with
each increment, the incremental model focuses on the delivery of an operational product
with each increment, ensuring that the product fully meets the needs of the customer
before it is considered complete.
 22

*
In contrast to the prototype methodology, the incremental model focuses on adapting the
original product to new circumstances.
* When personnel is unavailable for a comprehensive implementation by the business
deadline that has been imposed for the project, this strategy is particularly effective. * It
is possible to implement early increments with a smaller number of individuals. In the
event that the core product is favourably received, extra personnel may be added in order
to implement the subsequent increase. It is possible to plan for increments in order to
mitigate technological risks.
* For instance, the production of a significant quantity of brand new hardware is now
underway, although the exact date of its release is unknown.
* Therefore, it is important to arrange early increments in a way that prevents the use of
this hardware. This will make it possible for end-users to receive partial functionality
without an excessive amount of delay.

AN AGILE VIEW OF PROCESS

Agile software engineering is a methodology that fosters both the early incremental creation
of software and the pleasure of customers.
Software engineers and other project stakeholders, such as managers, end-users, and
consumers, collaborate as part of an agile team. This means that the team is responsible
for its own organisation and is in charge of its own fate.
The members of an agile team are better able to communicate with one another and work
together more quickly.
• Agile software engineering is an acceptable alternative to conventional software
engineering for certain categories of software and certain types of software projects.
This is because agile software engineering prioritises collaboration and iterative
development.
• Customers and Software Engineers that have accepted the agile concept share the
same point of view, which is that the only really important work product is an
Operational "Software increment" that is provided to the customer on or before the
appropriate commitment date.
• If the agile team comes to the conclusion that the process is successful and the team is
able to produce increments of software that the customer finds satisfactory.
 23

What Is Agility ?
• Modifications to the software under development, adjustments to team members,
modifications brought about by new technology, and modifications of any kind that
could
 24

affect the product they created or the project that develops the project are all instances of
the kinds of modifications to which an agile team can adapt in a way that is appropriate.
• An agile team is aware that software is created by people working in groups, and that
the success of the project depends on the abilities and talents of these people
cooperating.
• Agility encompasses more than just the ability to adapt quickly to change. In addition to
that, it incorporates the agile way of thinking.
What Is An Agile Process?
The bulk of software development projects are based on three key assumptions, and
an AGILE SOFTWARE PROCESS is characterised by the way it handles these
assumptions.
1. It is impossible to determine in advance which software requirements will
continue to be necessary and which will be replaced by new ones. It is similarly
challenging to anticipate how the priorities of a customer will shift as a project moves
forward.
2. The phases of design and production are frequently combined in the creation of
different kinds of software. i.e. It is recommended that both processes be carried out
simultaneously so that design models can be validated as they are being developed. It
is challenging to make an accurate estimate of the amount of design work that must
be completed before construction can be used to validate the design.
3. The phases of analysis, design, construction, and testing are not as predicable
as we would like them to be (based on the planning).

• Based on these three presumptions, we are able to assert that the process's success
resides in its adaptability (to rapidly shifting technical conditions and project
parameters).
• Flexibility is an absolute requirement for an agile process.
• The iterative approach to software development known as agile needs to change.
 25

• The agile team needs feedback from customers in order to achieve incremental goals.
• The iterative methodology enables the customer to frequently evaluate the software
increment, provide the software team with any necessary input, and have some say in
the process changes that are made to meet the feedback provided by the customer.

Those who wish to attain agility are required to adhere to the following 12 principles,
as defined by the Agile Alliance:

1. The earliest and most consistent delivery of useful software is our first and
foremost concern in order to fulfil the requirements of our customers.
2. Be prepared to modify plans in response to changing needs, particularly as
development progresses. Agile processes give the client a competitive edge by
allowing them to adapt to change.
3. Regularly deliver functional software, giving attention to completion in the least
amount of time. A few weeks or a few months could pass in this case.
4. Business experts and developers work together every day for the duration of the
project.
5. Focus on individuals with a strong sense of motivation. Have faith in their abilities
to do the task and give them the environment and assistance they need.
6. Direct, in-person communication is the most effective and beneficial means of
sharing information with other team members and members of a development
team.
7. The best measure of success is having software that functions as intended.
Using agile methodologies promotes sustainable development. The speed is
anticipated to be steady indefinitely, and sponsors, developers, and consumers should
all be able to maintain it.
9. You can improve agility by keeping an eye on sound design and technical
excellence.
Simplifying involves maximizing the amount of work that is not done, which is a key
element.
11. The best architectures, specifications, and designs are created by self-
organizing teams.
 26

12. On a regular basis, the team reflects on how it may become more efficient and
then adapts and changes its behavior to take those ideas into account.

AGIL E PROCESS MODELS

• Throughout the history of software engineering, there have been thousands of
abandoned process descriptions and methodologies, modeling approaches and
notations, tools, and technologies.
• With the advent of a large range of agile process models, all vying for acceptance
within the software development industry.
•There are numerous distinct process paradigms that can be referred to be "agile".
There are numerous similarities between these various methods. the
characteristics of each strategy that make them unique.
•All of the Agile models follow the principles of agility and the Manifesto for
Agile Software Development.
• EXTREME PROGRAMMING(XP)
• Extreme Programming, or XP for short, is a popular agile development process
that uses an object-oriented framework. Planning, designing, coding, and testing
are the four main framework tasks that are used to carry out a collection of
concepts and techniques.

PLANNING
• The creation of a collection of tales, also known as user stories, that outline the
features and functionalities required for the program to be developed is the first
step in the planning process.
• Each story, sometimes referred to as a "Use-Case," must be written by the
consumer and put on an index card.
• Based on the feature or function's overall business value, the customer assigns the
story a VALUE (priority).
• Following that, each tale is assessed by the XP team members, who then
determine its cost, which is expressed in terms of the weeks needed to complete it.
 27

• The customer will be asked to divide the story into manageable chunks and the
value and cost will be allocated to each story separately once more if the narrative
requires more than three weeks of development time.
•The author is free to write the new stories whenever they like.
•The XP team works with its customers to determine how to best arrange individual user stories
within the upcoming release, which is also referred to as the upcoming software increment. The
XP team makes this choice.
•The XP team will order the stories that will be developed in one of the following three ways
after a release date has been committed to:
1. Every story will be implemented immediately (in a matter of weeks).

2. The tasks related to the stories with the biggest possible impact will be finished
first and given a higher priority in the schedule.
3. The stories with the highest potential for failure will be placed to the front of the
schedule and implemented first.
 28

DESIGN
• The design of XP adheres to the "Keep it Simple" (KIS) approach. A less
complicated representation is preferable over a more complicated design.
• The design offers implementation assistance for a story exactly as it is stated;
nothing less and nothing more than that.
• XP promotes the utilization of CRC cards, which stand for "Class-Responsible
Collaboration." These cards identify and organize the object-oriented classes that
are pertinent to the currently active software increment.
• The only design work products that were generated as a result of the XP process
were the CRC cards.
• Refactoring, a building approach that doubles as a design technique, is
encouraged by the XP game mode.
• The term "REFACTORING" refers to a design process that is ongoing during the
construction of the system.

CODING
• According to the XP approach, once a team has finished working on the stories
and the preliminary design work, they should not move on to coding but rather
develop a set of unit tests that are included into the software increment that is
presently being worked on. The XP methodology proposes that once the team has
finished working on the stories and the preliminary design work, they should not
go on to work on coding.
• Once the unit test has been constructed, the developer will have a much easier
time focusing on the requirements that need to be met in order for the unit test to
be passed. • Once the programming has been completed, the code may be
instantly put through unit testing, which provides the developers with immediate
feedback.

• PAIR PROGRAMMING, XP recommends having two people cooperate on the

production of the story's code while working at the same computer work station.
These two people should be working together. This provides a means for
addressing issues in real time and checking the quality of work in real time while
it is being performed.
 29

EX: It's possible that one person will focus on the specifics of the coding for a segment of
the design while another looks over their shoulder to make sure the coding standards are
being adhered to.
• The created code will "FIT" into the larger framework of what the tale is about.
• The integration work is the duty of the pair programmers. This technique of
continuous integration helps to avoid problems with compatibility and interfacing,
and it creates a "SMOKE TESTING" environment, which helps to expose defects
at an earlier stage.
TESTING
• The newly developed unit tests ought to be put into practise by making use of a
framework that gives rise to the possibility of their being automated. When code
is modified in any way, this should encourage the use of a regression testing
technique.
• Integration and validation testing of the system can be performed on a daily basis
now that the unit tests have been arranged into a "Universal Testing suit." The XP
team receives a continuous indication of progress from it, and it also has the
potential to raise early warning signs if things start to deteriorate.
• XP acceptance tests, also known as customer tests, are tests that are specified by
the customer and concentrate on the overall features and functionality of the
system that are reviewed by the client.
• Acceptance tests are created from user stories after they have been incorporated
into a product release.
• Once the XP team has completed the delivery of the first release of the project,
they will compute PROJECT VELOCITY, which is the number of customer
stories that were implemented during the first release. After then, one may make
advantage of Project Velocity to
1. Contribute to the estimation of delivery dates and the release schedule for
subsequent versions and
2. Determine whether an over commitment has been made for all of the stories that
are part of the overall development project. In the event that an over commitment
takes place, either the substance of the release or the end-delivery dates will be
adjusted.
 30

• As the development process progresses, the client has the option of adding new
tales, altering the value of an existing narrative, splitting existing stories, or
removing existing stories. After then, the XP team reviews all of the releases that
are still to come and adjusts its plan accordingly.

SCRUM
SCRUM principles are consistent with the agile manifesto :
• Small working teams are organised to make the most of their communication,
minimise their overhead costs, and make the most of their opportunity to share
their knowledge.
• In order to "ensure the best product is produced," the process needs to be flexible
enough to accommodate both changes in technology and in business.
• The procedure results in frequent software increments "that can be inspected,
adjusted, tested, documented, and built upon."
• The work of development and the individuals who carry it out are separated "into
clean, low coupling partitions, or packets"
• As the product is being assembled, testing and documentation are carried out in a
continuous manner.
• The SCRUM methodology affords users the "flexibility to declare a product
'done' whenever it is necessary to do so."
• The SCRUM principles are utilised to direct the development activities that take
place within a process that also includes the activities of the following framework:
requirements, analysis, design, evolution, and delivery.
• Within each activity of the framework, work tasks take place according to a
pattern of processes known as Sprint.
• The work that is completed during a Sprint (the number of sprints necessary for
each framework activity will vary based on the complexity and scale of the
product) is suited to the problem that is currently being worked on. Additionally,
the SCRUM team defines the work and frequently modifies it in real time. The
following diagram outlines the general steps involved in the SCRUM process.
• SCRUM places an emphasis on the utilisation of a collection of "Software process
patterns," which have been demonstrated to be effective for projects that have
tight timeframes, fluctuating requirements, and high business criticality.
 31

• A group of different kinds of development work is outlined by each of these

process patterns.
• A prioritised list of project requirements or features that generate business value
for the customer is referred to as a backlog. At any time, additional items may be
added to the Backlog. The Backlog is evaluated by the product manager, who then
updates the priorities as necessary.
• Sprints are comprised of work units that must be completed within a specified
amount of time in order to fulfil a need that has been outlined in the Backlog.
During a Sprint, the items in the Backlog are frozen, which enables the members
of the team to operate in an environment that is both short-term and consistent.

• Scrum meetings are brief meetings that are held every day by the scrum team.
During the meeting, there are three important issues that are discussed, and each
member of the team provides an answer. o Since our previous gathering, what
have you been up to? o What kinds of challenges are you facing right now? o
What do you hope to have accomplished by the time we get together again as a
team?
 32

• The gathering is directed by a group leader known as a "Scrum master," who also
evaluates the contributions made by each individual. The team is able to identify
potential difficulties at the earliest possible stage thanks to the Scrum sessions.
• The regular meetings facilitate "knowledge socialization," which in turn
contributes to the development of a structure that allows the team to organise
itself.
• Demos - Deliver the software increment to the customer so that the customer can
showcase and evaluate the functionality that has been built. This allows the
customer to provide feedback on the functionality.
• The demonstration might not have all of the functionality that was anticipated, but
it should be possible to implement these features within the time constraint that
was set.

DYNAMIC SYSTEMS DEVELOPMENT METHOD(DSDM)

• An agile software development methodology called the DYNAMIC SYSTEMS
DEVELOPMENT METHOD (DSDM) provides a systematic framework for building
and managing systems that follow stringent deadlines. This is accomplished by applying
incremental prototyping in a project environment that is regulated. This is accomplished
by applying the agile software development methodology known as the DYNAMIC
SYSTEMS DEVELOPMENT METHOD (DSDM).
• One arrives at the DSDM principle by deriving it from the pareto concept.
• Much like XP, the DSDM employs an iterative software development process.
This allows for the delivery of 80% of an application in the same amount of time
as it takes to produce the full product. In each iteration, the DSDM methodology
adheres to the 80% rule, which states that only enough work is done to meet the
requirements of the next increment. The remaining work is finished at a later time
when more business requirements are discovered or modifications need to be
accommodated.
• The DSM consortium, which is an association of enterprises for some specific
purpose, is a global organization. This organization has devised an iterative
process model that is referred to as the DSM life cycle.
• The DSM life cycle outlines three distinct repeating cycles, which are preceded
by two more activities that are part of the life cycle.
 33

Feasibility study – In order to determine if an application is a good fit for the DSDM
process, it is necessary to first establish the fundamental business requirements and
constraints connected with the application.

Business Study – Establishes the functional and information requirements that must be
met in order for the application to be able to give value to the company, as well as
specifies the fundamental architecture of the application and outlines the needs that must
be met for the application to be maintainable.
Implementation – Installs the most recent software update available into the environment
in which it is now running. It is essential to keep in mind that
1) The increment might not be completely done, or
2) Changes might be required while the incremental is being implemented. Both of these
scenarios are crucial to keep in mind.
• DSDM and XP can be coupled to give a strategy that defines a stable process
model with the nuts and bolts practises (XP) that are used to construct software
increments.
This combination method is known as a combination approach.

AGILE MODELING(AM)
Software engineers often find themselves in the position of having to construct
massive, mission-critical systems for businesses.
Modelling the scope and complexity of such systems is necessary in order to achieve
the following goals:
1. ensuring that all stakeholders have a better understanding of what has to be
achieved.
2. The individuals who are responsible for finding a solution to the problem can
be divided up into groups that are more likely to be successful. And
3. The quality can be evaluated at each stage of the engineering and construction
processes for the system.

• Many other software engineering modelling methods and notations have been
suggested for use in the process of analysis and design; however, despite the major
 34

virtues of these methods, it has been found that they are difficult to implement and
demanding to maintain.
• The "Weight" of these modelling methodologies is a contributing factor to the
problem. When we refer to this, we are referring to the amount of notation that is
required, the degree of formalism that is advised, the complexity of the models for
larger projects, as well as the difficulty in sustaining the model as change occurs.

• The only methods that provide a sustainable benefit for larger projects are the
analysis and the design modelling.

• The AGILE MODELLING was implemented to make the projects

intellectually more manageable.
A description of the AGILE MODELLING (AM) is as follows:The acronym "AGILE
MODELLING" (AM) refers to a methodology that is based on practises and is used
to efficiently model and describe software-based systems. Agile modelling is a set of
concepts, ideals, and practises for modelling software that may be utilised in a
software development project in an efficient and unburdensome manner. These can be
utilised in the context of agile software development.

AM proposes a wide variety of "CORE" and "SUPPLIMENTARY" modelling

principles, which are what set AM apart from other modelling approaches.
Design with a clear end in mind A developer using AM should have a goal in mind
(such as "to communicate information to the customer") before commencing work on
the model. Once the purpose of the model has been established, both the form of
notation that will be applied to it and the level of detail that it must contain will
become more clear.
Make use of a variety of models. There is a wide variety of both models and notations
that can be utilized in the process of describing software. Only a small portion of the
whole is required for the majority of tasks.
Don't pack too much As the work on software engineering progresses, you should
only employ those models that will only deliver a value over the long run. Every
 35

piece of work that is preserved must be brought up to date whenever there is a

change.
The actual content is more essential than how it is represented. The audience that the
modelling is meant for should receive information from it. A model with correct
syntax and notation that does not transfer any information to the target audience is not
as valuable as one with incorrect syntax and notation that does not target audience at
all.
Be familiar with the models you generate and the tools you use to do so. Gain an
understanding of the techniques that are used to develop each model, as well as the
benefits and drawbacks of each model.
Adapt on a local level. The modelling strategy ought to be modified so that it caters to
the requirements of the agile team.

AGILE UNIFIED PROCESS

• Agile Unified Process follows a serial "in the large" and an iterative "in the small"
methodology.
• By utilising the traditional activities of the UP stages, which are "Inception,"
"Elaboration," "Construction," and "Transition," respectively.
• Iteration is used throughout each of the actions by the team in order to achieve
agility and to ensure that end users receive meaningful software increments as
quickly as feasible.
• The actions listed below are taken into consideration by this edition of the AUP:

• Modeling
• Implementation
• Testing
• Deployment
• Configuration and Project Management
• Environment Management

SPECIALIZED PROCESS MODELS :

 36

• These models are typically utilised if a specialised or narrowly defined method of

software engineering is selected as the strategy of choice.

Component-Based Development
1. 1. Research and analysis are conducted on the component-based products that are
currently available on the market for the application domain in question.
2. Problems with component integration are taken into consideration.
3. A software architecture that can accommodate the components is built.
4. The architecture incorporates the components into its structure.
5. Extensive testing is carried out to validate the correct operation of the component.
The use of a component-based development methodology results in increased
software reuse and reusability.
The Formal Methods Model
• Using formal techniques, you can describe, build, and validate a computer-based
system by employing a stringent mathematical language. This is made possible by
the use of formal methods.
• The creation of formal models now requires a significant amount of time and
money due to their complexity.
• Extensive training is necessary since only a small percentage of software
engineers have the appropriate experience to apply formal approaches.
• Customers who are not technically savvy will have a tough time understanding
how to use the models as a communication channel.

Aspect-Oriented Software Development

• Aspectual requirements are used to define the concerns that span across multiple
layers of the software architecture and have an effect on each.
• Aspect-oriented software development (AOSD) is a modern approach to software
engineering that offers a systematic and methodical approach for defining,
specifying, designing, and constructing aspects. It is alternatively referred to as
aspect-oriented programming (AOP) and aspect-oriented component engineering
(AOCE).
 37

• The process will incorporate features from both evolutionary and concurrent
process models.
• Aspect-oriented software development (AOSD) is an acronym that stands for
"aspect-oriented software development."
THE UNIFIED PROCESS
It's an effort to incorporate many of the finest practises of agile software development
while drawing on the strengths of traditional software process models.
The streamlined procedure highlights the significance of software architecture and directs
the architect's attention to where it's needed most.
=> Appropriate objectives
=> Clarity
=> Adaptability
=> Reusability
* It suggests at a process flow that is iterative and gradual, which creates the appearance
that evolution is taking place.
 38

Phases of the Unified Process:

(1) Inception Phase:
1) In this stage, you'll be communicating with customers and making plans at the same
time. One can determine the software's business needs by combining the two above;
2) The system's general layout is proposed; and
3) the project's iterative and incremental nature will be taken into account as the plan is
produced.
A use-case is a generic term for a description of a set of steps taken by an actor (whether
human or machine).
* Use-cases lay the groundwork for project planning and help define the scope of the
project.
(2) Elaboration Phase:
It improves and extends the initial use cases created during the inception stage.
It adds five more perspectives to the software's architectural representation:
 39

=> Use-case model

=> Analysis Model
=> Design Model
=> Implementation Model
=> Deployment Model
* The modification to the plan may be made at this time
(3) Construction Phase:
* The software building blocks that will make each use case usable by actual people are
created (or purchased) here.
* The code for the software contains all of its necessary and required features and
functions. Unit tests are developed and executed for individual components after their
implementation.

(4) Transition Phase:

During this stage, the software team can create all of the documentation it will need to
run well.
* In the Beta testing phase, the programme is made available to actual end users.
Feedback on reported issues and necessary tweaks comes directly from customers.
Methods of Assembly

(5) Production Phase:

* During these phase the
The infrastructure of the running environment is supported, and the software's continued
usage is monitored.
• Problem and enhancement reports are being reviewed as they are submitted.
 40

MODULE-2
REQUIREMENTS ENGINEERING
What is Requirement
Requirements engineering is the systematic procedure of determining the specific services
that a client demands from a system, as well as the limitations and conditions that govern
its operation and development. Requirements are the explicit descriptions of the services
and limitations of a system that are developed during the process of requirements
engineering.
Different types of Requirement Specification

Functional and non-functional requirements

• Functional requirements
Specifications describing the functions the system is expected to carry out, as well as
the expected responses to and actions in certain scenarios. Non-functional
requirements
• limitations imposed by the system on the services or capabilities it provides, such as
strict deadlines, difficult development processes, stringent quality controls, etc.

Domain requirements
Domain-specific requirements are system requirements that are derived from the
application domain and reflect the unique characteristics and functionalities of that domain.
 41

Functional requirements
• Specify the features and services of the system.
• Be contingent upon the nature of the software, its intended audience, and the nature
of the system on which it runs.
• The functional system requirements must be specific, in contrast to the functional
user requirements which might be more general descriptions of the system's
expected behaviour.
Requirements completeness and consistency
It is generally accepted that requirements should be exhaustive and uniform.
Complete
– All services required by the user should be defined.
Consistent
It is impossible to create a comprehensive and consistent requirements document in
practise, but it is essential that there be no inconsistencies or conflicts in the descriptions
of system facilities.

Non-functional requirements
• The requirements and characteristics of a system are defined by these factors. I/O
device limitations, system representations, and similar factors all serve as
constraints.
• Non-functional needs can be more crucial than functional requirements. If these
conditions are not fulfilled, the system becomes ineffective.
• The implementation of these needs may be spread out across the system. There are
two factors contributing to this:
• The non-functional requirements of a system may have more of an impact on the
system's architecture as a whole than on its individual components. To fulfil
performance criteria, for instance, you might have to organise the system in such a
way as to reduce the amount of communication that occurs between its various
components.
• It is possible for a single non-functional demand, such as a requirement for system
security, to spawn a number of related functional requirements that describe new
 42

system services that must be provided. Additionally, it is possible for it to produce

requirements that constrain requirements that are already in place.

Non-functional classifications
• Product requirements
• Prescriptions on how the delivered product must perform, including time to
completion, reliability, etc.
• Organisational requirements
• Company-specific requirements, such as those for meeting process standards,
meeting deadlines, etc., that are a direct outcome of the company's policies and
procedures.
• External requirements
- Requirements that are imposed on the system and its development process by elements
that are not directly related to the system itself, such as interoperability requirements,
legislative requirements, and so on.
 43

Metrics for specifying Non functional Requirements

The Software Requirements Document

A formal statement of what should be implemented by the system developers, the
software requirements document (also known as the software requirements specification
or SRS).
User needs and a thorough description of the system's specifications should both be
included.
• The precise system requirements may be presented in a different document if
there are several of them.
If you're having a third-party firm create your software, "requirements documents" are a
must.
• In Agile development where the requirements change fast, SRS gets out of date.
Therefore, Extreme Programming-style models gradually gather user needs.

Users of Requirements Document

 44

The structure of a requirements document

 45

Requirements specification
• An ideal requirements definition would result in user and system needs that are
crystal obvious, unambiguous, simple to grasp, exhaustive, consistent, and well-
organized into a requirements document.
• System users without extensive technical knowledge should be able to grasp the
user requirements for a system if they accurately represent the system's functional
and nonfunctional requirements.
• The system's external behaviour and operational restrictions should be simply
described in the requirements.
• They shouldn't worry about the system's design or implementation.
All design information must be included, and that's not doable. This is due to a
number of factors:
1. To better organise the requirements specification, you may need to create an
initial architecture of the system. Requirements are categorised by the several
subsystems that make up the whole.
2. Most systems need to communicate with one another, which might place
limitations on the design and additional demands on the new system.
 46

3. The usage of a specific architecture to satisfy non-functional criteria may be

necessary. If an outside authority has to verify the system's security, they can
insist on using a layout that has already been approved.

Ways of writing a system requirements specification

A structured specification of a requirement for an insulin pump

 47

Requirements Engineering Processes

Definition:
* The requirements definition and requirements specification are the end results of the
requirements engineering process. The software specification and reports on the system's
viability are also included.

There are four principal stages in this process:

Feasibility Study:
* It is estimated whether the identified user need can be met with current software and
hardware technology.
The study will also decide if the suggested system is cost-effective and if it can be built within
the current budget.
The result should help decide if a more in-depth study should be done or not.
A viability study shouldn't cost too much and shouldn't take too long.

Requirements Analysis:
 48

obtaining the system requirements by performing activities such as analysing tasks,

talking to possible users, evaluating existing systems, etc. The analyst gains a better
understanding of the system that needs to be detailed as a result of this. In order to
acquire a clearer picture of the requirements, system prototypes are often developed.
Requirements Definition:
The activity of transforming the information acquired during the analysis activity into a
document that describes a set of requirements is known as the requirements definition
activity.
* This document needs to be created in such a way that it can be comprehended by the
end-user as well as the system customer.
Requirements Specification:
The development of this document is conducted concurrently with the high-level design
process. Deficiencies in requirement specification are identified during the process of
document development, necessitating modifications to rectify these issues.
* A comprehensive and accurate specification of the system requirements is established,
serving as the foundation for the contractual agreement between the client and the software
developer.
* The system requirements statement serves as the foundation for the contractual
agreement between the client and the software developer.
Requirement Elicitation:
* It is a procedure that involves asking review questions with the client, the user, and
other people to inquire about
=> What the goal of the system is
.=> What exactly is it that has to be done?
=> How does the system accommodate the requirements of the organization?
=> What is the recommended way to use the product or the system on a day-to-day basis?
The requirements elicitation and analysis process
 49

The process activities are:

1. Requirements discovery This is the process of discovering the requirements of the
stakeholders of the system through interaction with those stakeholders. During the course
of this process, domain needs from the stakeholders and the documentation are also
found.
2. Requirements classification and organization This action takes the unstructured
collection of requirements and organises them into coherent clusters by grouping together
requirements that are connected to one another. Using a model of the system architecture
to identify sub-systems and to associate requirements with each sub-system is the most
popular method for grouping requirements. This is also the most effective method. In
actual practise, the processes of requirements engineering and architectural design simply
cannot be kept entirely apart from one another.
3. Requirements prioritization and negotiation When there are several stakeholders
involved, it is inevitable that their requirements may conflict with one another. Within the
scope of this activity are the processes of prioritising requirements, discovering conflicts
between requirements, and resolving those conflicts through negotiation. In most cases,
the parties involved are required to get together in order to reconcile their differences and
reach an agreement on the necessary concessions.
 50

4. Requirements specification The specifications are written down and included into the
subsequent iteration of the spiral. There is potential for the production of formal or
informal requirements documents. Viewpoints
• Viewpoints serve as a method for organizing requirements in order to accurately
represent the many perspectives of different stakeholders. Stakeholders can be
categorized based on several perspectives.
• A multi-perspective study is crucial because there is no definitive method for
analyzing system requirements. Types of viewpoint
• Interactor viewpoints
• Individuals or other entities that directly engage with the system. In an ATM, the
customer's information and the account database are interconnected virtual private
networks.
• Indirect viewpoints
• Individuals who are not directly involved in the system's operation but who have
an impact on its requirements. Both the management and the security staff at an
ATM are considered to be indirect opinions.
• Domain viewpoints
• The needs are influenced by the characteristics and constraints of the domain. In
the context of an Automated Teller Machine (ATM), an illustration would be the
protocols and guidelines governing the exchange of information between different
banks.
Interviewing
• During either a formal or a casual interview, the RE team will ask stakeholders
questions about the system that they currently use as well as the system that will
be constructed.
• There are two different kinds of interviews: closed interviews, in which
participants answer a series of questions that have been determined in advance,
and open interviews.

— Interviews with no set agenda, in which a wide variety of topics are discussed with
various stakeholders; these are open interviews.
 51

Scenarios
• Scenarios are real-life examples of how a system might be utilised. • Scenarios
should include the following: a description of the beginning situation; a
description of the goal of the scenario.

- A description of the typical order in which things occur;

- A discussion of the various things that could go wrong;
- Information regarding other activities taking place at the same time;
- A description of the situation that exists once the scenario has been completed.

Requirements checking
• <text>Validity.</text> <text>Does the system offer the functions that most
effectively meet the customer's requirements?</text>
• Consistency. Are there any conflicts arising from requirements?
• Completeness. Does the customer's requirements encompass all necessary
functions?
• Realism. Is it feasible to achieve the requirements within the constraints of the
existing budget and technology?
• Verifiability. Could you verify the requirements? Requirements validation
techniques
• Requirements reviews
– A methodical manual analysis of the specifications.
• Prototyping
– Verifying requirements with an executable model of the system.
• Test-case generation
– Creating tests to verify the testability of requirements. Requirements
reviews
• While the requirements definition is being developed, regular reviews ought to be
conducted.
• Staff from the contractor and the client should participate in reviews.
 52

• Reviews might be informal or formal, requiring completed papers. Early problem

solving is possible when developers, clients, and users have effective
communication.

Review checks
• Verifiability. Can the requirement be tested in a practical way?
• Comprehensibility. Does the requirement make sense to you?
• Traceability. Does the requirement clearly identify where it came from?
• Adaptability. Is it possible to modify the requirement without significantly
affecting other requirements?

Requirements Management
• Managing evolving needs during requirements engineering and system
development is known as requirements management.
• There will always be incomplete and inconsistent requirements;
– As business needs evolve and a deeper understanding of the system is
created, new requirements will always arise;
– Diverse perspectives will result in diverse requirements, many of which
are contradictory.

Requirements evolution

Requirements classification
 53

Requirements Management Planning

• During the process of requirements engineering, you are required to plan for the
following: – Requirements identification
• The procedure that is followed when assessing a change in the requirements; – An
approach to the management of change
• The method by which individual needs are determined
- Policies regarding traceability
• The quantity of information that is retained regarding the links between the needs;
– Support for CASE-based tools
• The tool support necessary to assist with the management of changing
requirements; Requirements change management
• Must be applicable to any suggested modifications to the requirements.
• Principal stages
– Problem analysis. Examine the requirements issue and suggest a solution;
– Change analysis and costing. Analyze how a modification will affect other
requirements;
– Change implementation. Changes should be reflected in the requirements
document and other documents. Change management
 54

Requirements Modeling Requirements

Analysis
• Models of the following kinds are produced as a result of the requirements
modelling process:
• Requirements models based on scenarios, including input from a wide range of
system "actors."
• Class-oriented models capture the interplay between classes in an object-oriented
framework and the properties and operations they use to fulfil system needs.
• Pattern- and behavior-based models that show how the programme responds to
outside "events."
• Data models representing the problem's information space.
• Models focused on data flow that depict the system's functional components and
the transformations they enact on data as it moves through the system.
• There are three main goals that the requirements model has to accomplish:
(1) describing the needs of the customer;
(2) providing a foundation for the software architecture; and
(3) defining a set of requirements that can be verified once the software is developed.

Analysis Rules of Thumb

• The model should be centred on the obvious requirements of the problem or
business domain. It is advised that a relatively high level of abstraction be used.
• The information domain, the function, and the behaviour of the system are all
aspects of the system that could benefit from the insights provided by the
requirements model. That's the case if we want to say this model works.
• Consideration of infrastructure and other non-functional models should be
postponed until after design has been completed. That is to say, it is possible that a
database will be necessary; nevertheless, the classes necessary to implement it, the
functions required to access it, and the behaviour that will be exhibited as it is
used should not be addressed until after the issue domain analysis has been
finished.
• Reduce the amount of connection that exists throughout the system. It is essential
to accurately portray the connections that exist between classes and functions.
 55

However, if the degree of "interconnectedness" is already at an excessively high

level, there is a need for attempts to bring it down.
• You should make sure that the requirements model offers something of value to
all of the stakeholders. The model can be put to a variety of different uses
depending on the constituency. For instance, business stakeholders should use the
model to validate the requirements; designers should use the model as a basis for
design; and quality assurance experts should use the model to assist in the
planning of acceptance tests.

• Try to keep the model as straightforward as possible. It is not necessary to provide

additional diagrams if they do not contribute any new information. Avoid using
complicated notational forms wherever possible and stick to using lists instead.

Elements of the analysis model

DATA MODELING CONCEPTS

• Data Objects
• Data Attributes
 56

• Relationships
Data Objects
• A data object is a computer-understandable representation of complex data.
• • Anything that meets the definition of a data object (such as anything that
generates or uses information) can be considered a data object.
• something (such a report or a display, for example)
• an occurrence (like a phone call), • an event (like an alarm), or both
• a function (such as a salesperson),
• a department within an organisation (such as accountancy), a location (such as a
warehouse), or a structure (such as a file) are all examples of organisational units.

Figure. Tabular representation of data objects

Data Attributes
The properties of a data entity are referred to as its data attributes, and these attributes can
have one of three distinct qualities. They have three different functions:
(1) they can be used to name an instance of the data object;
(2) they can be used to describe the instance; and
(3) they can be used to make a reference to another instance that is located in another
table.

Relationships
• There are various methods in which data objects are related to one another.
 57

Figure. Relationships between data objects

Flow Oriented Modelling

• It illustrates the transformations that occur to data objects as they pass through the
system.
• DFDs explain how information enters and exits a system and what the system does
with the data.
• A data flow diagram (DFD) shows how information moves through a system.
58
 59

DFD for SafeHome system

SCENARIO-BASED MODELING
 60

Firstly, what topic should you write on?

Secondly, What is the appropriate amount of writing to do about it?
Thirdly, what level of information is appropriate for your description?
And finally, what order should the description be in?

These are the problems that need to be addressed in order for use cases to be a useful tool
for requirements modeling.
The SafeHome home surveillance function that are performed by the homeowner
actor:
• Choose the camera you want to view.
• Make sure thumbnails are requested from all of the cameras.
• Views of the camera can be seen in a window on your computer.
• Manage the camera's pan and zoom settings individually.
• Record the output of the camera in a selectable manner.
• Play back the output from the camera.
• Use the Internet to access the video surveillance cameras.

Use case: Access camera surveillance via the Internet—display camera views Actor:
homeowner
1. The homeowner visits the SafeHome Products website and checks in to their account.
2. The user ID of the homeowner is entered into the system.
3. The homeowner is required to enter two passwords, each of which must be at least
eight characters long.
4. The system presents buttons for all of the primary functions.
5. The homeowner presses the button labelled "surveillance" to access the system's
primary functions.
6. The homeowner then chooses the option to "pick a camera."
7. The system will show you the layout of the house's floor plan.
8. The homeowner chooses an icon for a camera from the floor layout.
9. The homeowner clicks the "view" button on their computer screen.
Refining a Preliminary Use Case
Therefore, in order to evaluate each phase that makes up the major scenario, the
following questions will be asked.
 61

• Is there any other course of action that the actor can take at this point?
• Is it feasible that the actor will experience some kind of error circumstance at this
particular juncture? If that's the case, what could it be?
• Is it likely that the actor will come across another behaviour at this point, such as a
behaviour that is triggered by an event that is not under the actor's control? If that's
the case, what could it be?
Preliminary use case diagram for the SafeHome system

UML MODELS THAT SUPPLEMENT THE USE CASE

Even if it's something as straightforward as a use case, there are a lot of requirements
modelling scenarios in which a text-based model might not be able to convey information in
a way that's both clear and succinct. In situations like this, you have access to a vast library
of UML graphical models to select from.
• Developing an Activity Diagram
• Swimlane Diagrams
Activity diagram for Access camera surveillance via the Internet— display camera views
function.
 62

Swimlane diagram for Access camera surveillance via the Internet—display camera views
function.
 63

REQUIREMENTS MODELING FOR WEB AND MOBILE APPS

The following size-related variables dictate how much focus is placed on requirements
modeling for Web and mobile applications:
(1) The scope and intricacy of the application increment;
(2) The quantity of stakeholders (analysis can assist in identifying conflicting
requirements originating from various sources);
(3) The size of the app development team;
(4) The extent to which team members have collaborated previously (analysis can aid in
creating a shared understanding of the project); and
(5) The duration elapsed since the team's last collaboration.
 64

Module 3
DESIGN ENGINEERING AND METRICS

1. Class Diagram

Purpose: Represents the static structure of a system by showing its classes, attributes,
operations, and the relationships among objects.

• Class: A blueprint for creating objects. It encapsulates data for the object and
methods to manipulate that data.
o Attributes: Properties or fields of a class.
o Operations (Methods): Functions or procedures that the class can perform.
• Association: A relationship between classes.
o Multiplicity: Defines how many instances of a class are associated with
one instance of another class (e.g., one-to-many, many-to-many).
• Aggregation: A type of association that represents a "whole-part" relationship. For
example, a library and books.
• Composition: A stronger form of aggregation with a life-cycle dependency. For
example, a house and its rooms.
• Inheritance: A mechanism where one class (subclass) inherits attributes and
operations from another class (superclass).
• Interface: Defines a contract that implementing classes must follow, without
providing the implementation details.
• Dependency: A relationship indicating that a change in one class may affect
another class.

2. Use Case Diagram

Purpose: Describes the functional requirements of a system from the end user's
perspective.

• Actor: An external entity (user or another system) that interacts with the system.
• Use Case: A specific functionality or service that the system provides to actors.
• System Boundary: Defines the scope of the system, showing which use cases are
included.
• Relationship:
o Association: A line connecting an actor to a use case indicating interaction.
 65

o Include: A relationship where one use case includes the functionality of

another use case.
o Extend: A relationship where one use case extends the behavior of another
use case.
o Generalization: A relationship where a use case or actor is a specialized
version of another.

3. Activity Diagram

Purpose: Illustrates the flow of activities or actions in a system, showing the sequence and
conditions for these activities.

• Activity: Represents a task or operation in the system.

• Action: A specific step or operation within an activity.
• Flow: Shows the direction of control between activities or actions.
• Decision Node: Represents a point where the flow diverges based on conditions.
• Merge Node: Combines multiple incoming flows into a single outgoing flow.
• Fork Node: Splits a single flow into multiple concurrent flows.
• Join Node: Merges multiple concurrent flows into a single flow.
• Swimlane: Divides the diagram into sections to represent different responsibilities
or actors.

4. Interaction Diagram

Purpose: Focuses on the flow of messages between objects and how they collaborate.

• Sequence Diagram: Shows how objects interact in a particular sequence of events.

o Lifeline: Represents an individual participant or object in the interaction.
o Message: Communication between lifelines, including synchronous and
asynchronous messages. o Activation: The period during which an object is
active and can send or receive messages.
• Communication Diagram: Represents interactions between objects in a network-
like fashion.
o Object: Entities that interact with each other.
o Link: Connections between objects.
o Message: Communication between objects, similar to sequence diagrams.
 66

5. State Machine Diagram

Purpose: Models the dynamic behavior of a system or an object by showing its states and
transitions.

• State: Represents a condition or situation during the life of an object.

• Transition: Represents the movement from one state to another triggered by
events.
• Event: A stimulus that causes a transition from one state to another.
• Action: An operation or activity that occurs during a state transition. • State
Diagram: Includes states, transitions, and activities related to the state.

6. Component Diagram

Purpose: Depicts the physical components of a system and their relationships.

• Component: A modular part of a system that encapsulates a set of related

functions or services.
• Interface: Defines a contract for the services provided by a component.
• Port: Defines interaction points between a component and its environment. •
Dependency: A relationship showing that one component relies on another.

7. Deployment Diagram

Purpose: Shows the physical deployment of artifacts on nodes and their relationships.

• Node: A physical entity that hosts artifacts (e.g., a server, device).

• Artifact: A physical piece of information that is produced or consumed (e.g., files,
executables).
• Deployment: The distribution of artifacts to nodes.
• Association: Represents the connection or communication path between nodes.

These UML diagrams collectively help in visualizing, specifying, constructing, and documenting
the artifacts of a software system, ensuring a comprehensive understanding of both static and
dynamic aspects of the system.

Metrics in the Process and Project Domains

 67

1. Process Metrics

Purpose: Process Metrics are the measures of the development process that create a body
of software.
• Cycle Time: The time taken to complete a particular process or task from start to finish.
For instance, the time to develop a feature or resolve a defect.
• Lead Time: The total time from when a request is made until the final delivery. This
includes development time, testing time, and any other phases.
• Throughput: The number of units of work (e.g., features, defects) completed in a
specific period. It reflects the productivity and capacity of the development team.
• Defect Density: The number of defects per unit size of the code (e.g., per 1000 lines of
code). This helps in evaluating the quality of the development process.
• Work in Progress (WIP): The number of tasks or features currently being worked on. It
helps in understanding the current load and efficiency.
• Process Compliance: The degree to which the development process adheres to defined
standards and practices. To defined standards, guidelines, or regulations. It ensures
consistency and quality in the software development process.

2. Project Metrics

Purpose: To track project performance and progress.

• Cost Performance Index (CPI): A measure of cost efficiency in a project. CPI = Earned
Value / Actual Cost. A CPI greater than 1 indicates cost efficiency.
• Schedule Performance Index (SPI): A measure of schedule efficiency. SPI = Earned
Value / Planned Value. An SPI greater than 1 indicates ahead of schedule.
• Earned Value (EV): The value of work actually performed compared to the baseline
plan. It helps in measuring project performance.
• Planned Value (PV): The value of work planned to be performed by a specific time. It
helps in assessing whether the project is on track.
• Actual Cost (AC): The actual cost incurred for the work performed by a specific time. It
helps in comparing with the planned costs.
• Variance Analysis: Analyzing the differences between planned and actual performance.
This includes cost variance (CV = EV - AC) and schedule variance (SV = EV - PV).
• Risk Metrics: Measures related to risk management, such as the number of identified
risks, risk impact, and the effectiveness of risk mitigation actions.
 68

Software Measurement

Purpose: To quantify various attributes of software to support better decision-making and

improvement.

• Size Metrics: Quantify the size of software components. Common measures include:
o Lines of Code (LOC): The number of lines in the codebase. It helps in estimating
complexity and effort.
o Function Points (FP): A measure of functionality provided to the user,
independent of the programming language.
• Complexity Metrics: Measure the complexity of software to estimate effort and
maintainability.
o Cyclomatic Complexity: Measures the number of linearly independent paths
through the program's source code. Higher values indicate higher complexity.
o Halstead Complexity Measures: Metrics based on the number of operators and
operands in the code.
• Maintainability Metrics: Assess how easily software can be modified.
o Maintainability Index: A composite metric that includes cyclomatic complexity,
lines of code, and other factors to estimate maintainability.
Metrics for Software Quality

Purpose: To assess and improve the quality of the software product.

• Defect Metrics: Measures related to defects and their impact.

o Defect Rate: The number of defects found per unit of size (e.g., per 1000 LOC).
o Defect Discovery Rate: The rate at which defects are discovered over
time.
o Defect Severity: Classification of defects based on their impact on the system
(e.g., critical, major, minor).
• Test Metrics: Metrics related to testing and its effectiveness.
o Test Coverage: The percentage of the codebase exercised by tests. High coverage
indicates thorough testing.
o Defect Density in Test Cases: The number of defects found per unit of test cases
executed.
• Customer Satisfaction Metrics: Measures related to end-user satisfaction.
o Customer Satisfaction Index: Survey-based metric to gauge user satisfaction
with the software.
 69

o Net Promoter Score (NPS): Measures the likelihood of customers

recommending the software to others.
• Performance Metrics: Assess the efficiency and responsiveness of the software.
o Response Time: The time taken by the system to respond to a user action. o
Throughput: The number of transactions or requests processed by the system in
a given period.
• Usability Metrics: Measures related to the ease of use and user experience.
o Usability Score: Derived from user surveys and feedback to assess how easy and
intuitive the software is to use.
o Error Rate: The frequency of user errors during interaction with the software.

By employing these metrics, organizations can gain insights into their software development
processes, manage projects more effectively, and ensure high-quality software products. Metrics
help in making data-driven decisions, improving performance, and achieving better alignment
with business goals.
 62

MODULE-4 TESTING STRATEGIES

A Strategic Approach to Software Testing:

* Testing is a group of tasks that can be methodically and premeditatedly completed. * A
collection of testing procedures and test case design strategies are explained for a
software process.
* Several testing techniques are suggested
* Diverse testing techniques are suggested
* Testing is a series of tasks that can be organized and completed methodically in
advance.
Testing Strategies – Generic Characteristics:
* A group of software developers must conduct efficient formal technical reviews before
they may test software.
* Testing starts with the individual components and progresses to the integration of the
complete computer-based system.
* The software developer and, for larger projects, an independent test group carry out the
testing.
* Testing begins with component level work and progresses to the integration of the
entire computer-based system.
***********************************************************************
* Note:
Testing VS Debugging:
While testing and debugging are two different processes, every testing approach must
include debugging.
* A testing strategy should include guidelines for the tester as well as a management
checklist of benchmarks.
***********************************************************************
*
(1) Verification and Validation:
* Verification refers to a series of steps taken to ensure that a programme correctly
accomplishes a specified task.
Example:
Verification: Are we building the product right?
 63

* Various procedures are carried out under the umbrella term of "validation" to
guarantee that the final product of software development is tied to the requirements of the
customer.
Example:
Validation: Are we building the right product?
* The processes of verification and validation involve a wide range of SQA operations
that include the following:
=> Formal Technical Reviews
=> Quality and Configuration audits
=> Performance Monitoring
=> Simulation
=> Feasibility Study
=> Documentation Review
=> Database Review
=> Analysis Algorithm
=> Development Testing
=> Usability Testing
=> Qualification Testing
=> Installation Testing
(2) Organizing for Software Testing:
* The developer often also carries out integration testing, which is a phase of testing that
comes before the complete software architecture is constructed.
* Testing the various units (components) of the program is always the responsibility of
the software developer.
* Once the software architecture has been completed, an independent testing group will
be recruited to evaluate the product. The purpose of an Independent Test Group, which
is also abbreviated as an ITG, is to eliminate the inherent challenges that come when
the builder is given the opportunity to test the thing that has been built. This is
accomplished by eliminating the inherent difficulties. During the course of a software
project, the developer and the ITG work together very closely to ensure that through
testing will be performed.
* The developer needs to be available when testing is being done so that he or she may
fix any mistakes that are found.
 64

(3) Software testing strategy for conventional software architecture:

* A testing method for software can be understood in the context of the spiral, as depicted
in the following diagram:

* Unit testing starts at the middle of the spiral and concentrates on the software's
components as they are written in the source code. * Proceeding in a different direction
down the spiral, we encounter integration testing, which is concerned with the planning
and building of software architecture. * Next, validation testing is introduced, which
compares requirements that have been established during software requirements
analysis with software that has already been developed. * Finally, we come across
verification testing, which verifies that software that has been constructed satisfies
requirements that were determined during software requirements At last, we come to
the system testing phase, which involves testing the software along with the other
components of the system as a whole.
Software Testing Steps:
(i) Unit Testing:
* The initial phase of testing involves the examination of each component in isolation to
verify its proper functioning as an independent unit.
 65

* Unit testing employs rigorous testing techniques to achieve comprehensive coverage

and optimal error detection within the control structure of the components.
* Subsequently, the components are integrated to form cohesive software packages.

(i) Integration Testing:

* It solves the problems that arise when verifying and building a programme
simultaneously
* The requirements analysis validation criteria
* need to be tested. With validation testing, you can rest assured that your software will
perform as expected in every way.
* A series of high - order tests are executed after the software has been integrated [built].

(iii) High Order Testing:

* It is not considered to be a part of software engineering
* After the programme has been verified, it needs to be integrated with the other
components of the system (for example, the hardware, the people, and the software). *
Testing a system ensures that all of its components work together as intended and that
the desired level of overall functionality and performance is reached.

6.4 Strategic Issues:

 66

* If you want your software testing strategy to be successful, you need to address the
following issues:
(1) Specify product requirements in a quantifiable manner well in advance of testing
beginning;
(2) State testing objectives explicitly;
(3) Understand who will be using the software and create a profile for each user category.
(4) Formulate a strategy for tasting that places an emphasis on "Rapid Cycle Testing."
(5) Construct reliable software that is intended to perform its own testing.
(6) Employ efficient formal technical reviews as a filter prior to testing.
(7) Carry out formal technical reviews to evaluate the test strategy and test cases.
(8) Construct an approach for the testing process that emphasises continual improvement.

Test Strategy for Conventional Software:

* There are many different ways to test software, thus some of the available options are
as follows:
(i)A software team could wait until the system is completely built, and then they could
run tests on the system to look for faults. * This strategy is not effective in the majority of
situations.
(ii) A software engineer might be able to run tests every day anytime any
component of the system is being built
* This strategy has the potential to yield excellent results. But the majority of software
engineers are reluctant to make use of it
(iii) The majority of software teams opt for a testing technique that lies somewhere in the
middle of the two extremes
It adopts an incremental approach to testing, beginning with the testing of individual
programme units, then moving on to tests meant to aid the integration of the modules,
and finally culminating with tests that exercise the created system as a whole.

6.6 Unit Testing:

* It concentrates on the verification of the smallest unit of software design (also known
as a software component or module);
* It concentrates on the internal processing logic and data structures that are contained
inside the bounds of the component;
 67

Unit test Considerations:

* The test that is performed as a part of the unit tests is displayed below Interface:
* It is examined to ensure the following conditions are met:
=> Information is able to flow correctly into and out of the programme unit that is being
evaluated Local Data structures:
* These are investigated to guarantee that
=> The data that is kept in a temporary storage space will keep its integrity during the
entirety of the operation of an algorithm.

Independent Paths:
* Each and every basis path that passes through the control structures is investigated to
guarantee that
=> Each and every statement contained within a module has been run at least once.

Boundary Conditions:
 68

* These are verified to ensure that

=> the module runs correctly within the boundaries that have been specified in order to
limit (Or restrict) processing.
* And lastly, all possible error-handling routes are put through their paces.
Before any other tests can be run, there must first be validation of the dataflow across an
interface module. another test will be performed.
During the unit testing process, one of the most important tasks is to perform selective
testing of the execution path.

* Test cases must to be developed to unearth faults brought on by= Incorrect

Mathematical Processing Comparisons That Are Not Accurate Control not being
properly maintained
Common errors in computations are:
(1) Mixed mode operations
(2) Misunderstood arithmetic precedence
(3) wrong initialization
(4) Precision inaccuracy
(5) Misunderstood or wrong arithmetic precedence
(6) An inaccurate portrayal of a symbol representing an expression

Test cases should uncover errors, such as

(1) A comparative analysis of multiple data formats;
(2) erroneous logical operators (Or) hierarchy
(3) Expecting equality when precision error makes it unlikely;
(4) Making incorrect variable comparisons
(5) Incorrect (Or nonexistent) loop termination;
(6) Failure to terminate when divergent iteration occurs;
(7) Inaccurately changed loop variables

Boundary Testing:
* This is one of the most significant responsibilities involved in unit testing
 69

* A common cause of software failure is when it reaches one of its limits (for example,
an error frequently happens when the nth element of an n-dimensional array is
handled).
When evaluating error handling, the following are some examples of potential errors that
should be tested:
Processing under exception conditions is not right. The error description is
insufficient to help identify the error's cause.
(1) The error description is not clear.
(2) The error reported does not match the error experienced.
(3) An operating system intervention occurs before error handling due to an error state.
(4) The error description is insufficient to help identify the error's cause.

Unit Test Procedures: * Unit test design can be done either before
or after code is generated.
 70

Driver:
* A driver is not much more than an application's "main programme" in the vast majority
of cases * It accepts
=> data from test cases
=> Sends these data to the component that is [about to be tested].
=> Print the findings that are relevant.

Stub (Or) Dummy Programs:

* It takes the place of modules that are called by the component that is being tested.
* Stub utilises
=> the interface of the subordinate module.
= >Manipulate the data as little as possible
.=> guarantees the authenticity of the entry
=> transfers control back to the module that is currently being evaluated

* Drivers and stubs are two different types of software that need to be built, but they are
not included in the final software product.
* The real overhead is reasonably modest if the drivers and stubs are kept simple;
otherwise, it is substantial.
* When a component that has a high cohesiveness is designed, it simplifies the unit
testing process.
Integration Testing:
* Once all of the modules have passed their own unit tests meaning that all of the
modules function properly, we have doubts about whether or not they will work, when
do we integrate them together?
* Integration testing is going to be the solution for this problem.
Interfacing:
It is the mechanism that brings together all of the individual modules.
The following are the issues that can arise throughout the interfacing process: It is
possible to lose data when moving between interfaces.
=> An unintended negative effect can be caused by one module on another module.
 71

=> The combination of subfunctions might not result in the principal function that is
required.
What it does
=> An imprecision that is tolerable on its own might become intolerable when it is
multiplied. scales levels
=> Issues may arise due to the use of global data structures
Integration Testing – Definition:
* It is a methodical approach to building the software architecture, while at the same time
running tests to find faults linked with the software's interface.
* The goal is to use components that have undergone unit testing and construct a
programme structure according to the specifications set out by the design.

Incremental Integration:
* In this scenario, the programme is built and tested in small steps
* Errors are easy to localise and rectify
* Interfaces are tested in their entirety and a systematic testing strategy may be used
* There are several variants of the incremental integration method to choose from.

Incremental Integration – Types: (1)

Top – Down Integration:
 72

The software architecture is being built up in stages, including through this testing, which
is an incremental method.
* The modules are integrated by moving down the control hierarchy, beginning with the
main control module, also referred to as the main programme.It is possible to
incorporate the subordinate module to the principal control module either depth-first or
breadth-first.

Depth First Integration:

* Every component of the program structure integrates with its major control path.The
features specific to the application dictate the principal route selected.
*For example, if the components of the left-hand path were selected, integration would start
with M1, M2, and M5, and end with M8.The center and right hand control routes are then
constructed.

Breadth First integration:

* It incorporates all components that are immediately subordinate at each level, moving
the structure horizontally.
In the image on the right, the subassemblies M2, M3, and M4 would be integrated first, followed by
M5, M6, and so forth.

The steps that comprise the integration process are as follows:

Step 1: All components that are directly subordinate to the main control module are replaced with
stubs, and the main control module acts as the test driver.
Step 2: Depending on the integration method selected, either the breadth first or the depth first
approach is used to replace inferior stubs with genuine components one at a time.
Step 3: As each component is being integrated, tests are run.
Step 4: The actual component will be substituted by a new stub once each group of tasks has been
completed.
Step 5: Regression testing could be useful to ensure that no further errors have been introduced. The
process will start with Step 2 and continue until the full program structure is created.

Advantages:
(1) Top-down integration has several advantages, including ensuring important control or
decision points are proven early in the testing process.
 73

(2) In order to gain the trust of both the customer and the developer, it is advantageous to do
an early demonstration of the product's functional capabilities. This is noteworthy because it
shows that the feature is operating according to plan, which is crucial information to know.
(3) Despite not being unduly complex, this strategy could result in a number of real-world
problems.
(2) Bottom – Up Integration:
* In this scenario, start creating and testing the foundational components of the
software.The processing necessary for components subordinate to a specific level can
always be available thanks to the bottom-up integration of components.In this instance,
the stub is not required.

Actions taken during the Bottom-Up Integration:

Step 1: Low-level components are put together to form builds, or clusters, that execute certain
software functions.
Step 2: To synchronize the input and output of test cases, write a driver, or control software for
testing.
Step 3: Examining the cluster
Step 4: As drivers go up the program structure, clusters are combined and deleted.
Example:

Clusters 1, 2, and 3 are formed by assembling the components, as seen in the image below.
* A driver assists in putting each Cluster through its paces.
* The components from Clusters 1 and 2 are subordinate to the Ma component.After
taking drivers D1 and D2 out of commission, clusters are now connected to Ma
directly.Driver D3 for cluster-3 has also been removed and integrated with MB in a
similar fashion.
The Mc structure incorporates both Ma and Mb as components.
 74

Bottom up Integration

6.9 Regression Testing:

* It involves rerunning a portion of previously completed tests to make sure that
modifications have not had any unanticipated negative effects.
* i.e. whenever software is updated, a portion of the software configuration is altered,
including the program, its documentation, and the data that supports it.
* Regression testing is the process used to make sure that modifications made [for testing
purposes or for other reasons] don't result in the introduction of new errors.
* Regression testing can be carried out either manually by running a subset of all test
cases again or automatically by employing tools for capture and playback.
 75

* Software engineers can record test cases and outcomes with capture and playback tools
for later comparison and playback.
* There are three types of test cases in the regression test suite:
(i) A sample set of tests that will run through every feature of the
software
(ii) Further testing concentrating on software features that are probably
going to be impacted by the modification
(iii) Tests concentrating on the modified software components

Smoke Testing:
* When developing software products, this approach to integration testing is frequently
employed.
* It is intended to serve as a patching mechanism for projects that are time-sensitive,
enabling the software team to regularly evaluate its work.
Activities included in the smoke testing:
(1) A "Cluster" is assembled from software components that have been converted
into code. Every data file, library, reusable module, and engineering component needed
to carry out one or more product functions is included in a cluster.
(2) A battery of tests is intended to identify any problems that prevent the cluster
from operating as intended.
(3) The product is tested for smoke every day and the clusters are integrated with
additional clusters.
* The integration strategy might be either bottom-up or top-down.

Critical Module:
* It is a measure which contains one (Or) more of the following characteristics:
(i) Addresses several software requirements
(ii) Has a high level of control [resides relatively high in program
structure]
(iii) is complex (Or) error prone
(iv) Has definite performance requirements
* Testing the crucial module as soon as feasible is recommended.
 76

* Regression tests typically need to concentrate on important module functionalities.

Integration Test Documentation:

* A test specification includes a detailed task description and an overarching plan for software
integration. * This document contains a
=> Test Plan
=> Test Procedure
=> Work product of the software process
* Here, the testing process is broken down into phases and clusters that focus on particular
functional and behavioral aspects of the program.

Validation Testing:
* The validation process at the system level concentrates on the following:
=> User – visible actions
=> User recognizable output from the system
* Validation testing is only successful when the program operates as the customer would
reasonably expect it to.
* The Software Requirements Specifications define reasonable expectations
* A section of the specification called validation criteria serves as the foundation for a
validation testing approach

Validation Test Criteria:

* A test plan specifies the classes of tests to be conducted;
* Test procedures identify individual test cases;
* Software validation is accomplished by a sequence of tests;
 77
* The purpose of the procedures and test plan is to guarantee:
=> Every functional requirement has been met
=> all behavioral characteristics are achieved
=> all performance requirements are attained
=> documentation is correct
=> usability and other requirements are met

* One of the following two scenarios could arise following the validation test:
(i) The function's (or) performance characteristics meet the requirements
and are approved.
(ii) A list of deficiencies is made and the derivation from the specification
is discovered.
(iii) Derivation (Or) errors found at this point are rarely able to be fixed in
time for the delivery date.
Configuration Review (Or) Audit:
* It is a crucial component of the validation procedure. * The purpose of the review is to
make sure that
=> all software configuration elements have been generated or cataloged
correctly and
=> contain all the information needed to support each stage of the
software life cycle.
Alpha and Beta testing:
* To enable the customer to verify all requirements, a series of acceptance tests are
carried out when custom software is developed for a single customer.
* The end-user acceptance test, which is carried out by them instead of software
engineers
* Since it is difficult to conduct acceptance tests with every client while developing
software for mass use, most software product developers employ a procedure known as
alpha (Or) beta testing.
(i) Alpha testing:
* End Users perform it where the developers are located.
* The program is used in a realistic environment;
 78
* The developer is present at all times;
* The developer monitors errors and usage issues;
* Alpha tests are conducted in a closely supervised environment.
.
(ii) Beta testing:
* The beta test is a "Live" implementation of the program in an uncontrollable
environment for the developer.
* The end-user logs any issues that come up during beta testing;
* These error reports are forwarded to the developer on a regular basis;
* The software engineer modifies the product based on the error report, and then gets
ready to release it to all of the users. * It is carried out at end-user locations;
* The developer is not present at this time;
* The beta test is a "Live" application of the software in an

System Testing:
* It is a set of several tests with the main goal of thoroughly testing the computer-based
system.
* Although the goals of each test vary, they always aim to confirm that the various
components of the system have been correctly integrated and are carrying out their
designated tasks.
* Despite the fact that this test series' main objective is to thoroughly test the computer-
based system

Types:
(i) Recovery Testing
(ii) Security Testing
(iii) Stress Testing
(iv) Performance Testing
(v) Sensitivity Testing
(1) Recovery Testing:
* It is a type of system test that involves purposefully breaking the programme in a number
of various ways and checking to see whether or not recovery is carried out properly.
 79
* If the recovery process is automated, often known as being carried out by the system on
its own, then
=> * If it is necessary for human intervention to recover the lost data and restart the
system, the Mean Time to Repair (MTTR) metric is analysed to evaluate whether or not it falls
within the allowed range of values. The evaluation of the validity of the checkpointing
processes that occur as a consequence of reinitialization is what ultimately leads to the
assessment of data recovery and restarting.
(2) Security Testing:
Good security testing will eventually be able to break into a system if given sufficient
time and resources to do so. When designing a system, it is the job of the system designer
to ensure that the cost of penetrating the system is higher than the value of the
information that would be obtained.
* It ensures that the protective mechanism that is implemented into a system will, in fact,
safeguard the system from unauthorised intrusion.
* In the process of evaluating the system's security, the tester acts out the part of a
potential threat who wants to break into the system.

* In the process of evaluating the system's security, the tester acts out the part of a
potential threat who wants to break into the system.
* It ensures that the safety feature that was incorporated into a

(3) Stress Testing:

* Stress testing is the process of putting a system through its paces in a manner that
places an abnormal demand on its resources in terms of quality, frequency, or volume.
Example:
(i)When one (Or) two is the average rate, a unique test that produces the interruptions per
second may be created.
(ii) In order to see how input functions react, input data rates may be raised by an
order of magnitude.
Test cases requiring the maximum amount of memory (iii) or other resources are run.
(iv) Test cases are created that could result in issues with memory management.
(4) Performance Testing:
 80
* Its purpose is to evaluate software's performance within the framework of an integrated
system.
* At every stage of the testing process, performance testing takes place.
* Stress testing and performance testing are commonly coupled, and both hardware and
software requirements are usually involved.
* Its purpose is to assess software performance within the framework of a runtime
environment.
(5) Sensitivity Testing:
* It's a type of stress testing.
* For instance, a limited set of data that falls inside the boundaries of lawful data may
result in inflated and incorrect processing in the great majority of mathematical
algorithms.
* Finding data combinations within valid input classes that may cause instability or
incorrect processing is required to test for sensitivity.
The Art of Debugging:
* Debugging is not a type of testing, but it does always happen as a consequence of
testing. * This is when a test case shows an issue, and debugging is an activity that
ultimately leads to the problem being removed from the system.
The Debugging Process
 81
* The execution of a test case is the first step in the debugging process.
Next, the results are analysed, and a discrepancy between expected and actual
performance is discovered.
Next, debugging attempts to match symptoms with the underlying causes of errors, which
ultimately leads to error correction.
Finally, debugging always has one of two possible outcomes:
(i) the cause will be located and fixed, or
(ii) the cause will not be located. Debugging will always have one of these two outcomes.

Why is debugging so difficult?

(1) The symptom and the cause may be located in different parts of the world [that is, the
symptom may appear in one section of a programme, but the reason may actually be
situated at a location that is quite far away].
(2) The symptom might go away (temporarily) if another error is fixed.
(3) The symptom might really be caused by something that isn't an error at all (such as
rounding off inaccuracy).
(4) The symptom could be the result of an error made by a person that is difficult to
pinpoint.
(5) The symptom could be the result of timing problems rather than processing problems.
(6) It may be challenging to correctly duplicate the conditions of the input [for example,
in a real-time application when the ordering of the data is unpredictable].
(7) The manifestation of the ailment may come and go. This is especially common in
embedded systems, which combine hardware and software in a manner that cannot be
separated.
(8) The symptom may be the result of a lot of reasons that are spread across a variety of
jobs that are being executed on various processors.

*The amount of pressure to determine the causes of a mistake also grows *This pressure
compels the software developer to fix one problem while simultaneously adding two
more
*The amount of pressure to determine the causes of a mistake also increases
*The greater the implications of an error, the greater the amount of pressure there is to
investigate and pinpoint its root cause.
 82
6.15 Debugging Strategies:
* In general three debugging strategies have been proposed
(i) Brute Force
(ii) Back Tracking
(iii) Cause Elimination

(1) Brute Force:

Memory dumps, runtime traces, and output statements in the code are used for this, and
while the resulting data may be useful in the long run, the time and energy spent gathering it
are often better spent elsewhere.
* this method is applied only when all other methods fail.
* the philosophy used here may be "Let the computer finds the error." * we apply this
method only when all other methods fail. * we only apply this method when all other
methods fail.
* we only apply this method when all other methods fail.
(2) Back Tracking:
* This method is the most frequent one that can be implemented effectively in relatively
modest programmes.
* The source code is traced backward [manually] starting at the spot where a symptom
has been detected and continuing until the reason is found.
* If the number of source lines increases, the number of possible backward paths may
become unmanageably large.
* The number of possible backward paths could grow uncontrollably if the number of
source lines rises.
* The number of possible backward paths could become unmanageable if the number of
source lines rises.
* The number of alternative backward paths may grow unmanageably enormous if the
source code contains a big number of lines.
* If the source code contains a large number of lines, the number

(3) Cause Elimination:

* This can be accomplished through the use of induction (or) deduction
 83
* It presents the idea of binary partitioning. It is followed by the following steps: * A
cause hypothesis is formulated and is supported (or refuted) by the data pertaining to
the mistake occurrence.
* Every potential reason is enumerated, and experiments are carried out to rule them all
out.
* When preliminary investigations suggest that a specific cause theory holds potential,
data is reworked to try and find the bug. * A binary partitioning scheme is introduced
* Testing is done to rule out each potential reason after a list of all potential causes is
created.
6.16 White Box Testing:
White-box testing also known as clear box testing, glass box testing, or structural testing is
a software testing method that focuses on testing the internal structures, logic, and
implementation of the code. Unlike black-box testing, which examines functionality without
knowing the internal workings, white-box testing requires knowledge of the source code.
White box testing
• To test logical paths across the software, test cases with particular sets of conditions
and/or loops are provided.
• Testing of the software is referred to as white-box testing when it is dependent on a
detailed investigation of the product's procedures.
• The "status of the programme" can be evaluated at a number of different periods in
time.
• White-box testing, also known as glass-box testing, is a method for designing test
cases that derives test cases by using the control structure of the procedural design. This
method is frequently referred to as "glass-box testing."

Through the use of this strategy, SE is able to generate test cases that
1. Ensure that each and every independent branch contained within a module has been
traversed at least once.
2. Consider all logical judgements from both the correct and incorrect perspectives,
3. Ensure that all loops are executed at their respective limits and remain inside their
respective operational limitations
4. Perform tests on the internal data structures to confirm that they are valid.

Basis path testing

 84
• Test cases with specific sets of criteria and/or loops are supplied in order to evaluate
logical paths throughout the program.
• It is assured that each statement in the programme will be run at least once when
using test cases that are derived to exercise the basis set.
Methods:
1. Flow graph notation
2. Independent program paths or Cyclomatic complexity
3. Deriving test cases
4. Graph Matrices
 85

Each circle in figure B, which is referred to as a node on a flow graph, represents one or
more procedural statements.
• A mapping into a single node is possible for a series of process boxes and a decision
diamond.
• Similar to the arrows on flowcharts, the arrows on the flow graph, sometimes referred
to as edges or links, show the flow of control.
• Even in cases when a node does not reflect a procedural statement, it still needs an
edge to finish at that node.
• Any area bounded by a network of edges and nodes is referred to as a region. The area
outside the graph is counted together with the regions when we calculate the overall
count.
• In the event that a compound condition arises during the process of procedural design,
the flow graph will become marginally more convoluted.

Independent program paths or Cyclomatic complexity

• An independent path is any way through the programme that includes at least one new
set of processing statements or new condition. This is the minimum requirement for a
path to be considered independent.
 86
• Take, for instance, the following as an illustration of a set of independent paths for a
flow graph:
1-11 is the first path, and
1-2-3-4-5-10-1-11 is the second.
– Path 3: 1-2-3-6-8-9-1-11
– Path 4: 1-2-3-6-7-9-1-11
• Take note that every new path results in the creation of a new edge.
• The path 1-2-3-4-5-10-1-2-3-6-8-9-1-11 is not an independent path because it is merely
a combination of paths that have already been stated and does not traverse any new
edges. This means that it does not go through any new nodes.
• Test cases should be built in such a way that they are forced to follow these basic set
paths.
• Each and every line in the programme should have at least one opportunity to be run,
and each and every condition should have been tested both ways (true and false).
How can we determine the total number of possible routes to investigate?
• Cyclomatic complexity is a software metric that provides a quantitative measure of the
logical difficulty of a programme. It does this by counting the number of paths through
a programme.
•It offers the number of tests that need to be carried out in addition to defining the total
number of independent pathways in the basis set.
•Calculating cyclomatic complexity can be done one of three ways:
1. The cyclomatic complexity is directly proportional to the number of areas.
2. The cyclomatic complexity, denoted by the symbol V(G), of a flow graph, G, is
defined as V(G) = E - N + 2, where E represents the number of edges in the flow graph
and N represents the number of nodes in the flow graph.
3. A flow graph's cyclomatic complexity, V(G), can be written as V(G) = P + 1, where P
is the total number of nodes and edges in the predicate.
As a result, we have an upper bound on the total number of tests based on the value of
V(G).
Deriving Test Cases
• This strategy consists of a predetermined order of actions.
• The average of the operation as shown in the PDL.
 87
• The extremely straightforward algorithm known as average includes both
complex criteria and loops.
To derive basis set, follow the steps.
1) A flowchart should be created based on the design or code.
Numbering the PDL statements that will become nodes in the flow graph is the first step
in making the graph.
88
 89

Flow graph for the procedure average

Determine the cyclomatic complexity of the resultant flow graph.
1. Second, V(G) can be calculated without making a flowchart by counting the
number of conditional statements in the PDL (complex conditions count as two
for the average method) and then adding 1.
2. Theorem 3: V(G) = 6 regions
3. Fourth, V(G) = 17 - 13 + 2 = 6
4. In other words, V(G) = 5 predicate nodes+ 1 = 6
Determine a basis set of linearly independent paths
a. The value of V(G) provides the number of linearly independent paths
through the program control structure.
b. path 1: 1-2-10-11-13
c. path 2: 1-2-10-12-13
d. path 3: 1-2-3-10-11-13
e. path 4: 1-2-3-4-5-8-9-2-. . .
 90
f. path 5: 1-2-3-4-5-6-8-9-2-. . .
g. path 6: 1-2-3-4-5-6-7-8-9-2-. . .
h. The ellipsis (. . .) following paths 4, 5, and 6 indicates that any path
through the remainder of the control structure is acceptable.
5. Prepare test cases that will force execution of each path in the basis set.
a. Data should be chosen so that conditions at the predicate nodes are
appropriately set as each path is tested.
b. Each test case is executed and compared to expected results.
c. Once all test cases have been completed, the tester can be sure that all
statements in the program have been executed at least once.

1. Statement Coverage

 Definition: Ensures that every executable statement in the code is executed at least once
during testing.
 Objective: To verify that no line of code remains untested.

Ex:-

def calculate(num):

if num > 0:

print("Positive number")

else:

print("Non-positive number")

Test cases for 100% statement coverage:

 Input: 5 (executes print("Positive number"))

 Input: -3 (executes print("Non-positive number"))

2. Branch Coverage (Decision Coverage)

 Definition: Ensures that every possible branch (outcome of each decision) is tested at least
once.
 Objective: To test both the true and false outcomes of each decision point.

Ex:-
 91
def is_even(num):

if num % 2 == 0:

return True

else:

return False

Test cases for 100% branch coverage:

 Input: 4 (True branch)

 Input: 3 (False branch)

3. Path Coverage

 Definition: Ensures all possible paths through the code (including combinations of
branches) are tested.
 Objective: To explore every unique path in the code, covering all branches and loops

Ex:-

def check_number(num):

if num > 0:

if num % 2 == 0:

print("Positive even number")

else:

print("Positive odd number")

else:

print("Non-positive number")

Test cases for 100% path coverage:

 Input: 4 (Path 1: num > 0 and num % 2 == 0)

 Input: 3 (Path 2: num > 0 and num % 2 != 0)
 Input: -1 (Path 3: num <= 0)
 92
4. Condition Coverage

 Definition: Ensures that every individual condition in a decision (e.g., within if statements)
is tested for both true and false outcomes.
 Objective: To test each condition independently.

Ex:-

def check_conditions(a, b):

if a > 0 and b > 0:

print("Both are positive")

Test cases for 100% condition coverage:

 Input: a=1, b=1 (Both conditions true)

 Input: a=1, b=-1 (First condition true, second false)
 Input: a=-1, b=1 (First condition false, second true)
 Input: a=-1, b=-1 (Both conditions false)

5. Loop Testing

 Definition: Focuses on validating the behavior of loops under different conditions (e.g., zero
iterations, one iteration, multiple iterations, maximum iterations).
 Objective: To ensure loops handle various cases correctly.

Ex:-

def sum_numbers(n):

total = 0

for i in range(n):

total += i

return total

Test cases for loop testing:

 Input: n=0 (Zero iterations)

 Input: n=1 (One iteration)
 Input: n=5 (Multiple iterations)
 93

Black – Box Testing:

Black box testing is a complementary strategy that is likely to reveal a different class of
problems than white-box testing methods; it is not meant to be used in place of white box
testing.
* It is also known as Behavioural Testing.
* White box testing and black box testing are not interchangeable.
* Black box testing is also known as Behavioural Testing. Testing in a black box makes
an effort to identify problems in the following areas:
(1) Incorrect Functions, Or Functions That Are Missing
(2) Errors in the interface
(3) Errors in the data structures (Or) unauthorised access to external data bases
(4) Inappropriate behaviours (Or) Poor performances
(5) Errors during the initialization and termination processes

Types of Black Box Testing

There are several phases of which are segregated into different types, such as regression testing, unit
testing, beta testing, integration testing, system testing, functional testing, load testing, etc. But, the
prominent types are explained below.

Functional Testing:

This type of testing is useful for the testers in identifying the functional requirements of a software
or system.

Regression Testing:

This testing type is performed after the system maintenance procedure, upgrades or code fixes to
know the impact of the new code over the earlier code.

Non-Functional Testing:

This testing type is not connected with testing for any specific functionality but relates to non-
functional parameters like usability, scalability and performance.
 94
Graph-Based Testing Methods
• To have an understanding of the relationships that connect the items that are
modelled in software as well as the objects themselves.
• The following step is to develop a series of tests that will verify that "all objects
have the expected relationship to one another."
Alternately stated as follows:
- Make a diagram depicting significant things and the connections between them.
- Conceive a battery of examinations that will be centred on the graph.
• In order to ensure that every item and relationship is tested and that any errors are
located.
• To begin, design a graph that consists of a set of nodes, which stand for items, and links,
which depict the connections that exist between those objects. The nodes will represent
the items, and the links will show the relationships between the items.
– weights that describe some aspect of a link, which are referred to as link weights; –
weights that characterise the qualities of a node, which are referred to as node weights.

• The nodes in the network are depicted as circles, and the connections between them can
take on a variety of forms.
• A one-way relationship is denoted by a directed link, which is depicted as an arrow and
indicates that the link only goes in one direction.
• The relationship is considered to apply in both directions when there is a bidirectional
link, which is also referred to as a symmetric link.
When multiple distinct associations need to be constructed between two nodes in a graph,
the use of parallel links is necessary.

Example
 95

• Object #1 This is the item that you selected from the “New File” option.
• Object #2 This is the window that was made just for the document.
• Object No. 3 indicates the next that is present in the document.

Upon choosing a fresh file from the menu:

- A window for the document opens.
- According to link weight criteria, this window must be created in less than 165
milliseconds.
- The node weights associated with the document window describe its anticipated
characteristics.
- A parallel link exists, suggesting a connection between the text of the document and the
document window.
- A symmetric relationship between the document text and the "New File" menu selection
is shown by an undirected link.

To define equivalence classes, follow the guideline

1. There are two invalid equivalency classes and one legal equivalency class defined
if the input condition calls for a range to be specified.

2. When an input condition asks for a certain value, there are two defined incorrect
equivalence classes and one defined genuine equivalency class.
3. When an input condition identifies a member of a set, an equivalency class will be
created.
4. When an input condition is Boolean, a valid class and an invalid class are defined.
 96

Example
• The area code, which could be a three-digit number or a blank number
• The terms prefix and suffix refer to three-digit numbers that do not begin with zero or
one, respectively, and sometimes to four-digit numbers.
• Password: a six-digit string that is both numeric and alphabetic
• orders like pay bills, deposit checks, and other comparable ones
• Boolean input condition: either true or false, depending on whether the area code is
present.
• Kindly enter the value as a three-digit number and the condition.
• prefix: • Range of values defined between 200 and 999, with some deviations from the
norm.
• Four-digit length for the input condition and value; • Suffix:
• password: Boolean input condition that allows a password to be either present or
absent.

Equivalence Partitioning (EP):

Divide the input data into groups (or "partitions") where the system is expected to
behave similarly for every input within the same group.

Example:

· If an application accepts ages between 18 and 65:

o Partition 1: Valid inputs (18–65)

o Partition 2: Invalid inputs (<18)
o Partition 3: Invalid inputs (>65)
 Test cases could be: 20 (valid), 15 (invalid), 70 (invalid).

Goal:

· Minimize the number of test cases by selecting representative values from each partition.

Boundary Value Analysis (BVA)

 97
This technique is capable of identifying the flaws of the limits of the input values
rather than focusing on the range of input value. Boundary Value Analysis also deals
with edge or extreme output values.

Example:

· For the same age range (18–65):

o Boundary test cases: 18, 19, 65, 64, 17, 66

o These values test the boundaries and immediate neighbors.

Goal:

· Detect errors at the extreme ends of the input domain.

 98

MODULE - 5
RISK, QUALITY MANAGEMENT AND REENGINEERING

Risk:-
Risk in the software development lifecycle refers to the possibility of uncertain
events or conditions that could negatively impact the project's objectives, such as
quality, timelines, budget, or performance.
RISK MANAGEMENT:-

Risk management in software development is the process of identifying, assessing,

prioritizing, and mitigating risks throughout the software lifecycle to minimize their
impact on the project's objectives, such as scope, quality, cost, and schedule. It
involves proactive planning to handle uncertainties effectively and ensure project
success.

Reactive VS Proactive Risk strategies:

1. Reactive Risk Strategies

A reactive approach deals with risks after they have occurred. It's a "wait and see" strategy, where
the focus is on damage control.

Characteristics:

 Post-event focus: Risks are addressed once they materialize.

 Crisis management: Involves managing the impact of issues like system failures, bugs, or
security breaches.
 Short-term solutions: May involve quick patches, workarounds, or emergency fixes.
 Example scenarios:
o A bug is discovered in production, and the team deploys a hotfix.
o A security vulnerability is exploited, prompting immediate patches.

Advantages:

 Lower upfront effort: No resources are spent on risks that may never occur.
 Fast response to specific incidents.

Disadvantages:

 Higher costs: Fixing issues post-occurrence can be costly and time-consuming.

 99
 Customer impact: Delays or service interruptions may harm user experience.
 Reputational damage: Issues like security breaches can hurt the company’s image.

2. Proactive Risk Strategies

Proactive strategies aim to identify and mitigate risks before they occur. It’s about anticipation and
prevention.

Characteristics:

 Prevention focus: Risks are systematically identified and addressed during the development
process.
 Long-term planning: Emphasis on creating robust systems that minimize potential risks.
 Example scenarios:

o Conducting regular code reviews and static analysis to catch bugs early.
o Implementing automated tests and continuous integration (CI) pipelines.
o Investing in security audits and penetration testing.

Advantages:

 Cost savings: Early detection and prevention of risks are often cheaper than fixing problems
later.
 Improved quality: Reduces the likelihood of major disruptions, enhancing system
reliability.
 Customer trust: Fewer issues in production enhance user satisfaction.

Disadvantages:

 Higher upfront effort: Requires time and resources for risk assessment and mitigation
planning.
 Possible over-preparation: Some risks may never materialize, leading to unnecessary work.

* The primary goal is to prevent risk, but because no risk can be eliminated entirely, *
The team is working to establish a contingency plan that will enable it to react in a
controlled and efficient manner in the event that a risk is encountered.
Software Risks:

1) Project Risks
 100
 Risks that affect project management, timelines, and resource allocation The project
scope expands without corresponding adjustments to time or budget..

2) Technical Risks

 Risks related to the technology, tools, or methods used in the project The system
may not meet performance requirements under high load.

3) Operational Risks

 Risks that impact the day-to-day operations or processes of the software Downtime
or crashes in production environments.

4) Security Risks

 Risks that compromise the confidentiality, integrity, or availability of the system or

data. Unauthorized access to sensitive information.

5) Business Risks

 Risks that impact the business value or strategic goals of the software. The product
doesn't align with customer expectations..

6) Process Risks

Risks related to the software development process itself. Misunderstandings

between stakeholders, leading to errors.

Risk Mitigation, Monitoring and management [RMMM]:

Risk Mitigation, Monitoring, and Management (RMMM) is a structured approach used in

software engineering to handle risks throughout the project lifecycle. It ensures that risks are
proactively identified, monitored, and managed to minimize their impact on the project's success.

Components of RMMM

Risk Mitigation
Focuses on reducing the likelihood or impact of identified risks before they occur.

Strategies:

1. Avoidance: Change project plans to eliminate the risk.

Example: Avoid using unproven technology that could cause delays.

 101
2. Reduction: Implement measures to lower the risk's probability or impact.

Example: Introduce automated testing to reduce the chance of defects.

3. Transfer: Shift the risk to another party.

Example: Outsource complex components to specialized vendors.

4. Acceptance: Acknowledge the risk and prepare to handle its impact if it occurs.

Example: Allow for potential delays and allocate contingency time.

Risk Monitoring
Involves tracking identified risks and detecting new risks as the project progresses.

Key Activities:

1. Regular status reviews: Periodic evaluation of risk status in team meetings.

2. Performance metrics: Use indicators like test failure rates, bug counts, or schedule
variances to identify emerging risks.
3. Risk audits: Scheduled reviews to assess the effectiveness of risk mitigation actions.
4. Early warning systems: Automated alerts when predefined thresholds (e.g., server
load, project delays) are exceeded.

Risk Management
Encompasses the decision-making and corrective actions required to handle risks effectively.

Key Activities:

1. Risk prioritization: Continuously update the priority of risks based on changing

project circumstances.
2. Contingency planning: Prepare response plans for high-priority risks.

Example: Have a rollback strategy in place for software deployments.

3. Issue resolution: Address risks that materialize as issues.

4. Stakeholder communication: Keep all stakeholders informed about risk status and
actions.

RMMM Process Workflow

1. Risk Identification: Identify risks using methods like brainstorming, risk checklists, or
historical data.
2. Risk Assessment: Evaluate the probability and impact of each risk.
 102
3. Risk Prioritization: Rank risks based on their severity (high, medium, low).
4. Risk Mitigation Plan: Develop strategies to address high-priority risks.
5. Implementation of Mitigation: Execute the planned actions.
6. Monitoring and Reporting: Continuously track risks and update stakeholders.
7. Management and Response: Take corrective actions if risks evolve into actual issues.

Example of RMMM in Practice

Scenario: Developing an e-commerce website.

1) Identified Risk: The payment gateway might fail during peak usage.
2) Mitigation Plan:

Use load testing tools to simulate high traffic and optimize the gateway's
performance.

Integrate a secondary payment gateway as a backup.

3) Monitoring:

Set up monitoring for transaction success rates and server load.

Trigger alerts if the success rate falls below 95%.

4) Management:

If the risk materializes, automatically switch to the backup payment gateway

and investigate the root cause.

Benefits of RMMM

 Proactive risk handling: Reduces the chance of major disruptions.

 Better resource allocation: Focuses time and resources on high-priority risks.
 Improved project outcomes: Increases the likelihood of delivering on time, within budget,
and with expected quality.
 Enhanced stakeholder confidence: Keeps all parties informed and prepared for potential
risks.
 103
Software Quality Assurance

Software Quality Assurance (SQA) is a systematic process that ensures software products and
processes meet predefined quality standards throughout the software development lifecycle (SDLC).
It encompasses a range of activities, including planning, monitoring, testing, and improving
software quality to ensure the product meets customer expectations and complies with
organizational and regulatory standards.

Key Objectives of SQA

1) Ensure Quality

Deliver software that meets functional and non-functional requirements (e.g.,

performance, security).

2) Prevent Defects

Identify potential defects early in the development process to reduce cost and
time of fixing issues later.

3) Improve Development Process

Enhance software processes to produce consistent and reliable results.

4) Ensure Compliance

Ensure adherence to industry standards, regulations, and organizational policies.

Key Components of SQA:-

1) Quality Management:

Quality Planning: Define quality standards and establish processes to achieve them.

Quality Control: Monitor specific project outputs to ensure they meet the defined standards.

Quality Improvement: Continuously improve processes and products.

2) Standards and Procedures

Develop and enforce guidelines for software development and testing.

 104
Use industry standards like ISO 9001, IEEE, or CMMI for quality frameworks.

3) Verification and Validation (V&V)

1. Verification: Ensures that the product is being developed correctly (e.g., design
reviews, code inspections).
2. Validation: Ensures the final product meets user needs and expectations (e.g., user
acceptance testing).

4) Testing

Includes various types of testing like unit testing, integration testing, system testing,
and performance testing to identify defects.

5) Audits and Reviews

Conduct internal and external audits to ensure compliance with processes and
standards.

Regular code reviews, design reviews, and project status reviews to catch potential issues
early.

SQA Activities:-

Requirement Analysis

Ensure that software requirements are clear, complete, and testable.

Design and Code Reviews

Conduct peer reviews to ensure design and code quality.

Testing Strategies

Plan and execute various levels of testing (unit, integration, system, acceptance).

Defect Tracking and Reporting

Use tools to track defects from discovery to resolution.

Process Monitoring

Ensure that software development follows the defined processes (e.g., adherence to
coding standards).
 105
Risk Management

Identify, assess, and mitigate risks that could impact software quality.

Benefits of SQA:-

Improved Product Quality

Ensures the software meets functional and non-functional requirements.

Cost and Time Savings

Detecting and fixing issues early reduces the cost and time required for later-stage
corrections.

Customer Satisfaction

Delivering high-quality software enhances user trust and satisfaction.

Reduced Risk

Minimizes the likelihood of failures, security breaches, or regulatory non-

compliance.

Enhanced Team Efficiency

Well-defined processes and tools streamline development and testing activities.

Challenges in SQA:-

Resource Constraints

o Limited time, budget, or skilled personnel can impact quality assurance activities.

Changing Requirements

o Evolving project requirements can make it difficult to maintain consistent quality.

Integration Complexity

o Ensuring quality across integrated systems and third-party components can be

challenging.
 106
Resistance to Process Changes

o Teams may resist adopting new quality standards or tools.

FORMAL TECHNICAL REVIEWS

Software developers carry out this task as part of their software quality assurance
process.
The FTR's goals are to:
- Identify errors in any software representation's logic, function, or implementation;
- Verify that the software under review meets its requirements;
- Ensure that the software has been represented in compliance with established standards;
- Generate software that is developed consistently; - Simplify projects.
• The FTR class of reviews includes walkthroughs, inspections, round-robin
reviews, and other small-group technical software evaluations.

FTR- Review meeting

• The normal number of attendees for a review meeting should be between three
and five people; • The number of participants in the review should fall anywhere
between three and five.
• There should be some level of advance preparation, but the amount of effort
required from each individual should not exceed two hours.
• The time allotted for the review meeting must be significantly shorter than two
hours.
• FTR concentrates on a particular (and relatively insignificant) portion of the
software as a whole. • For instance, rather than attempting to examine the complete
design, FTRs are carried out for each component or small group of components. •
Each and every review meeting ought to be constrained by the following guidelines:
• Typically, the evaluation should include participation from between three and
five different people.
• There should be some level of advance preparation, but the amount of effort
required from each individual should not exceed two hours.
• The time allotted for the review meeting must be significantly shorter than two
hours.
 107
• FTR concentrates on a particular (and relatively insignificant) portion of the
software as a whole. • For instance, rather than attempting to examine the complete
design, FTRs are carried out for each component or small group of components.

Review Reporting and Record Keeping

1. • A reviewer records the FTR by acting as the recorder and actively noting every concern
raised. These notes are compiled at the end of the review meeting, and a list of review issues
is created.
•A review summary report addresses the three inquiries listed below:
1. What was examined specifically?

2. Second, who wrote the review?

3. What were the investigation's conclusions and outcomes?

• The review summary report is sent to the project leader and any other parties interested in
the work, and it is included in the project's historical record.

• The review issues list fulfills two purposes:

1. To identify the specific areas of the product that are producing problems
2. to serve as a reference point for action items that the producer can use as direction
while making adjustments.

• Creating a follow-up procedure is crucial to ensuring that the problems listed on the list
have been appropriately fixed.
• The summary report usually comes with a problems list.
An issues list is typically included in a summary report. Should this not be done, there's a
chance that the issues raised will "fall between the cracks."
• Giving the person in charge of the review the responsibility for follow-up is one tactic.
 108

SOFTWARE RELIABILITY
Software reliability is defined statistically as "the probability of failure-free operation of a
computer programme in a specified environment for a specified amount of time."
•What does it really mean to be unsuccessful in something?
–Failure in the context of any discussion about the reliability and quality of software is defined
as nonconformance to software requirements.
It is likely that correcting one error can cause others to arise, which will then cause more errors,
which will ultimately result in further failures.
•When development and historical data are combined, software reliability may be
tracked, directed, and evaluated.

Measures of Reliability and Availability

The mean-time-between-failure (MTBF) approach is a simple way to assess a system's reliability.

MTBF = MTTF + MTTR.
Two distinct acronyms for the same idea are mean-time-to-failure (MTTF) and mean-time-to-repair
(MTTR).
• Defects per KLOC or problems per FP are not nearly as relevant as the mean time
between failures,MTBF.

In other words, an end-user is not concerned with the overall number of errors; rather, they are only
concerned with the number of failures. Because each individual fault identified within a program
has a different failure rate, the total error count is not a very trustworthy predictor of the
dependability of a system.
•In addition to our current dependability metric, we also need to build an availability meter.
 109
• Software availability is the likelihood that a programme is working according to the
requirements at a given point in time. The formula for calculating availability is as
follows: Availability = [MTTF/(MTTR + MTTF)] 100%.
• The sensitivity of the MTBF reliability measure to the MTTF and MTTR is the same.
• The availability measure is somewhat more sensitive to the MTTR, which is an
indirect indication of the maintainability of software.
 110

Reengineering Introduction
• Regardless of application size, complexity and domain environment modification
occurs.
1. Due to new feature demanded by customer.
2. Due to errors.
3. Due to new technology
• We have to maintain when it is necessary and we have to re-engineer right.
• What is it?
• Who does it?
 111
• Why it is important?
• What are the steps?
❖ Maintenance correct the defects, adopts new functionality as per user needs and
changing env
❖ At strategic level BPR identifies and evaluates the existing business process and
create revised BP that better meet the current goals
• What is the work product?
❖ Variety of maintenance and re-engineering work products are produced eg:
usecases, analysis and design model, test procedures
❖ The final output is upgraded software
• How do you ensure that you have done right?
❖ Use SQA practices that are applied to every SE process
✓ Technical reviews assess the analysis and design models
✓ Specialized review consider the business applicability and compatibility ✓
Testing is applied to uncover the errors in content functionality etc.
Re-Engineering Advantages
✓ Reduced risk
✓ There is a high risk in new software development. There may be development
problems, staffing problems and specification problems.
✓ Reduced cost
✓ The cost of re-engineering is often significantly less than the costs of developing
new software.
Business Process Re-Engineering
• BPR extends for beyond scope of IT and SE
• Concerned with re-designing business processes to make them more responsive
and more efficient.
Business Process:
• BP is a set of logically related tasks performed to achieve a defined business
outcome.
• Within the BP people, equipment, material resources and business procedures are
combined to produce s specified results.
• The overall business can be segmented as fallow
Business ->Business System->Business Process->Business Sub-process.
 112

•
BPR can be applied to at any level of hierarchy but as the scope of BPR
broadens, risk associated with BPR grows dramatically.
BPR Model:
- *BPR is an Iterative Model*: The BPR process is evolutionary and does not have a
fixed start or end. It adapts continuously to changes in the environment.
- *BPR Model Activities*:
1. *Business Definition*:
- Identify business goals based on four key drivers: cost reduction, time reduction,
quality improvement, and personal development/empowerment.
- Goals can be defined at the overall business level or for specific business components.

2. *Process Identification*:
- Determine which processes are necessary to achieve the identified business goals.
- Rank these processes by importance, need for change, or other relevant criteria.

3. *Process Evaluation*:
- Analyze and measure the current process thoroughly.
- Identify tasks within the process and note the cost, time consumption, and performance
issues.
4. *Process Specification and Design*:
- Develop use-cases based on information from the previous activities.
- Define scenarios within these use-cases that reflect outcomes for the customer.
- Design new tasks and processes to address identified needs.
 119

5. *Prototyping*
:
- Create a prototype of the redesigned business process.
- Test the prototype to make necessary refinements before full integration.

6. *Refinement and Instantiation*

:
- Refine the business process based on feedback from the prototype.
- Implement the refined process within the business
system.

❑ BPR activitiesare sometimesused in conjunction withworkflowanalysistools.

❑ The intent of this tool is to build model of existing workflow in an effort to better
analyzeexisting process.
SoftwareRe-Engineering
• The scenario is all to common
• Reorganizingand modifyingexisting softwaresystemsto makethem more
maintainable.
Objectives:
• Describe the steps involved in the software
-engineering
re process;
-engineering
• Make a distinction between software and data re and address the issues with the
latter;
• Explain why software -re
engineering is a financially advantageous alternative for system
evolution.
SoftwareRe-EngineeringProcessModel:
 114

•
Re-engineering takes time, it costs significant amounts of money, and it absorbs
resource.
For all these reason re-engineering is not accomplished in a few months or even a
few years.
• Re-engineering of information system is an activity that will absorb IT
resources for many years. That’s why every organization needs a
pragmatic strategy for software re-engineering.
• A workable strategy is encompassed in re-engineering process model.
• Re-engineering is a rebuilding activity.
Eg: Rebuilding of a house
❖ Before you can start rebuilding, it would seem reasonable to inspect the house.
❖ Before you tear down and rebuild the entire house, be sure that structure is weak.
❖ Before you start rebuilding be sure you understand how the original was built.
❖ If you begin to rebuild, use only the most modern, long lasting materials.
❖ If you decide to rebuild be disciplined about it.
Software Re-engineering Activities:
• The scenario is to common to all: An application is served the business
need of a company for 10 or 15 years.
• During that type it has been corrected, adapted and enhance many times.
 116

•
Re-Engineering activities paradigm is a cyclical model that means each activities
presented as a part of paradigm can be re visited.
Totally we are having 6 software re-engineering activities.
❖ Inventory analysis:
• Every software org should have a inventory of all application.
• Inventory is nothing but spread sheet type of document.
• By sorting the info according to business critically, longevity etc..
• Resources can then allocated to candidate application for re-engineering
work.
• This inventory should be revised on a regular cycle as a status of
application change.
❖ Document Restructuring:
• Weak document is trademark for many legacy software. What you can do about
it? And what are your opt?
➢ Creating document is far too time consuming:
▪ If a system is working you just go for live with what you have.
▪ In some cases this is correct approach why because it is not possible to re-
create document for hundreds of computer program.
▪ If the program is static document will end otherwise it wont.
➢ Document must be updated, but your org have limited resources:
▪ Here we use a “documented when touched” approach it will not necessary to
fully document an application.
▪ Rather than that those portions of the system that are currently undergoing
change are fully documented.
➢ The system is business critical and must be fully re documented.
▪ Even in this case an intelligent approach to pare documentation to as essential
minimum.
❖ Reverse engineering:
• The term RE has its origin in the hardware world.
 117

•
• A company disassemble a competitive hardware product in effort to understand
its competitor design and many of secrets.
• These secrets can be easily understood whenever the specifications obtained.
• But these documents are proprietary and not available for re engineering.
Because of this SE derives one or more design and manufacturing specification
for a product by examining the actual outputs.
Sometime RE is done company’s own work to understand the specification.
• Therefore RE is the process of design recovery.
• RE tools extracts data, architecture and procedural design info from an existing
system.
❖ Code Restructuring:
• The most common type of re-engineering code restructuring.
• Legacy system have solid program architecture but individual modules coded in
way that makes them difficult to understand, test, maintain.
• In this case code within the suspect module can be restructured.
• To accomplish this task source code can be analyzed by using restructuring tools.
• Violations in structure programming are noted and then code is restructured(this
can be done automatically) or re written in modern language.
• Resultant code can be reviewed and tested to ensure that no anomalies have been
introduced.
• Internal code document is updated.
❖ Data restructuring:
• A program with weak data architecture will be difficult to adopt and enhance.
• Code restructuring will occurs at low level but data restructuring is full scale re-
engineering actually.
• In most case DR begins with RE actions
• Current data set are dissected and necessary data model are defined.
• Data objects and attributes are identified and existing data structure are reviewed
for quality.
• When data architecture is weak the data are reengineer because it is has strong
influence in either architecture and code level changes.
❖ Forward engineering:
 118

•
• Application can be rebuild using automated RE engine.
• The old program fed into the engine analyzed, restructured and regenerated
in a form that exhibit the best aspect of software quality.
Reverse Engineering
• Undocumented source file converted into fully documented source code.
In reverse engineering designer must extract the design info from source code but
❖ Abstraction level
❖ Completeness of the documentation
❖ The degree to which tools and a human analyst work together ❖ The
directionality of the process are highly variable.
• The abstraction level and completeness can be extracted from source code.
• The RE process should be capable of deriving
❖ procedural design representation(LL)
❖ Program and DS info(somewhat HL)
❖ Object model(HL)
• As a abstraction level increases you are provided with info that will allow easier
understand of the program.
• The completeness of RE process refers to the level of details that is provided at
an abstraction.
• Completeness improve direct proportion to the amount of analysis performed by
the person doing RE
• Interactivity refers to degree to which the human is integrated with automated
tools to create effective REP.
• In most cases as AL increases interactivity must increase or completeness will
suffer.
• If the directionality of REP is one way all the info extracted from the source code
is provided to the SE who can use it during any maintenance activity.
• If directionality is two way the info is fed into RE tools that attempts to
restructure or regenerate old program.
• Before Re-Eng commences unstructured source code is restructured
 119

•
• This makes source code easier to read and provides the basis for all subsequence
RE activity.
• You must evaluate the old program from the source code and develop
❖ Meaningful specification
❖ User interface applied
❖ Program DS or database i.e used
Reverse engineering to understand data
• RE of data occurs at different level of abstraction often it is first RE
task.
 120

•
At the program level internal program DS must often be RE as a part of overal
Re-engineering efforts.
• At the system level global DS can be evaluated.
Internal DS:
• RE tech for internal program data focus on the def of classes of objects.
• In many cases the data org within the code identifies abstract data types.
Database structure:
• Regardless of logical org and physical structure DB allows the def of object
and support some methods to establishing relationship among the objects.
• Therefore re-eng one DB schema into another requires an understanding of
existing object and relationship.
• Following steps may be used to re eng to new DB
❖ Build initial object model
❖ Determine candidate key
❖ Refine tenative class
❖ Define generalization
❖ Discover association using CRC tech RE to understand processing:
• RE to understand processing begins with an attempt to understand and than
extract procedure abstraction presented in source code.
• To understand the process abstraction the code is analyzed at varying level of
abstraction.
• Each program that makes the application represent functional program at high
level of abstraction.
• Block diagram can be created.
• In some cases system program and component specification already exist in this
situation the specification can be reviewed.
• Things become more complex when we look at the section of code that represents
generic procedural pattern.
• Almost in every component a section of code prepares data for processing(within
the module)

•
 121

•
Different section of code does processing and section of code prepares result of
processing for export.
For large system RE is generally accomplished by using semi automated
approach.
• Automatic tools is used to understand the semantics of the code
• Output of this then passed to restructuring and FE tools to complete re-eng
process.
RE user interface:
• Sophisticated GUI have become mandatory to computer based and other based
system.
• Before user interaction be built RE should occur
• The structure and behaviour of the present user interface need to be defined in
order to gain a complete understanding of it.
• Before the start of UI, Merlo and his coworkers present queries that can have their
answers provided.
• What are the fundamental operations that need to be processed by the interface?
• What is a succinct description of the way the behaviour of the system reacts when
it is exposed to the action?
• What exactly do we mean when we talk about replacement, and how exactly does
the idea of equivalence of interface apply to this situation?
• The answers to the first two questions can be found by modelling behaviour.
• It is frequently to one's advantage to conceptualise new interaction metaphors

Restructuring
• Software restructuring modifies source code and/or data in effort to make future
changes.
• This restructuring doesn't modifies the entire program architecture.
• Mainly it focus on the design details of individual modules and local data
structure within the module.
 122

•
• If suppose restructuring efforts extends beyond the boundaries of module and
encompasses the software architecture restructuring becomes Forward
engineering.
• Restructuring occurs when the basic architecture of an application is solid, even
through technical internal need to work.
This step initiated when major parts of software are serviceable and only subset of
all modules and data need extensive modification.
Code Restructuring:
• CR is performed to yield a design that the same function but with higher quality
than the original program.
• In general CR technology model program logic with Boolean algebra and then
apply a series of transformation rules that restructures logic.
• A resource exchange diagram is a map that depicts each programme module as
well as the resources that are traded between that module and the other modules.
• The programme design can be changed to ensure minimum coupling among
modules if the representation flow is first created. This will allow for more
flexibility.
Data Restructuring:
• The process of reverse engineering, also known as analysis of code, needs to be
carried out before DR can get underway.
• The evaluation of all PL statements takes place, whether or not they contain data
definition, file descriptions, I/O, or interface description.
• The purpose of this activity, which is known as data analysis, is to extract data
items and objects in order to obtain information on data flow and to gain an
understanding of the existing data structures that have been put into place.
• The process of data redesign begins once the examination of the data has been
finished.
• Data record standardization step clarifies data definition to achieve consistency
among data items names or physical record format within the existing DS or file
format

•
 123

•
• Another form of redesign called data name rationalization it ensure that all data
naming conventions conform to local standards that aliases are eliminated as data
flow through the system.
• When restructuring move behind the standardization and rationalization physical
modification can be done to existing one in order to make the data design more
effective.
This means that translation from one file format to another or in some cases
translation from one type database to another.
 124

•
Forward Engineering
• A program with control flow that is the graphic equivalent of bowl of spaghetti
with modules.
❖ You can struggle through modification after modification, fighting the ad
hoc design and source code to implement the necessary changes.
❖ You can attempt to understand inner working of program in broader way to
make modification more efficiently.
❖ You can redesign, recode and test those portion of the software that require
modification and apply SE approach.
❖ You can completely redesign or recode and conduct test to understand the
current design.
• There is no single correct option circumstances may dictate the first option even
if others are more desirable.

• Rather than waiting until a maintenance request is received the development or

support org uses the results of inventory analysis to select a program that ❖ Will
remain in use for a number of years.
❖ Is currently being used successfully.
❖ Is likely to undergo major changes or enhancement in near future.
• The suggestion that you redevelop a large program when a working version
already exists before passing the judgment consider the following points.
❖ The cost to maintain one line of source code.
❖ Redesign of SA using modern design concepts.
❖ Bcz prototype of software already exist, development productivity much
higher than average.
❖ Now user has experience with software therefore new req and directions
change can be ascertained with greater ease.
❖ Automated tools for reengineering will facilitate some parts of the job.
❖ A complete software configuration exist upon completion of preventive
maintenance.

•
 125

• FE applies the software engineering principles, concepts and methods to re create

an existing application.
In most cases FE does not simply create modern equivalent of existing program
rather new user and tech req are integrated into the reengineering effort.
• So that the redeveloped program extends the capabilities of the older application.
Forward engineering for client server architectures
• Although a variety of different distributed environment can be designed, the
typical mainframe application that is reengineered into a client server architecture
has the following features.
❖ Application functionality must migrate to each client computer.
❖ New GUI are implemented at client sites. ❖ Database function are
allocated to server.
❖ Specialized functionality may remain at server site.
❖ New communication, security, archiving and control requirement must be
established at both the client and server sites.
• Reengineering for client-server application begins with analysis of the
business environment that encompasses the existing mainframe.
• Three layers of abstraction can be identified
1. The database sits
2. The business rules layer
3. Client application layer The database sits:
• It is foundation for client server architecture and manages the transactions and
queries from server application.
• Yet this transactions and queries can be controlled within the context of business
rules.
• The function of the existing DBMS and data architecture of existing DB must be
reengineered to redesign DB foundation layer.
Business rules layer:
• Represents software resident at both the client and server.
• This software performs control and coordination tasks to ensure that transactions
and queries between the client application and database conform to the
established business process.
 126

•
In many cases mainframe application can be segmented into set of desktop
application that is controlled by business rules layer.
Client application layer:
• it implements the business function that are required by specific group of end
user.
Forward engineering for object oriented architectures
• First we do reverse engineering to the existing system so that the appropriate
data, functional and behavioral models can be created.
• If the re engineered system extends the functionality or behavior of original
application usecase are created.
• The data models created in reverse engineering are then used with conjunction
with CRC modeling to establish the basis definition of classes.
• Class hierarchies, object-behavior models and sub systems are defined and object
oriented design commences.
• As object oriented FE progresses from analysis to design