CleanRoom Software Engineering

1
CleanRoom Software Engineering

• By Jonathon Fischer

2
Overview

• What is Cleanroom SE
• The Cleanroom process
• Cleanroom results

3
What is CleanRoom SE?

• Created by IBM in the early 80s
• Named after cleanrooms used in Semiconductor
  Industry

4
What is Cleanroom SE? (cont.)

• Iterative 14 step process
• Goal of 0 or near 0 errors
• All errors account for by compile time
• No Unit testing
• Developers dont compile the system.

5
4 teams of Cleanroom SE

• 4 teams
• Management
• Tracks progress and budget
• Specification
• Defines required functions and usage of system
• Development
• Creates the system
• Certification Team
• Tests the system against specifications

6
Cleanroom Flow
7
Project Planning Process

• Adapt process model to project
• Cleanroom Engineering Guide
• Create project Plan
• Software Development Plan
• Review Plan with customer and team members

8
Project Management Process

• Begins the Cleanroom process
• Defines incremental development and certification
• Measures for correctness testing defined

9
Project Improvement Process

• Find ways to improve performance and facilitate
  changes
• Create Performance Improvement Plan
• Made prior to a change
• Outline additional training for change
• Revise Cleanroom Engineering Guide
• Usually, changes started at milestones

10
Engineering Change Process

• Make changes to the product
• Faults or failures are found
• Must be compliant with the Configuration
  Management Plan
• Changes recorded in Engineering Change Log
• Change evaluated for correctness and impact

11
Architecture Specification Process

• Decomposes the project
• Requirements and Specifications must be partially
  complete
• Start at high level of abstraction and go lower
• Black box to Clear box
• Generate analysis models

12
Requirements Analysis Process

• Started immediately after work order is received
• Work with customers to determine
• What the system does
• How it will be used
• Preferred Environment
• Repeated each iteration or if requirements added
• Most stable requirements implemented first

13
Function Specification Process

• Determine unambiguous user scenarios regardless
  of probability of occurrence
• Recorded in Function Specification Doc
• Mathematically representation of reqs
• Each spec linked to at least 1 req
• Written in Black box style

14
Usage Specification Process

• Determine info about the users
• Type of user
• User environment
• Started when Functions Specifications is
  partially complete.
• Provides a way to effectively allocate resources
• Helps to complete and validate Function Specs.

15
Increment Planning Process

• Create/revise Increment Construction Plan
• Helps to determine
• Elements to complete immediately
• Elements to stub out and finish on a different
  iteration
• Using incrementation allows for mistakes to be
  caught and fixed earlier.

16
Software Reengineering Process

• Used when incorporating reused software
• Prior to integration determine
• Reliability of software
• Benefits outweigh cost of integration
• Integration can be done
• As is
• With a wrapper for limited access
• Reengineered to better fit project

17
Incremental Design Process

• Implements Incremental Construction Plan
• Input code here!
• Multiple reviews
• Assess progress of current increment
• Determine changes to keep verification and
  project maintainability
• Goal few faults as possible before Correctness
  Verification

18
Correctness Verification Process

• Verifies the program will work to specifications
  without running the system
• Uses proofs and mathematical methods for
  verification
• Program structures broken down to mathematic
  equivalence
• Correctness Verification is more effective and
  efficient than Unit testing
• Can accurately predict almost infinite number of
  execution paths
• Unit testing can only do so much

19
Usage Model and Test Planning Process

• Usage model created from refined specs
• Cover a broad range of modules
• Especially ones where failure is unacceptable
• Shows each state and transitions
• Create Incremental Test Plan
• Models and test Plan determine
• Test cases
• Testing environment

20
Statistical Testing and Certification Process

• Final phase for each increment
• Code is run for the first time.
• Tests are performed according to Incremental Test
  Plan
• Test results compared to function specs
• Each result used to determine measurement of
  system for Certification
• Failure gt return to Incremental Design
• Success gt proceed according to Increment
  Construction Plan

21
First Cleanroom Project

• IBM 1988
• Program automatically restructured COBOL code
• Contained 33 KLOC
• In first 3 years of use
• 7 errors found
• All were easy fixes.

22
NASA and Cleanroom SE

• 1989 FORTRAN satellite controller
• 40 KLOC, only 4.5 errors / 1KLOC
• 40 increase in quality
• 80 increase In productivity
• 780 LOC per person month!!
• Ave. embedded system 40 160 LOC/pm
• Ave. commercial system 200 800 LOC/pm

23
Review

• 14 step iterative process
• Goal of 0 or near 0 errors
• No Unit testing
• Seems difficult, but can have amazing results

24
Questions ?
25
Sources

• Hausler, P. A., Linger, R. C. (1994).
  Adopting Cleanroom Software Engineering With a
  Phased Approach. IBM Systems Journal, Volume 33,
  Issue 1, p89. EBSCOhost.
• Linger, R. C., Trammell, C. J. (November 1996).
  Cleanroom Software Engineering Reference Model,
  Verison 1.0. found at
• http//www.sei.cmu.edu/pub/documents/96.reports/p
  df/tr022.96.pdf
• Oshana, R. Quality Software Via a CleanRoom
  Methodology. Embedded Systems Programming.
  Found at http//www.embedded.com/97/feat9609.ht
  m
• Steward, Donald V. (1987). Software Engineering
  with Systems Analysis and Design.Monterey, CA,
  Brooks/Cole Publishing Company.
• Uta.edu. Cleanroom Sotware Engineering. Found
  at http//www.uta.edu/cse/levine/fall99/cse5324
  /cr/clean/page.html