Docsity
Docsity
Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity

Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan

Guidelines and tips
Guidelines and tips
Sell on Docsity
Sell on Docsity
Docsity AI
Docsity AI
Log inSign up

Prepare for your exams

Study with the several resources on Docsity

Find documents

Prepare for your exams with the study notes shared by other students like you on Docsity

Search for your university

Find the specific documents for your university's exams

Docsity AINEW

Summarize your documents, ask them questions, convert them into quizzes and concept maps

Explore questions

Clear up your doubts by reading the answers to questions asked by your fellow students

Earn points to download

Earn points by helping other students or get them with a premium plan

Share documents
download point icon20 Points

For each uploaded document

Answer questions
download point icon5 Points

For each given answer (max 1 per day)

All the ways to get free points
Get points immediately

Choose a premium plan with all the points you need

Study Opportunities

Choose your next study program

Get in touch with the best universities in the world. Search through thousands of universities and official partners

Community

Ask the community

Ask the community for help and clear up your study doubts

Free resources

Our save-the-student-ebooks!

Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors

Cleanroom Software Engineering: Mathematical Approach for Low Defects & High Productivity, Exams of Software Engineering

Georgia Institute of Technology - Main CampusSoftware Engineering

Cleanroom software engineering is a methodology that aims to achieve software quality through mathematically sound design and statistically-valid testing. Developed by harlan mills at ibm in the 1980s, it is based on the principles of electronic component manufacture and uses statistical quality control features. The objective is to achieve quality by design rather than through testing, resulting in software with near-zero defects at delivery. Key features include usage scenarios, incremental development and release, separate development and acceptance testing, program proofs, and formal specification. Defect rates are significantly lower than traditional methods, and productivity is improved by 3-5 times. Cleanroom tools include a test case generator, reliability analysis package, and verification-based inspection syntax analyzer.

Typology: Exams

Pre 2010

Uploaded on 08/05/2009

koofers-user-grq
koofers-user-grq 🇺🇸

10 documents

1 / 6

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
1
• Cleanroom
– attempt to mathematically-based, scientific engineering
process of software development
– “Cleanroom software engineering yields software that
is correct by mathematically sound design, and
software that is certified by statistically-valid testing” –
SEI
– Objective: achive quality by design rather than through
testing – time is spent in design and verification
• Harlan Mills (Linger, Dyer, Poore), IBM, 1980
• Analogy with electronic component manufacture
• Use of statistical quality control features
• Certified software reliability
• Improved productivity; (near) zero defects at
delivery
• Unit – software use
– can be defined in number of ways based on application
Key Features
• Usage scenarios; statistical modeling
• Incremental development and release
• Separate development and acceptance
testing
• Program proofs; no unit testing
Defect Rates
•Traditional
– Unit testing: 25 faults / KLOC
– System testing: 25 / KLOC
– Inspections: 20 - 50 / KLOC
• Cleanroom
– < 3.5 / KLOC delivered
– Average 2.7 / KLOC between first execution
and delivery
pf3
pf4
pf5

Partial preview of the text

Download Cleanroom Software Engineering: Mathematical Approach for Low Defects & High Productivity and more Exams Software Engineering in PDF only on Docsity!

  • Cleanroom
    • attempt to mathematically-based, scientific engineering process of software development
    • “Cleanroom software engineering yields software that is correct by mathematically sound design, and software that is certified by statistically-valid testing” – SEI
    • Objective: achive quality by design rather than through testing – time is spent in design and verification - Harlan Mills (Linger, Dyer, Poore), IBM, 1980 - Analogy with electronic component manufacture - Use of statistical quality control features - Certified software reliability - Improved productivity; (near) zero defects at delivery - Unit – software use - can be defined in number of ways based on application

Key Features

• Usage scenarios; statistical modeling

• Incremental development and release

• Separate development and acceptance

testing

• Program proofs; no unit testing

Defect Rates

• Traditional

  • Unit testing: 25 faults / KLOC
  • System testing: 25 / KLOC
  • Inspections: 20 - 50 / KLOC

• Cleanroom

  • < 3.5 / KLOC delivered
  • Average 2.7 / KLOC between first execution and delivery

Basic Technologies

• Box-Structured

• Specification

• Function-theoretic verification

  • before any code is compiled/executed
  • debugging not permitted

• Statistical usage testing

Incremental Development

  • Typical system < 100KLOC
  • Increment: 2 - 15KLOC
  • Team size < 14 (6-8)
  • Each increment End - to - End
  • Overlapped development of increments
  • 12 - 18 weeks from beginning of specification to end of test
  • Partitioning is difficult and critical

Formal Specification

• Box-structured design

  • Black box: stimulus-response
  • State box: formal model of system state
  • Clear box: hierarchical breakdown

• Program functions

• Verification properties of control structures

Statistical Usage Testing

  • Certification of reliability
  • Process control
  • Cost-effective orientation
  • Guidelines for test completion (desired reliability reached) or redesign (too many failures found)
  • Stratification mechanism for dealing with critical situations
  • But questions exist on how to feed back the results of testing to the development team

Testing process

  • Usage distribution models
    • From competitors, earlier versions, analysis
  • Markov usage chain
    • State transition probability matrix
  • Statistics
    • Π (proportion of time spent in each state)
    • n (number of states visited before a given state is reached)
    • s (number of tests needed to reach a state).
  • Random test generation
    • Design required
  • Test execution and test chain generation, including failure states
  • Statistics
    • R (reliability)
    • MTBF (mean time between failures)
    • D (divergence of test chain from usage chain)