Software quality Engineering Lecture :05

Bismillahirrahmanirrahim. Welcome to fifth lecture of the course software quality Engineering. As you
are aware that we are in the first part and we are discussing the basics and we are giving you an
overview of what software quality engineering is. Before we formally start today's lecture, let us have a
look at on the summary of the previous lecture. If you precisely remember, we talked about quality
assurance classification. We discussed that quality assurance deals in detect defect prevention, defect
detection, and defect recovery. So if these activities are performed We say that quality assurance is being
done. There was another activity in quality assurance and that was defect contentment, defect
controlling. So mainly we talked about the work of quality assurance that first of all defect should be
controlled.

First of all, you should not allow defects to come. You should take such careful measures in which you
prevent defects, errors, bugs, failures as much as possible from coming. But this situation is not always
possible and sometimes During the development of the system, or after some time, it is known that
there is a defect in the system. Now, due to the defect in the system, the performance of the system is
being affected. So, to restore the performance of the system, you first need to detect, you first need to
identify, you first need to analyze where the problem is. where the defect is actually lying. So, you find
the defect. When the defect is found, then you remove the defect. So, prevention is done.

If some defects come despite prevention, then they are detected, analyzed or identified and After this
identification, after finding the defect, then you remove the defect. We had also said that sometimes the
effects of defect can go far. They can affect other things too. So then you do defect containment, you
control the defect. If you remember, we discussed through a figure that if there are errors, you try to
remove those errors. You exclude the errors. You exclude the bugs. Because of that error, another fault is
being created. And because of the fault, failures are coming. So, we have discussed the failures. If there
are a lot of failures in the system, then these failures result in low system usage. People stop using the
system.

So then what do we do? If the failure is more or the defect is more, then you try to control it or you do
defect containment. Apart from this, we have some other things related to software quality engineering.
We also took an overview of similar terminologies. And we looked at different things like defect
prevention, overview of defect prevention, overview of testing, overview of fault, and overview of safety.
We took an overview of what role this plays in software quality engineering. If you remember the slides
from the previous lecture, we discussed this in testing. Usually validation and verification is done. In
testing, you want to see whether your software is performing the things that it should perform.
Validation, V. And on the second number, and this thing, validation,

Black box testing also says that you have given the input, you are not concerned about how the input is
being executed, you only see the output. So if the desired output is being produced against the input, it
means that the black box testing has been successful and your software is performing the required
function properly. So validated. And we also do verification in testing. And verification means that the
work that was required, is it performing in the same way as it was required? Which I say again and again,
are we doing the right things in the right way? So what is right way? Right way is your verification. How
do you verify? In testing, you Let's verify with white box testing. White box testing means that you check
the internal components of that software.
You check that the required input, the way it was to be executed and the output that was to be
displayed, are all these things working properly? I can give you another example of black box testing and
white box testing. You have made a software which takes some integer from the user, let's say from the
user, its salary input and on the basis of that salary, it shows its tax output, its deductible tax amount. So,
black box testing shows whether the user paid the salary and whether the taxable amount was produced
correctly or not. If it was, then the black box testing is successful. While white box testing shows each
and every detail that the salary was an integer. How much is the length of the integer, the percentage
formula, the taxable amount, the type of the integer, the character, the length of the variable character

So, whether you are dividing it by zero in your formula, which goes to infinity. So, all these internal
details are checked by your white box testing. It is also called white box testing. It is also called
verification. So, these two things are performed in your testing. Apart from this, we also talked about
fault and we also talked about safety. We also talked about that like against your software, safety
hazards. What is it that can harm the software? Imagine that you have a software that is interacting with
a hardware. That hardware is an outdoor display. Let's say there is a CCTV camera. The images of the
CCTV cameras that are displayed in the street, your software has to take them. Now, for your software,
directly

there can be some hazard or not but for the external hardware display the hazard is like extreme sunlight
or extreme rain or an obstacle in front of it and it can't capture the images so what do you do in safety?
you analyze the hazards and all the hazards for your software, direct hazards and indirect hazards check
and then accordingly you will take the remedial actions. So this was the brief summary of our previous
lecture. Let us proceed to the outlines of today's lecture. Today we will talk about quality assurance
context. Apart from this we will talk about quality in software processes. We have software processes
may have a waterfall model, spiral model, incremental approaches. So, as an example, we will take a
waterfall model and see how the quality can be checked here.

After this, we will see V and V view, validation and verification view, and DC view, and Inko bhi hum apas
mein compare karenge, contrast karenge aur yeh dikhenge ke quality assurance mein VNV view aur DC
view kaise ahem role play karte hain. Aaj ke lectures ke objectives mein yeh shamil hai ke hopefully by
the end of today's lecture you will be able to understand and distinguish between validation and
verification view and DC view of the software quality engineering. So, you have to keep this in mind in
the next lecture that you have to identify what is V and V view and what is DC view. And how they play a
role in quality assurance and ultimately in software quality engineering. Let us first talk about the quality
assurance in context.

Quality assurance and the overall development context, which includes a lot of things. You also get
defect handling and resolution. Defect handling includes all these things, that you prevent defect, you
detect defect, you remove defect. So, how are you actually dealing with defect? How do you deal with
defects? Defects in any system are absolutely normal. You cannot imagine the development of any such
system. It would be impossible to develop a system or develop a software which has got zero defect.
There won't be any system with zero defects. Certainly, when you develop a system, a software, defects
will occur. How do you actually deal with defects? This is a very important work of quality assurance. And
how do you resolve defects? What solution do you provide for it?

This is also very important. Apart from this, we also saw that there are different types of activities and
different types of processes in Quality Assurance. But the alternate perspective of Quality Assurance is
Verification or Validation, V and V-View. So, in Quality Assurance, you are ultimately checking whether
we are doing the right things in the right way. So, are we doing the right things? Validation. In the right
way? Verification. So, validation and verification view. So, quality assurance mainly checks that the
functionality, the operability, the features required by your software are performing well. and if they are
performing in the same way then in the next slides we will look at it in detail. We are talking about
defect handling and resolution. Remember that defect handling and resolution

It is not a single step or a single phase. Rather, it is comprised of some other phases or some other
actions that are also performed. Like, first of all, status and tracking. As we discussed earlier, you first
need to detect the defect. Find out where the problem is. Find out where the problem is. Find out the
status. Is the defect currently active or inactive? Currently, what are the things it is affecting? You are
also tracking the defect. So, you are looking at the defect in different ways. So, status and tracking is also
a way of defect handling. Apart from this, you can do casual analysis. We also do casual analysis which is
also called root cause analysis. It is very important to reach the root cause of the problem.

If you do not reach the root cause of the problem, obviously you will solve the problem. But if you do not
address or solve the root cause, so it will propagate into other parts of the system. For example, you can
take the development of a software in which you will give a query to a database and it will retrieve a
record. Now, whenever you give a query, you give a correct query. science is fine, but records are not
being displayed. So, what is the reason for this? The query is fine, but the database has records, but the
records are not being displayed. So, what is the problem? Where is the problem? This is very important
to know. It is possible that you are trying to retrieve that information,

record is not accommodating in the variable or the temporary location in which you want to store it. Or
it is accommodating but contents are not displaying. So there is an issue of display, retrieval, storage,
size. It is very important to know the root cause. And obviously, when you know the root cause, then you
resolve the defect and provide a solution to it. Providing a solution can be done in different ways. One
solution to the defect is to remove the defect. Remove the defect and the defect is resolved. Secondly,
you want to know how to re-write, re-phrase, re-code this defect. For example, if I try to explain it in a
simple way, you have a table and there is a defect in the table that when you put the table on a plane, it
is still shaking.

You can't sit and work comfortably on it. The legs of the table are not in the level. So what is the solution
for this? One solution is that you should not use this table, you should remove it. This table is not good.
If you put a glass of water on it, it will fall. If you want to do any writing on it, the writing will not be
good. Or if you put something else on it, it will slip and fall. So the way to resolve is that you remove this
table. You should not use it. new table. The second way to resolve this defect of the table is that you see
which is the leg of the table which is not in the level, whose length is comparatively longer or shorter
than the other legs of the table and then you solve that defect

address it, fix it, and then your table gets fixed. So, the resolution that I talked about, you can resolve the
defect by removing it, and you can actually solve the defect by resolving it. This can also happen in
software, that if you have a defect, if there are any errors, then either you have to remove it completely,
or actually know what the problem is. If integer It is not saving certain values. There is some problem in
coding. If you have coded in such a way that it is not able to store the integer properly, then one way is
that you remove that integer completely and store it in some other way. Or the second way is that in that
integer, first if its length
let's say 10 characters, then you make it 20 characters, 30 characters, so you can do both ways. Apart
from this, lastly, you don't forget the process of improvement. Improvement is also an ongoing process
in which you see that like, the casual chains, you break them. Meaning, the things that can cause
problems, can cause problems later, you break them. disconnect, you break the things that cause
problems and remove them. So, the improvement process is telling you that those things which can be
problematic later on in the life cycle of the software development, you simply break this chain, you
simply get rid of that. So, you disconnect that problematic thing from the rest of the system. So, overall,
you have improvement and you came towards improvement.

So that was quality assurance in the context. Let us talk about defect measurement and analysis.
Measuring defect is very important. I have given you many examples. There is a problem in a system.
How severe is that problem? What is the type of that problem? What impact can it have on other
components of the system? Is there any classification of the system? At what time does this problem
occur? All these things are known in defect measurement. All these things come under defect
measurement. So defect measurement or you can also call it defect handling. So actually you are trying
to know all types of details of that particular problem. What is in that all types of details? Like where
injected or where found? Where is that defect actually?

Is it in the code? Is it in the requirement? Is it in the design phase? It is in the interface, on the database,
on the front end, on the back end. Where is the problem? Where is it seen? Okay. Type, severity, impact.
It is also very important to know this fact. There may be a small bug. Spelling mistake. There is a button
on the interface and let's say the spelling of save is wrong on the button. S-A-V-E instead of S-A-F-E. Now,
Obviously it is a defect, but it is not that severe. It will not have much impact. Why? Because as long as
the button is pressed, the record is being saved. It is doing its work. But the defect is this. Whereas some
defects can be very severe.

Just like you divide any value in your mathematical formula by zero. By dividing it by zero, your system
can go into halt state. Or you had to copy some records from the system, and have copied the place, or
you have to relocate them, have cut them, and if you have not placed them in the right location, if you
have not moved them back, then all the records can be deleted. So, wrong command or wrong
placement of certain queries, which can result in the loss of data. Now, if it is a defect like this, then its
severity is very high. Similarly, you have declared an integer. It was enough to define the length of the
integer as 4 characters. But, if you have declared the length of the integer as 40 characters instead of 4,

So ultimately, you have to use a lot of system resources on the backend. By using the system resources,
the overall processing of your system is getting low. In this case, the severity of this small problem is very
high. And as I said, you define in type that this is a defect of the requirement phase. design phase defect,
coding defect, so you actually classify it. And if further classification is possible, let's say if it is of design
phase, so where is this defect of design phase? Is it in any entity relationship diagram ERD or in any data
flow diagram? If it is in data flow diagram, So, is it in level 0 DFD or level 1 DFD? So, these things you
need to know more, do measurements, and if possible, classify them.

Apart from this, consistent interpretation, timely defect reporting, all of these things are part of defect
measurement. Apart from this, defect analysis, we also have some quality models. In the previous slide,
we talked about the analysis of the defect. So, in the defect analysis, we have follow up to defect
handling. You have identified a defect and you have addressed the defect, whether it was an appropriate
solution or not. provide kiya, ya apne usko remove kiya, whatever. Ab iske baad, aap follow up karte
hain. Follow up ka matab ye hai, ki aap system ko dubara jaake dekhte hain, ki is defect ko remove kar
dene se, kya system ki performance theek hoi hai, ya nahi hoi. Thike, agar to system ki performance
theek ho gayi hai, iska matab ye hai, ki yes, you have rightly identified the defect, and you have rightly
addressed the defect.

Lekin, If you did not follow up, then the loss may be that the defect, you think that it has been removed,
but it may be that it has not been removed and it is still present in the system. I can tell you through an
easy example, follow up to defect handling phenomena. Let's say you have a car and there is a sound
coming from the engine. or the speed of your vehicle has slowed down. So, you go to the mechanic, the
mechanic analyzes it, identifies it, and this defect tells that your air filter is blocked, due to which the
vehicle is not getting proper air and fuel is not burning. So, the vehicle's peak, vehicle's speed, vehicle's
power has reduced. Now you have identified it.

You tell it to clean the air filter or install a new air filter. Now what is the follow-up? In the follow-up, it
comes that the air filter, which was defect, after addressing that, you run your car again and see if the
pick of the car is fixed or not. If the pick of the car is fixed or the power is resolved, it means that it was
the defect. But if the pick of the car is still not fixed, This means that there was no problem with the air
filter, the problem was something else and you provided a solution for it. So actually, we do this in
follow-up, we see that after handling that defect, after removing it, the performance of the system that
was expected, is it getting or not getting.

So you actually follow up. Similarly, which has relevant data and historical base lines. When did it come,
what time did it come, when did it come before this. You see all these things in the analysis model. What
is your purpose? The purpose of defect analysis or the goal is that you are actually predicting. You want
to bring improvement in your software. You are doing assessment in your software. You are looking at it
in different ways and want to know that there is improvement in my software, my software is working
properly, etc. etc. And lastly, you see how much is the reliability component in the system. We definitely
check the reliability in our software. And the purpose of looking at the reliability component is that you
bring extreme cases on it, do extreme testing.

And then let's see how the system responds or behaves on that extreme testing. For example, you have
written a software for a server and that software application can entertain 500 users per unit time. If 500
queries come simultaneously, then there is so much capability in the server and your software that it will
reply to it. So, you What do you do in casual and risk analysis or reliability? You bring 500 users or 500
queries to the server and see if the system crashes by bringing 500 or 500 plus users, 510, 520, 600
users. Is it possible that the system is completely halted? So, you can check the reliability of the system
in this way. So, overall you are doing the analysis of risk, you are actually checking the reliability of the
system.

Quality assurance in software processes. We know that different phases are involved in software
development or different processes are involved and we use different models. some of our mega
processes can be like the initiation of the project apart from this the requirement analysis of the project
similarly development similarly maintenance and project completion these are all the mega processes so
whether it is initiation or development or maintenance or project completion these are the mega phases
so you have created the quality Assurance should be done in every phase. The quality assurance in
initiation phase has its own details. Similarly, in requirement gathering or design phase, it has its own
details that how you will assure quality there. Similarly, when you are developing a project, for example,
you are coding, how will you ensure quality there?

It has its own details. So, quality assurance, actually, in every phase, you put it, in every kind of phase,
the required details are available, you follow them. Remember that there are no universal or common
quality assurance practices which you can use in every phase and for every kind of model. For example,
the technical details of quality assurance in the waterfall model for the design phase will be completely
different for some other model for some other phase. So, what I mean to say is that you have different
software process models, waterfall, spiral, and other models. Every model has different phases. Project
analysis, design, code, test. Here also, for example, requirement gathering, then design. Now, in every
phase, you will ensure quality assurance. You have to incorporate quality assurance in each

phase of the software process models. So, the components of the development process are
requirements and specifications, about which I have already told you. Let's talk further about quality
assurance in software process and as I just talked to you that we have different process variations,
different software process models. One of them is the waterfall model. One is iterative development
process. One is spiral development process. One is agile development or extreme programming. So we
have different types of models. Each model differs from the other model in its development phases,
completion phases. And we know from the perspective of software engineering that each model It can't
be suitable for every kind of software. In fact, every model is a suitable candidate. For example, if your
requirements are pretty much clear, you know the time, you know the available budget, so what do you
do?

Then you go to the waterfall model. If your requirements are vague and you expect that requirements
will keep on coming, so you make an iterative decision development, iterative software development
model. Similarly, you have agile development process. Similarly, if you have a scenario where you have to
deploy different teams simultaneously, you can go towards extreme programming, XB. So, because there
are different models of software development, different software development life cycle models, so,
There can be no universal or common quality assurance practices which you can apply on all these
models. In fact, there are unique quality assurance practices which you can apply. In some phases or
variations of the process, maintenance is also a process. The software is made, you deliver it to the
client, it is deployed there, the software is being used there.

Its maintenance is also required. How will you ensure quality in the maintenance phase? This is also a
very important aspect of quality assurance. For example, we talk about NADRA's software. NADRA is a
database software. Now this software is actually developed, deployed and NADRA has been using this
software for many years. But its time-to-time maintenance bhi chalti hai. maintenance ek ongoing
activity hai jo ke iss particular software par Nadra ke software par chalti rehti hai. Ab maintenance ke
phase mein quality assurance ki apni details hai, apni practices hai jo ke maintenance ke phase mein
apply hoti hai. Isi dana baaz processes hai jo ke mixed hai, ya synthesized hai, ya customized hai. So, To
conclude, the very important point is there are no universal or no common quality assurance practices
that can be used, that single quality assurance practice can be used and applied to all models.

Not like this. Based on the type of model, spiral, waterfall or iterative, we have to make sure that there
are certain quality assurance practices that must be applied. So, no matter what the process model is,
from the perspective of quality engineering, you have to ensure that quality assurance is a part of every
process. Okay, here as an example, Let's take the waterfall model. Now, why is it called a waterfall
model? It's like a waterfall that flows from top to bottom. So, your waterfall... The process is that you
start from above, from requirement analysis, requirement specification, then you come to design, then
you code, then you test, and then you release that software or give it to the client, and then the support
phase is also included in it.

Just like we discussed in the previous slide, the last point, that quality assurance is important in all
processes. So here we are talking about how to bring quality assurance in this waterfall model. So, if you
talk about the first phase, the requirement specification, then there also you will bring quality assurance,
you will do inspection, you will do reviews, there you will apply the relevant quality assurance activities
in your way. Similarly, if you are in the design phase, or you are going to the coding phase of design. So,
while going to the coding phase of design, you will also see that what you inspect here, you test, you
review, whether it is formal reviews or informal reviews. So, your purpose is to ensure quality.

Now, if you look at this diagram carefully, so in this, When you go from requirement specification to
design, there is a slash. What is this slash? This dotted line. This is showing you the process of inspection
or review. So this means that whenever you want to go from the requirement and specification process
to design process or analysis process, analysis phase to design phase, Before going to the design phase,
you must do specification, you must do formal reviews in order to perform quality assurance. And
similarly, when you go to coding from design, you will do inspection and reviews. When you go to testing
from coding, you will do inspection and reviews. And similarly, when you go to release and support from
testing, you will do inspection and review.

Okay, further notice that you do not only do inspection and review, but you also ensure your other
quality assurance activities. What are other quality assurance activities? As we discussed earlier, there is
defect prevention, defect removal, defect controlling or containment. So, here also we are doing the
same work. You will see that the dotted line below, It's a big dotted line. It goes from the requirement
specification phase to the coding phase. And it says, it focuses on defect prevention. So, you went from
each phase to the next phase, did inspections and reviews, and by combining three phases, overall you
focused on defect prevention. Similarly, when you go from coding to If you are going towards the testing
phase or talking about release and support, then you talk about defect removal.

And lastly, when you talk about release and support, when the software has been made, when the
software has been handed over to the client, then you talk about defect containment. You have to realize
that Why aren't you doing defect prevention in the coding and testing phase? Or when you have reached
the release and support phase, why aren't you doing defect prevention there? Why aren't you doing
removal there? The answer is very simple and that is, as long as you are in design and code, till then you
can prevent the defect but when your software is completed then you don't prevent the defect then if
there are any defects then you try to remove them and when your software is completed and given to
the client then you can't even remove the defect then you control the defect

Because removing the defect requires re-designing. Re-designing requires you to do re-requirement
analysis. So sometimes it is not possible to prevent or remove the defect. So what do you do? You
control the defect. So we are seeing the same thing here. If you are in the early stages, requirement
analysis, or specification, or design, or coding, there you try to prevent. Later on, if you have completed
coding, and you have come to the testing phase, there you do defect removal. Or, once the software is
completed, and is handed over to the client, and is released, and you are in the maintenance or support
phase, then you don't actually remove or prevent defects, you then you then But only thing you can do
on your software is to control the defects.

So, we discussed the example of waterfall model. Similarly, the activities of quality assurance, the other
activities or the main activities will be completely different for spiral model or iterative model. Quality
assurance in software processes, because we have got different process variations. If we talk about
iterative process, then quality assurance is also in iterations, increments. If we talk about spiral model,
then quality assurance works with risk management. If we talk about process model Extreme
Programming, XP, then quality assurance is used in the case of test-driven development. If we talk about
process model Mixed or Synthesized, then quality assurance is used in the case-specific sense. So,
depending on the type of software process model, quality assurance could be deployed or used
accordingly. So quality assurance, if we talk about the maintenance phase, the maintenance process,
when your software has been made, the client has been handed over, then what do you talk about?

Then you see exactly, focus on defect handling. The purpose is that you will see the defect, then you talk
about its containment. So one very important point is some defect contentment activities for critical or
highly dependable systems. Now some systems are very time sensitive. Let's say there is a banking
system, banking software, it is connected to database, people are purchasing with credit cards. If you
have developed that kind of software, and during maintenance, if a defect is identified there, then now
you cannot prevent or remove the defect. Because the time of prevention and removal has passed, now
you control it. Now you do its containment. And similarly, the findings that you get, un jo bhi aapne
defect containment ki uske baad dekha ki haan ji defect control ho gaya hai.

So, iss kisam ki details, ye data, aap later on quality assurance ki jo activities hai uske liya use karte hai
one very important point that should summarize all our discussion is that quality assurance is scattered
throughout all process theke How process model k how to phase make quality assurance apply Hogi it is
scattered throughout the development of the? software It is scattered throughout the life of the
software taken so how the phase may how process may opt equality assurance Hogi or you being a
software quality engineer, you need to make sure that quality assurance is included in it. Now let's talk
about validation and verification. Now core quality assurance activities are grouped into validation and
verification. We talked in the beginning that your main quality is revolving around validation and
verification.

Validation is that are we doing the right things and verification is that are we doing the right things in the
right way. And these are the core activities of quality assurance. Quality assurance is revolving around
validation and verification. Quality assurance simply makes sure that there is validation, the software is
validated and verified bhi hai. Ab agar aap requirement phase mein hai, agar aap requirement phase
mein hai, toh wahan pe bhi aap validation aur verification karenge. Agar aap design phase mein hai, toh
wahan pe bhi aap validation aur verification karenge. So agar aap requirement analysis phase mein hai,
toh aap what usually yeh software kya karega. which function this software will perform, what it will do
and what it will not do. So you are in that phase, requirement analysis phase.

What is validation there? Appropriate, you are checking appropriateness, fit for use, you are checking
right things. If it is a web software which has to retrieve some images, so we are not bothered, your
client is not interested, In the other irrelevant details, you simply see that what is required is happening
or not. Here in validation, you can do scenario and usage inspection or you can do testing. This means
that if I want to retrieve an image, if I give the name of the image in it, will it be displayed on my screen?
Yes or no? If it is displayed on the screen, It means that whatever I wanted, my software performed it.
So, validation happened. Similarly, system integration and acceptance testing is also done.

It means that my software had to bring a query from the database, had to retrieve some information and
based on that information, I wanted to retrieve the name of the employee. After retrieving the data, I
had to retrieve the employees' CV, profile, web link, or image. If this is happening, it means that
integration and acceptance testing has also been done. In addition, beta testing and operational support
also comes under validation. When you talk about verification, you want to know exactly how things will
work. What are the technical details? How do you talk about it? You don't take validation and verification
as an example. I told you about black box testing and white box testing. What is black box testing?
consider your software as a black box.

Black box means that you don't know what's inside. You simply give input. If the output is coming, here
you go. Your software is performing well. White box testing is that you look inside the box. What are the
technical details? What contents are there? When I give input, how is my input executed? Where is it
stored? What is the type of variable? This variable How does my query access the database? How much
delay is there in it? So, these technical details and the minute level details, the how details come in your
white box and then an output is produced against it. So, you are checking correctness. So, your right
things are happening, but are they happening in the right way or not? If age,

The employee's age is an integer value. So if the employee's age is an integer value, then it should be an
integer. It doesn't need to be a variable character to be a varchar. The employee's age can go up to 99
years. So its length should be accordingly. If you increase the length of the integer or increase the length
of the varchar, now these are the details of how, which tells in verification that this So, in the verification
with respect to specification and design, how are things actually working? Correctness. Design as
specification for components. Structural or functional testing. desired behavior was required from that
software and the responsiveness required from that software has been performed or not. And lastly, you
do inspection and formal reviews in which you again verify that the things that should be done in which
way are being performed in the same way.

So here are the details for the validation and verification. If we want to know Validation and Verification
in the software process, so actually what happens is that it starts with the requirements of the customer.
So there are the requirements of the customer, then there is the specification, then you do the high level
design, then you do the low level design, then you do the code, then you do the test and then you use it.
So this is basically generic phases of any software. Requirement analysis, product specification, design,
code, test, and actually usage. Now, in validation and verification, we have to see in which phase there
will be validation and in which phase there will be verification. So, customer requirements are validated
and In the customer requirements phase, V&V, you only validate whether the required things are being
performed or not.

So, you did it in the requirements as well. And at the end, when the software is made and comes into
operation, you then revalidate it. Similarly, let's talk about product specification. Here, product
specification and ultimately system test. Here, you are seeing both things. In these two phases, you are
seeing both verification and validation. If we talk about high-level design and if we talk about integration
test on the other side, then you are verifying it that the technical details that were to be performed
ideally are being performed. Apart from that, there is low-level design and component test. You are
verifying here as well. So, it means that in this V and V model, validation and verification V model, its
shape is also V type, like alphabet V, so it is called V model.

So, in this V model, there are different software processes, like requirements, specification, high level
design, low level design, coding, test, then test, then test, and then operational use. So, you have to
check exactly where to perform validation and where to perform verification in each phase. Where to
perform validation and where to perform verification. Apart from this, if we talk about V model as bent
over waterfall. Because its stages, its phases are like a waterfall. analysis, design, code, test or
maintenance or handover so it is called bent over waterfall model. In left arm, you have implementation
and in right arm, you have actually testing in left arm, in left arm you have customer requirement,
product specification, high level design, there you have implementation details.

And in the right arm, you can see that all your testing is going on. Component test, integration test,
system test. Where is the user? At the top is your user and at the bottom is your developer. So in coding
and unit test, he is your developer. And at the operational use and that top is your customer. So, should
we talk about operational use or customer requirements? There, the customer is telling you what the
requirements are and the customer is telling you while using it whether it is working properly or not.
Apart from this, we have a defect centered view, which we call DC view. Quality assurance actually has
two views. One is validation and verification view and the other is defect centered view.

We have seen the validation and verification view in detail. Now let's talk about the defect centered
view. Remember that these two views are not interconnected and you cannot run them collectively.
Their mapping is impossible. So we just discussed the validation and verification view. Let us now have a
look on the defect centered view or DC view of the quality assurance. So validation and verification after
commitment, defect injected already. So here you focus on defect removal and defect controlling. If we
talk about verification, then your focus is internal. You are actually checking the technical details.
Whereas in validation, you can see externally whether the overall system is performing properly or not.
And we talked in the previous slide that the V-model that we discussed, verification and validation V-
model, it's closer to user or developer.

Any user, whether they are the end user who will use the software or the developer who is developing
the software. So at the top is the actual user or client and at the bottom is the developer. Defect
centered view or validation or verification Let's talk about the mapping in this table. So, we want to see
what is the activity of quality assurance and how does DC view perform and how does validation and
verification view perform. So, in the column in the middle of this table, there are the activities of quality
assurance, how is the defect centered view performing and how is the validation and verification view
performing. It is mentioned here in this table. If you look at the first line, so quality assurance activity is
requirement related, other defect prevention, formal specification, formal verification.

What is the defect centered view doing? Actually, it is doing defect prevention. It is doing defect
prevention and it is assuring quality. Whereas, what is validation and verification view doing? Indirectly It
is validating or verifying the requirements and checking whether the software will perform the required
functions or not. Similarly, quality assurance activity is testing. Testing is performed by DC view, Defect
Centered View, and Defect Reduction. Obviously, validation and verification view is performed more
formally by using verification and validation. And lastly, Your third phase is of operation or design and
implementation. So, how do you use DCV? By doing defect containment. Whereas, what does your
VNVU do? Mostly, things have been validated. Now, it verifies them. So, what I mean to say is that you
have different quality assurance activities in different software processes.

Like, in requirement analysis, test may design may take a requirement analysis may up could be seen you
can cut the head if I prevention cut the head or up goes validation and review we envy you can cut the
head I'll move do you act with invalidation or verification will perform cut the head is kebada up cut
testing a process a so be seen you can cut the DCB up a defect reduction cut the head we envy you can
cut the head you have paid again verification and validation. Lastly, your design phase. In design phase,
your mostly operational design or other implementation details are there. DC view controls the defects
here. And your V and V view, mostly things are already verified and validated.

It is just ensuring them. So that was a comparison between the DC view and validation and verification
view. And as we discussed in the previous slide, these both views are related to the quality assurance. So
these are, as we previously discussed, that there are two views and that is V&V view and DC view. So we
have seen the comparison of these two in this particular slide. Let us proceed towards the summaries of
today's lecture. In today's lecture, we saw in detail that there are different software process models and
different phases of each software process model. Quality assurance is scattered in each phase of each
software process model. You just need to make sure that quality assurance is there in any phase of any
type of the software development model.

We also discussed the two views of quality assurance, that is V and V view and DC view, defect centered
view. And we also compared and contrasted that how different quality assurance activities are viewed by
the DC model and by the VNV model. Inshallah in our next lecture we will have a look on quality
assurance towards software quality engineering and we will explore some SQE software quality
engineering related activities. We will also have a look on the How to incorporate the SQE in software
process? So far we have discussed how quality assurance is done in software process. In the next lecture
we will talk about how software quality engineering is done in software process. And we will also see
how quality improvement paradigm and software quality engineering work together to ensure quality in
your software.

Hope you enjoyed today's lecture. I'll see you with more details until then bye for now and Allah Hafiz