Smqa unit v

Cleanroom Software Engineering

Mr. M. E. Patil
1
S.S.B.T COET, Bambhori

The Cleanroom Process Model
increment #1

Box Structure Formal Correctness Code
Specification Design Verification Statistical Cerfification
Inspection
Requirements Use
Gathering Testing
Test Planning

System
Engineering increment #2

Inspection
Requirements Use
Gathering Testing
Test Planning

increment #n
Inspection
Requirements Use
Gathering Testing
Test Planning

Mr. M. E. Patil
2

The Cleanroom Strategy-I
Increment Planning—adopts the incremental strategy
Requirements Gathering—defines a description of customer level
requirements (for each increment)
Box Structure Specification—describes the functional specification
Formal Design—specifications (called “black boxes”) are iteratively refined
(with an increment) to become analogous to architectural and procedural
designs (called “state boxes” and “clear boxes,” respectively).
Correctness Verification—verification begins with the highest level box
structure (specification) and moves toward design detail and code using a
set of “correctness questions.” If these do not demonstrate that the
specification is correct, more formal (mathematical) methods for
verification are used.
Code Generation, Inspection and Verification—the box structure
specifications, represented in a specialized language, are transmitted into
the appropriate programming language.

Mr. M. E. Patil
3

The Cleanroom Strategy-II
Statistical Test Planning—a suite of test cases that exercise of “probability
distribution” of usage are planned and designed
Statistical Usage Testing—execute a series of tests derived from a
statistical sample (the probability distribution noted above) of all possible
program executions by all users from a targeted population
Certification—once verification, inspection and usage testing have been
completed (and all errors are corrected) the increment is certified as ready
for integration.

Mr. M. E. Patil
4

Box Structure Specification
CB1.1.1.1

black box
BB1.1.1 SB1.1.1 CB1.1.1.2
clear box

BB1.1 BB1.1.2
CB1.1.1.3

BB1 BB1.1.3
BB1.2

state box

BB1.n

Mr. M. E. Patil
5

Box Structures
State
T

S f:S* R R

S black box, g R
black box
state box

State
T

g12

S g11 cg1 R
g13

clear box
Mr. M. E. Patil
6

Design Refinement & Verification
If a function f is expanded into a sequence g and h, the correctness
condition for all input to f is:
• Does g followed by h do f?
When a function f is refined into a conditional (if-then-else), the
correctness condition for all input to f is:
• Whenever condition <c> is true does g do f and whenever <c> is false,
does h do f?
When function f is refined as a loop, the correctness conditions for all
input to f is:
• Is termination guaranteed?
• Whenever <c> is true does g followed by f do f, and whenever <c> is
false, does skipping the loop still do f?

Mr. M. E. Patil
7

Advantages of Design Verification
 It reduces verification to a finite process.
 It lets cleanroom teams verify every line
of design and code.
 It results in a near zero defect level.
 It scales up.
 It produces better code than unit testing.

Mr. M. E. Patil
8

Cleanroom Testing
 statistical use testing
 tests the actual usage of the program
 determine a “usage probability distribution”
 analyze the specification to identify a set of
stimuli
 stimuli cause software to change behavior
 create usage scenarios
 assign probability of use to each stimuli
 test cases are generated for each stimuli
according to the usage probability distribution

Mr. M. E. Patil S.S.B.T COET, Bambhori 9

Certification
1. Usage scenarios must be created.
2. A usage profile is specified.
3. Test cases are generated from the profile.
4. Tests are executed and failure data are
recorded and analyzed.
5. Reliability is computed and certified.

Mr. M. E. Patil
10

Certification Models
Sampling model. Software testing executes m random test
model.
cases and is certified if no failures or a specified numbers of
failures occur. The value of m is derived mathematically to
ensure that required reliability is achieved.
Component model. A system composed of n components is
to be certified. The component model enables the analyst to
determine the probability that component i will fail prior to
completion.
Certification model. The overall reliability of the system is
projected and certified.

Mr. M. E. Patil
11

Reengineering

Mr. M. E. Patil
12

Business Process

• A set of logically related tasks performed to
archive a defined business outcome
• With in the business process people ,
equipments material resources and business
procedures are combined to produce the
specific result

Mr. M. E. Patil
13

• BPR is iterative process
• Business process goals and the processes that
achive them must ne adapted tp a changing
business environment
• There is no start and end of the BPR its is an
evolutionary process

Mr. M. E. Patil
14

Business
definition

Refinement
&
Instantiation

Prototyping

Process
identification
Process
Specification
and Design

Process
Evaluation

Mr. M. E. Patil
15

BPR Principles
• Organize around outcomes, not tasks.
• Have those who use the output of the process perform the
process.
• Incorporate information processing work into the real work that
produces the raw information.
• Treat geographically dispersed resources as though they were
centralized.
• Link parallel activities instead of integrated their results. When
different
• Put the decision point where the work is performed, and build
control into the process.
• Capture data once, at its source.

Mr. M. E. Patil
16

Software Reengineering
fo rw ard inventory
eng ineering analysis

data document
restructuring restructuring

reverse
code engineering
res truc tu ring

Mr. M. E. Patil
17

Inventory Analysis
 build a table that contains all applications
 establish a list of criteria, e.g.,
 name of the application
 year it was originally created
 number of substantive changes made to it
 total effort applied to make these changes
 date of last substantive change
 effort applied to make the last change
 system(s) in which it resides
 applications to which it interfaces, ...
 analyze and prioritize to select candidates for
reengineering

Mr. M. E. Patil
18

Restructuring
 Document Restructuring
 options range from doing nothing to regeneration of
all documentation for critical system
 Reverse Engineering
 the intent here is to achieve design recovery
 Code Restructuring
 rebuild spaghetti bowl code
 Data Restructuring
 data architecture

Mr. M. E. Patil
19

Reverse Engineering
dirty source code

restructure
code

clean source code processing

extract
abstractions interface

initial specification database

refine
&
simplify

final specification

Mr. M. E. Patil
20

Forward Engineering
1. The cost to maintain one line of source code may be 20 to 40
times the cost of initial development of that line.
2. Redesign of the software architecture (program and/or data
structure), using modern design concepts, can greatly facilitate future
maintenance.
3. Because a prototype of the software already exists, development
productivity should be much higher than average.
4. The user now has experience with the software. Therefore, new
requirements and the direction of change can be ascertained with
greater ease.
5. CASE tools for reengineering will automate some parts of the job.
6. A complete software configuration (documents, programs and
data) will exist upon completion of preventive maintenance.

Mr. M. E. Patil
21

Smqa unit v

Recommended

More Related Content

Recently uploaded (20)

Featured (20)

Smqa unit v