Validation & verification software engineering

SOFTWARE ENGINEERING
SWETA KUMARI BARNWAL 1
Verification and Validation
Verification and Validation is the process of investigating that a software system satisfies
specifications and standards and it fulfills the required purpose. Barry Boehm described
verification and validation as the following:
Verification: Are we building the product right?
Validation: Are we building the right product?
Verification:
Verification is the process of checking that a software achieves its goal without any bugs. It is
the process to ensure whether the product that is developed is right or not.
Verification testing includes different activities such as business requirements, system
requirements, design review, and code walkthrough while developing a product.
It is also known as static testing, where we are ensuring that "we are developing the right
product or not". And it also checks that the developed application fulfilling all the requirements
given by the client.
It verifies whether the developed product fulfills the requirements that we have.
Verification is Static Testing.
Activities involved in verification:
1. Inspections
2. Reviews
3. Walkthroughs
4. Desk-checking
Validation:
Validation is the process of checking whether the software product is up to the mark or in other
words product has high level requirements. It is the process of checking the validation of product
i.e. it checks what we are developing is the right product. it is validation of actual and expected
product.
Validation is the Dynamic Testing.
Activities involved in validation:
1. Black box testing
2. White box testing
3. Unit testing
4. Integration testing

White box Testing: - White box testing techniques analyze the internal structures the used data
structures, internal design, code structure and the working of the software rather than just the
functionality as in black box testing. It is also called glass box testing or clear box testing or
structural testing
Black box Testing: - Black-box testing is a method of software testing that examines the
functionality of an application based on the specifications. It is also known as Specifications
based testing. Independent Testing Team usually performs this type of testing during the
software testing life cycle.
Unit Testing: - Unit Testing is defined as a type of software testing where individual
components of a software are tested. It is a testing method using which every independent
module is tested to determine if there are any issue by the developer himself. It is correlated with
functional correctness of the independent modules.
Integration Testing: - Integration testing is done to test the modules/components when
integrated to verify that they work as expected i.e. to test the modules which are working fine
individually does not have issues when integrated. In this testing, units or individual components
of the software are tested in a group. The focus of the integration testing level is to expose
defects at the time of interaction between integrated components or units.
VERIFICATION VALIDATION
Requirement
Specification
High Level Design
Detail Design
Program
Specification
CODING
Unit Testing
Integration Testing
System Testing
User Acceptance
Testing

Software Inspections: -
It is a quality improvement process to the software project. Its main goal is to defect detection
and defect prevention.
Inspection can be done manually or automatically or both in a sequential manner. It is an
important part of the software development cycle.
It involves meetings during which analysis, designs and code are reviewed by people other than
the original developer.
A software inspection team consists of 3-8 members
A small group of programmers who follow a specific procedure to review the source code
developed by a peer with the intent of identifying defects and improving maintainability.
What's the difference between a code walkthrough, code review, and code inspection?
The terms "walkthrough" and "code review" usually refer to informal or casually prescribed
methods. Inspections are more formal and quite carefully specified.
Automated Static Analysis
An automatic analysis that executes when software is “checked in” to the project database is the
best way to ensure periodic and consistent static software tests. Automating the testing allows
greater consistency and the assurance that even without direct programmer involvement,
the static analysis executes.
Software Testing:- Software Testing is a method to check whether the actual software
product matches expected requirements and to ensure that software product is Defect free. It
involves execution of software/system components using manual or automated tools to evaluate
one or more properties of interest. The purpose of software testing is to identify errors, gaps or
missing requirements in contrast to actual requirements.
System Testing: - SYSTEM TESTING is a level of testing that validates the complete and
fully integrated software product. System Testing (ST) is a black box testing technique
performed to evaluate the complete system the system's compliance against specified
requirements. In System testing, the functionalities of the system are tested from an end-to-end
perspective.

System Testing is usually carried out by a team that is independent of the development team in
order to measure the quality of the system unbiased. It includes both functional and Non-
Functional testing.
The process of testing an integrated system to verify that it meets specified requirements.
Usually, Black Box Testing method, in which the internal structure of the system under test is
unknown, is used. Tests are normally done manually but the trend of test automation, specially
for Regression Testing, is picking up.
System Testing is the third level of software testing performed after Integration Testing and
before Acceptance Testing.
Normally, independent software testers perform System Testing. Normally, independent
software testers perform System Testing.
Component Testing: -
Component Testing is a type of software testing in which usability of each individual component
is tested. Along with the usability test, behavioral evaluation is also done for each individual
component. To perform this type of testing, each component needs to be in independent state and
also should be in controllable state. Each component of the software should be user
comprehensible.
Component Test Specification
Component Test Plan
Project Component Test Plan
Component Test Strategy
Component Test Report

Unit Testing:
Unit Testing is a type of software testing in which individual units of software i.e. group of
computer program modules, usage procedures and operating procedures are tested to determine
whether they are suitable for use or not. It is a testing method using which every independent
module is tested to determine if there are any issue by the developer himself. It is correlated with
functional correctness of the independent modules.
Test Case Design
Test design is an art that has interesting techniques associated with it, which make it effective
and useful for testing. Many people, when creating a test plan or writing the test case, fail to
decipher what to test in a given cycle or what not to test in a given project. When you are
checking the parameters that are not be tested, one must ensure that the requirement which is
not testable by testers must be addressed here.
Automation Testing
Automation testing is a Software testing technique to test and compare the actual outcome with
the expected outcome. This can be achieved by writing test scripts or using any automation
testing tool. Test automation is used to automate repetitive tasks and other testing tasks which are
difficult to perform manually.
Software Measurement and Metrics
Acceptance Testing
System Testing
Integration Testing
Unit Testing

A measurement is an indication of the size, quantity, amount or dimension of a particular attribute of a
product or process. For example, the number of errors in a system is a measurement.
Measurement can be used by software engineers in decision making.
Measure is used to indicate the quality of the product.
It is the process by which numbers or symbols are assigned to the attributes of the entities in the real
world in such a way as to define them accordingly to clearly defined rules.
A Metric is a measurement of the degree that any attribute belongs to a system, product or process. For
example the number of errors per person hours would be a metric.
Thus, software measurement gives rise to software metrics.
Metrics are related to the four functions of management:
• Planning
• Organizing
• Controlling
• Improving
Software metrics is a standard of measure that contains many activities which involve some
degree of measurement. It can be classified into three categories: product metrics, process
metrics, and project metrics.
• Product metrics describe the characteristics of the product such as size, complexity,
design features, performance, and quality level.
• Process metrics can be used to improve software development and maintenance.
Examples include the effectiveness of defect removal during development, the pattern of
testing defect arrival, and the response time of the fix process.
• Project metrics describe the project characteristics and execution. Examples include the
number of software developers, the staffing pattern over the life cycle of the software,
cost, schedule, and productivity.
Some metrics belong to multiple categories. For example, the in-process quality metrics of a
project are both process metrics and project metrics.
COCOMO Model
This model is mainly used to estimate cost, size & time of the software to be developed.
Actually, there are three kinds of software are available named as;
Organic (Small size project, experienced developers in the familiar environment. For example,
pay roll, inventory projects, Banking system; Project Size: 2 to 50 KLOC)

Semidetached (Medium size project, Medium size team, Average previous experience on
similar project. For example: Utility systems like compilers, database systems; Project Size: 50
to 300 KLOC)
Embedded (Large project, Real time systems, Complex interfaces, Very little previous
experience. For example: ATMs, Air Traffic Control, Navigation satellite; Project Size: Above
300 KLOC)
NOTE: Person-month (PM) is considered to be an appropriate unit for measuring effort
Cocomo (Constructive Cost Model) is a regression model based on LOC, i.e number of Lines
of Code. It is a procedural cost estimate model for software projects and often used as a
process of reliably predicting the various parameters associated with making a project such as
size, effort, cost, time and quality. It was proposed by Barry Boehm in 1970 and is based on
the study of 63 projects, which make it one of the best-documented models.
The key parameters which define the quality of any software products, which are also an
outcome of the Cocomo are primarily Effort & Schedule:
• Effort: Amount of labor that will be required to complete a task. It is measured in person-
months units.
• Schedule: Simply means the amount of time required for the completion of the job, which
is, of course, proportional to the effort put. It is measured in the units of time such as
weeks, months.
Different models of Cocomo have been proposed to predict the cost estimation at different
levels, based on the amount of accuracy and correctness required. All of these models can be
applied to a variety of projects, whose characteristics determine the value of constant to be
used in subsequent calculations. These characteristics pertaining to different system types are
mentioned below.

Boehm’s definition (1981) of organic, semidetached, and embedded systems:
1. Organic – A software project is said to be an organic type if the team size required is
adequately small, the problem is well understood and has been solved in the past and also
the team members have a nominal experience regarding the problem.
2. Semi-detached – A software project is said to be a Semi-detached type if the vital
characteristics such as team-size, experience, knowledge of the various programming
environment lie in between that of organic and Embedded. The projects classified as Semi-
Detached are comparatively less familiar and difficult to develop compared to the organic
ones and require more experience and better guidance and creativity. Eg: Compilers or
different Embedded Systems can be considered of Semi-Detached type.
3. Embedded – A software project with requiring the highest level of complexity, creativity,
and experience requirement fall under this category. Such software requires a larger team
size than the other two models and also the developers need to be sufficiently experienced
and creative to develop such complex models.
All the above system types utilize different values of the constants used in Effort
Calculations.
Types of Models: COCOMO consists of a hierarchy of three increasingly detailed and
accurate forms. Any of the three forms can be adopted according to our requirements. These
are types of COCOMO model:
1. Basic COCOMO Model
2. Intermediate COCOMO Model
3. Detailed COCOMO Model
The first level, Basic COCOMO can be used for quick and slightly rough calculations of
Software Costs. Its accuracy is somewhat restricted due to the absence of sufficient factor
considerations.
Intermediate COCOMO takes these Cost Drivers into account and Detailed
COCOMO additionally accounts for the influence of individual project phases, i.e in case of
Detailed it accounts for both these cost drivers and also calculations are performed phase wise
henceforth producing a more accurate result. These two models are further discussed below.
Estimation of Effort: Calculations –
Basic Model –
1. E =a*(KLOC)b
2. time = c (Effort)d
3. Person Required = Effort/time
Where, E is effort applied in Person-Months, and D is the development time in months
The above formula is used for the cost estimation of for the basic COCOMO model, and
also is used in the subsequent models. The constant values a,b,c and d for the Basic Model
for the different categories of system:
Sr. No. Mode Effort Time
1 Organic E = 2.4*(KLOC)1.05
Time = 2.5*(E)0.38

2 Semidetached E = 3.0*(KLOC)1.12
Time = 2.5*(E)0.35
3 Embedded E = 3.6*(KLOC)1.20
Time = 2.5*(E)0.32
Merits of Basic Cocomo model:
Basic cocomo model is good for quick, early,rough order of magnitude estimates of software
project.
Limitations:
1.The accuracy of this model is limited because it does not consider certain factors for cost
estimation of software. These factors are hardware constraints, personal quality and
experiences, modern techniques and tools.
2. The estimates of Cocomo model are within a factor of 1.3 only 29% of the time and within
the factor of 2 only 60% of time.
Example: consider a software project using semi-detached mode with 30,000 lines of code . We
will obtain estimation for this project as follows:
Effort estimation E= a*(KLOC)b
person-months
E=3.0(30)1.12
where lines of code=30000=30
KLOC E=135 person-month
Disadvantages of Basic COCOMO Model
• It considers only KLOC to estimate effort
• It cannot be used for modern tools
• It does not consider different parameters
Note: Intermediate COCOMO model considers different parameters to estimate effort and time
Intermediate COCOMO
It computes software development effort as a function of program size and a set of “cost drivers”
that include subjective assessments of product, hardware, personnel, and project attributes.
E =a*(KLOC)b *EAF
E is effort in person-months, KLOC is estimated number of lines of code
Sr. No. Mode Effort

1 Organic E = 3.2*(KLOC)1.05
* EAF
2 Semidetached E = 3.0*(KLOC)1.12
* EAF
3 Embedded E = 2.8*(KLOC)1.20
* EAF
Merits:
1.This model can be applied to almost entire software product for easy and rough cost estimation
during early stage.
2.It can also be applied at the software product component level for obtaining more accurate
cost estimation.
Limitations:
1.The effort multipliers are not dependent on phases.
2. A product with many components is difficult to estimate.
Example: Consider a project having 30,000 lines of code which in an embedded software with
critical area hence reliability is high.
The estimation can be
E=a*(KLOC)b
*(EAF)
As reliability is high
EAF = 1.15 (product attribute)
A =2.8
B =1.20
for embedded software
E=2.8(30)1.20
*1.15 = 191 person month
Time (T) =c (E)db = 2.5(191)0.32
=13 months approximately
N=E/T =191/13 N=15 persons approx.
Advanced COCOMO
It incorporates all characteristics of intermediate COCOMO with an assessment of the cost
driver’s impact on each step of software engineering process. This model uses different effort
multipliers for each cost driver attribute. In detailed cocomo, the whole software is divided into
different modules and then we apply COCOMO in different modules to estimate effort and then
sum the effort.
The Six phases of detailed COCOMO are:
a) Planning and requirements
b) System design
c) Detailed design
d) Module code and test
e) Integration and test
f) Cost Constructive model
The effort is calculated as a function of program size and a set of cost drivers are given according
to each phase of the software lifecycle.

Software Productivity
It is a deceptively simple concept, but a matter of some debate. Although its earliest
measurement was in lines of code per man-hours worked, a better definition is the ratio between
the functional value of software produced to the labor and expense of producing it. There are
several ways to measure software productivity, including Function Point Analysis, Cost
Component Modeling, Cyclomatic Complexity, and program performance metrics that take into
account the costs of running and maintaining the software.
Using these tools, the software development process can be managed and productivity
enhanced by reusing code to leverage existing programs, minimizing rework through reliability
initiatives, and adopting sound development practices and standards. However, even when sound
practices are adhered to, software productivity may not increase because of circumstances
outside the control of the development team. This includes rapidly changing technologies and the
fixed-cost behavior of significant parts of the software development process.
The concept of software productivity is not a theoretical abstract. It is a critical part of the
software engineering process. Understanding software productivity becomes important in
systems analysis when you consider that good systems analysis enhances software productivity
and software productivity is a success measure of systems analysis.
In standard economic terms, productivity is the ratio between the amount of goods or
services produced and the labor or expense that goes into producing them (1). The assumption
that follows, then, is that software productivity is the ratio between the amount of software
produced to the labor and expense of producing it. This is a simple theory that appears to be
logical, but in practice becomes a matter of some debate.
In order to define software productivity, we must first establish a definition of software.
At its most fundamental level, software is a computer program comprised of lines of code.
However, lines of code, in and of themselves, are not the primary deliverables of a software
project and customers often do not know how many lines of code are in the software they are
buying (1).
A broader definition of software encompasses not only the computer program, but also
the related procedures and documentation associated with the program. This often includes
documentation of requirements, specifications, software design, and end-user procedures (2).
The complete set of documentation provides a more tangible deliverable of a software project
than does the program itself.
However, even though program code and documentation are the primary outputs of
software production, they are not of direct interest to the software consumer. Software is bought
based on what it can do, not on how it was coded or documented. This means that the economic
value of goods and services consumed is not measured in the same units as the natural units of
production. Subsequently, a different measure of software needs to be used in order to get a
meaningful definition of software productivity. This measure needs to reflect the utility value of
the software, to wit the function that the software is intended to perform (1).
Basing our measurements on the utility value of software, we can revise our original
assumption and define software productivity as the ratio between the functional value of
software produced to the labor and expense of producing it. This definition allows us to measure
productivity based on the value of results to the software consumer, which is more realistic than
basing results on lines of code (2).

Project Duration and Staffing
Once the effort is estimated, various schedules (or project duration) are possible, depending on
the number of resources (people) put on the project.
For example, for a project whose effort estimate is 56 person-months, a total schedule of 8
months is possible with 7 people. A schedule of 7 months with 8 people is also possible, as is a
schedule of approximately 9 months with 6 people.
Manpower and months are not interchangeable in a software project. A schedule cannot be
simply obtained from the overall effort estimate by deciding on average staff size and then
determining the total time requirement by dividing the total effort by the average staff size.
Brooks has pointed out that person and months (time) are not interchangeable. According to
Brooks,"... man and months are interchangeable only for activities that require no
communication among men, like sowing wheat or reaping cotton. This is not even approximately
true of software...."
For instance, in the example here, a schedule of 1 month with 56 people is not possible even
though the effort matches the requirement. Similarly, no one would execute the project in 28
months with 2 people. In other words, once the effort is fixed, there is some flexibility in setting
the schedule by appropriately staffing the project, but this flexibility is not unlimited.
Empirical data also suggests that no simple equation between effort and schedule fits well. In a
project, the scheduling activity can be broken into two sub activities: determining the overall
schedule (the project duration) with major milestones, and developing the detailed schedule of
the various tasks.
Overall Scheduling: - One method to determine the normal (or nominal) overall schedule is to
determine it as a function of effort. Any such function has to be determined from data from
completed projects using statistical techniques like fitting a regression curve through the scatter
plot obtained by plotting the effort and schedule of past projects. This curve is generally
nonlinear because the schedule does not grow linearly with effort. Many models follow this
approach. The IBM Federal Systems Division found that the total n duration, M, in calendar
months can be estimated by
In COCOMO, the equation for schedule for an organic type of software is
It should be clear that schedule is not a function solely of effort. Hence, the schedule determined
in this manner is not really fixed. However, it can be used as a guideline or check of the
schedules reasonableness, which might be decided based on other factors.

One rule of thumb, called the square root check, is sometimes used to check the schedule of
medium-sized projects. This check suggests that the proposed schedule can be around the square
root of the total effort in person-months. This schedule can be met if suitable resources are
assigned to the project. For example, if the effort estimate is 50 person-months, a schedule of
about 7 to 8 months will be suitable.
From this macro estimate of schedule, we have to determine the schedule for the major
milestones in the project. To determine the milestones, we must first understand the manpower
ramp-up that usually takes place in a project. The number of people in a software project tends to
follow the Rayleigh curve. That is, in the beginning and the end, few people work on the project;
the peak team size (PTS) is reached somewhere near the middle of the project. This behavior
occurs because only a few people are needed in the initial phases of requirements analysis and
design. The human resources requirement peaks during coding and unit testing. Again, during
system testing and integration, fewer people are required.

Validation & verification software engineering

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Validation & verification software engineering

Similar to Validation & verification software engineering (20)

More from Sweta Kumari Barnwal

More from Sweta Kumari Barnwal (20)

Recently uploaded

Recently uploaded (20)

Validation & verification software engineering