CSI3014

Software Verification and Validation

Dr.N.Narayanan Prasanth
Associate Professor
Department of Database Systems
School of Computer Science and Engineering (SCOPE)
VIT University Vellore
Mail: n.Prasanth@vit.ac.in
Mobile: 9943182582
Cabin: SJT116 A40
4. Evolutionary Process Models
- Evolutionary models are iterative.
- A process model that has been explicitly designed to accommodate a product that
grows and changes

Why Evolutionary Model?

1. Business and product requirements often change as development proceeds, making a

straight line path to an end product is unrealistic;
2. Tight market deadlines make completion of a comprehensive software product
impossible, but a limited version must be introduced to meet competitive or business
pressure;
3. A set of core product or system requirements is well understood, but the details of
product or system extensions have yet to be defined.

2
4.1. Prototyping

Q u i ck p l an
Quick
plan
Co m m u n icat io n
communication

Mo Modeling
d e lin g
Q u i ck d e si g n
Quick design

Deployment
Deployment
De live r y
delivery &
& feedback
Fe e d b ack Co n st r u ct io n
o fConstruction
of prototype
p r o t o t yp e

3
4. Evolutionary Process Models
4.1 Prototyping Example

4
4.1. Prototyping
Prototyping paradigm can offer the best approach,
• If developer may be unsure of the efficiency of an algorithm,
• the adaptability of an operating system, or
• the form that human-machine interaction should take

• Prototyping paradigm assists everyone to better understand what is to be built when

requirements are fuzzy
• Stakeholders should agree that the prototype is built to serve as a mechanism for defining
requirements.
• A prototyping iteration is planned quickly, and modeling occurs
• A quick design focuses on the software that will be visible to end users
• The prototype serves as a mechanism for identifying software requirements
5
4.2. The Spiral Model

6
4.2. The Spiral Model

Figure: Boehm’s spiral model of

the software process
(©IEEE 1988)

7
4.2. The Spiral Model

It is an evolutionary software process model that couples the iterative nature of

prototyping with the controlled and systematic aspects of the waterfall model.
The spiral model is a realistic approach to the development of large-scale systems
and software.
The spiral development model is a risk-driven process model generator. It has two
main distinguishing features:
approach for incrementally growing a system’s degree of definition and
• cyclic
implementation while decreasing its degree of risk
•a set of anchor point milestones for ensuring stakeholder commitment to feasible
and mutually satisfactory system solutions

8
4.2. The Spiral Model
• Anchor point milestones—a combination of work products and conditions that
are attained along the path of the spiral—are noted for each evolutionary pass.
• The first circuit around the spiral might result in the development of a product
specification; subsequent passes around the spiral might be used to develop a
prototype and then progressively more sophisticated versions of the software.
• Each pass through the planning region results in adjustments to the project plan.
Cost and schedule are adjusted based on feedback derived from the customer
after delivery.
• The spiral model can be adapted to apply throughout the life of the computer
software.

9
4.2. The Spiral Model
Using the spiral model, software is developed in a series of evolutionary
releases.
During early iterations, the release might be a model or prototype.
During later iterations, increasingly more complete versions of the
engineered system are produced.
A spiral model is divided into a set of framework activities defined by the
software engineering team.

10
4.2. The Spiral Model
• The spiral model is a realistic approach to the development of large-scale
systems and software because the software evolves as the process progresses.

• Thespiral model uses prototyping as a risk reduction mechanism but needs to

apply the prototyping approach at any stage in the evolution of the product.

• Thespiral model demands a direct consideration of technical risks at all stages of

the project and, if properly applied, should reduce risks before they become
problematic.

11
5. Rational Unified Model
History
• In 1990, James Rumbaugh [Rum91], Grady Booch [Boo94], and Ivar Jacobson [Jac92]
began working on a “unified method” results in UML—a unified modeling language that
contains a robust notation for the modeling and development of object-oriented systems.
• UML provided the necessary technology to support object-oriented software engineering
practice, but it did not provide the process framework to guide project teams in their
application of the technology
• Then they developed the Unified Process, a framework for object-oriented software
engineering using UML
• It suggests a process flow that is iterative and incremental, providing the evolutionary
feel that is essential in modern software development.

12
5. Rational Unified Model
The RUP recognizes that conventional process models present a single view of the
process.

In contrast, the RUP is normally described from three perspectives:

1. A dynamic perspective, which shows the phases of the model over time.
2. A static perspective, which shows the process activities that are enacted.
3. A practice perspective, which suggests good practices to be used during the
process.

13
5. Phases of the Unified Process

14
5. Rational Unified Model
1. Inception
• The goal of the inception phase is to establish a business case for the system.
• Identify all external entities (people and systems) that will interact with the system
• Use this information to assess the contribution that the system makes to the business

2. Elaboration
• The goals of the elaboration phase are to develop an understanding of the problem domain,
establish an architectural framework for the system, develop the project plan, and identify key
project risks.
• On completion of this phase you should have a requirements model for the system, which may
be a set of UML use-cases, an architectural description, and a development plan for the
software. 15
5. Rational Unified Model
3. Construction
The construction phase involves system design, programming, and testing. On completion of this
phase, you should have a working software system and associated documentation that is ready for
delivery to users.

4. Transition
The final phase of the RUP is concerned with moving the system from the development
community to the user community and making it work in a real environment.

5. The production phase

During this phase, the ongoing use of the software is monitored, support for the operating
environment (infrastructure) is provided, and defect reports and requests for changes are
submitted and evaluated.
6. Specialized Process Models
1. Component-Based Development
Commercial off-the-shelf (COTS) software components, developed by vendors
who offer them as products, provide targeted functionality with well-defined
interfaces that enable the component to be integrated into the software that is to be
built.

Spiral Model + Iterative approach

• This model constructs applications from prepackaged software components.

17
6. Specialized Process Models
1. Component-Based Development

The component-based development model incorporates the following steps:

1. Available component-based products are researched and evaluated for the application
domain.
2. Component integration issues are considered.
3. A software architecture is designed to accommodate the components.
4. Components are integrated into the architecture.
5. Comprehensive testing is conducted to ensure proper functionality.

18
6. Specialized Process Models
2. The Formal Methods Model

• It encompasses a set of activities that leads to formal mathematical specification of

computer software.
• It enable you to specify, develop, and verify a computer-based system by applying a
rigorous, mathematical notation.
• A variation on this approach, called cleanroom software engineering and is currently
applied by some software development organizations.
• It provides a mechanism for eliminating many of the problems that are difficult to
overcome using other software engineering paradigms

19
6. Specialized Process Models
2. The Formal Methods Model

• Ambiguity, incompleteness, and inconsistency can be discovered and corrected

more easily through the application of mathematical analysis.

• When formal methods are used during design, they serve as a basis for program
verification and therefore enable you to discover and correct errors that might
otherwise go undetected.

• It
is not a mainstream approach, the formal methods model offers the promise of
defect-free software.
20
6. Specialized Process Models
2. The Formal Methods Model

Drawbacks
• time consuming and expensive
• extensive training is required
• difficult to use the models as a communication mechanism

Applications
• It is used to build safety-critical software

21
6. Specialized Process Models
3. Aspects-Oriented Software Development

Aspect-oriented software development (AOSD), often referred to as aspect-oriented

programming (AOP), is a relatively new software engineering paradigm that
provides a process and methodological approach for defining, specifying, designing,
and constructing aspects.

Aspects—“mechanisms beyond subroutines and inheritance for localizing the

expression of a crosscutting concern

22
6. Specialized Process Models
Why Aspects-Oriented Software Development?
• Builders of complex software invariably implement a set of localized features, functions,
and information content and are modeled as components and then constructed within the
context of a system architecture.
• As modern computer-based systems become more sophisticated and complex, certain
concerns span the entire architecture. Some example concerns are security, fault tolerance,
integrating business rules, etc.
• concerns—customer required properties or areas of technical interest
• When concerns cut across multiple system functions, features, and information, they are
often referred to as crosscutting concerns.
• These crosscutting concerns will have an impact across the software architecture.

23
7. The Reuse Oriented Software Engineering

Fig. Reuse-oriented Validation software engineering

24
7. The Reuse Oriented Software Engineering
Reuse-oriented approaches rely on a large base of reusable software components and
an integrating framework for the composition of these components.
• It reduces the amount of software to be developed, cost and risks
• Faster delivery of the software

There are three types of software component that may be used in a reuse-oriented
process:
• Web services that are developed according to service standards and which are available
for remote invocation.
• Collections of objects that are developed as a package to be integrated with a component
framework such as .NET or J2EE.
• Stand-alone software systems that are configured for use in a particular environment.
25
References
1. Roger Pressman, Software Engineering: A Practitioner’s Approach, 8th Edition,
McGraw-Hill, 2019.
2. Ian Sommerville, Software Engineering, 9th Edition, Addision-Wesley, 2016