Scribd
Upload
56 views

Cleanroom Software Engineering (AB)

The cleanroom software engineering process uses formal specification, design verification, and statistical testing to develop reliable software incrementally. It aims to produce software with a certifiable level of reliability of less than 5 failures per 1000 lines of code during initial use. Key aspects include peer code reviews, incremental development, usage modeling, correctness verification, and measuring reliability through statistical testing and quality certification. The goals are zero failures in the field, short development cycles through avoidance of rework, and longer product life through detailed specifications and usage models.

Uploaded by

Muhammad Taha
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
56 views

Cleanroom Software Engineering (AB)

The cleanroom software engineering process uses formal specification, design verification, and statistical testing to develop reliable software incrementally. It aims to produce software with a certifiable level of reliability of less than 5 failures per 1000 lines of code during initial use. Key aspects include peer code reviews, incremental development, usage modeling, correctness verification, and measuring reliability through statistical testing and quality certification. The goals are zero failures in the field, short development cycles through avoidance of rework, and longer product life through detailed specifications and usage models.

Uploaded by

Muhammad Taha
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 13

CLEANROOM SOFTWARE

ENGINEERING
WHAT IS IT ?

• The cleanroom software engineering process is a


software development process intended to produce
software with a certifiable level of reliability.
• Cleanroom software engineering involves the
integrated use of
• software engineering modeling
• program verification
• statistical software quality assurance.
· Verifies design specification using mathematically-
based proof of correctness
• Relies heavily on statistical use testing to uncover
high impact errors
CLEANROOM IS SHIFT IN PRACTICE

From To
• Individual craftsmanship • Peer reviewed
• Sequential development engineering
• Incremental
• Individual unit testing
development
• Informal coverage • Team correctness
testing verification
• Unknown reliability • Statistical usage testing
• Informal design
• Measured reliability
• Disciplined engineering
specification and design
INCREMENTAL DEVELOPMENT
OR
CLEANROOM SOFTWARE ENGINEERING

Frozen
specification

Establish Formal Develop s/w Deliver


rerquirements specification increment software

Requir ements change request


BENEFITS

• Zero failures in the field


• that’s the goal any way
• a realistic expectation is < 5 failures per KLOC on first
program execution in the first team project
• Short development cycles
• results from use incremental strategy and avoidance of
rework
• new teams should experience a two-fold productivity
increase on the first project and continue the increase
• Longer product life
• investments detailed specifications and usage models
help keep a product viable longer
WHY ARE CLEANROOM TECHNIQUES NOT
WIDELY USED
1. Some people believe cleanroom techniques are
too theoretical, too mathematical, and too
radical for use in real software development
2. Relies on correctness verification and statistical
quality control rather than unit testing (a major
departure from traditional software
development)
CLEANROOM ACTIVITIES

• There are five major activities involved in a


Cleanroom process
• Specification
• Increment Planning
• Design and Verification
• Statistical Testing
• Certification
• Two to three independent teams may exist and
work concurrently
• Development Team
• Testing (or Certification) Team
• Documentation Team
SPECIFICATION

• Two specifications are produced: functional and usage.


• Functional Specification
• Defines the required external system behavior in all
circumstances of use.
• Forms the basis for incremental software development.
• Usage Specification
• Defines usage scenarios considering:
• User - person, hardware device or other software; subclasses may
exist
• Use - a particular work session or transaction; bounded by specific
start and end events
• Environment - platform, OS environment, system load, etc.
• Forms the basis of statistical testing and quality certification.
INCREMENT PLANNING

• On the basis of the functional and usage specifications, a plan


is formulated for developing the software in well-defined
increments which will accumulate into a final system.
• Each increment is developed through a full Cleanroom process
of Specification, Design, Verification, Testing, and Certification.
• A pipeline of increments is created to produce the complete
system.
• Each increment defines a complete system with added
functionality from previous increments.
• Increments are defined according to
• Size - increments should be relatively small and of manageable size
• Concurrency - potential for parallel development can be exploited
• Cohesiveness - increments should be cohesive with respect to their
functional requirements
INCREMENTAL DEVELOPMENT

Development Inc
Inc11 Inc
Inc22 Inc
Inc33 Inc
IncNN

Testing and Certification Inc


Inc11 Inc
Inc1,2
1,2
Inc
Inc
1,2,3
1,2,3
... Inc
Inc
1..N
1..N

The Configuration Inc


Inc11 Inc
Inc11

Inc
Inc22 Inc
Inc33

Inc
Inc44
DESIGN AND VERIFICATION

• The development team carries out a


design and correctness verification cycle
for each increment.
• The certification team works in parallel,
using the usage specification to generate
test cases that reflect the expected use of
the accumulating increments.
STATISTICAL TESTING

• Testing software according to the way users intend to use it.


• The entire focus is on external system behavior, not the
internals of the design or implementation.
• The certification team’s goal is not to debug, but to certify
the the software’s quality. This requires deep knowledge of
expected usage but no knowledge of design or
implementation information.
• Three steps
• Specify usage probability distributions
• Derive test cases that are randomly generated from usage
probability distributions.
• Execute test cases, assess results, and compute quality
measures.
CERTIFICATION

• Based on the data gathered during


statistical testing, the software can be
given a certified reliability.
• Reliability is expressed as MTTF and is
computed according to specific
mathematical reliability models
• Sampling model
• Component model
• Certification model

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy