sss ssss rrrrrrrrrrr
ssss ss rrrr rrrr
sssss s rrrr rrrr
ssssss rrrr rrrr
ssssssss rrrr rrrr
ssssss rrrrrrrrr
s ssssss rrrr rrrr
ss sssss rrrr rrrr
sss sssss rrrr rrrr
s sssssss rrrrr rrrrr
+===================================================+
+======= Testing Techniques Newsletter (TTN) =======+
+======= ON-LINE EDITION =======+
+======= June 1996 =======+
+===================================================+
TESTING TECHNIQUES NEWSLETTER (TTN), On-Line Edition, is E-Mailed
monthly to support the Software Research, Inc. (SR) user community and
provide information of general use to the worldwide software testing
community.
(c) Copyright 1996 by Software Research, Inc. Permission to copy and/or
re-distribute is granted to recipients of the TTN On-Line Edition pro-
vided that the entire document/file is kept intact and this copyright
notice appears with it.
========================================================================
INSIDE THIS ISSUE:
o When the Pursuit of Quality Destroys Value (Part 2 of 2), by John
Favaro
o Software Investments Strategy (Part 2 of 3), by L. Bernstein and
C. M. Yuhas
o Six Sigma: Hardware Si, Software No! (Part 1 of 2), by Robert V.
Binder.
o QW'96 Chair's Final Comments, by Edward Miller
o Quality Week Proceedings Available
o Call for Papers: 1996 Asia-Pacific Software Engineering Confer-
ence (APSEC '96)
o Cleanroom Software Engineering Education
o TTN SUBMITTAL POLICY
o TTN SUBSCRIPTION INFORMATION
========================================================================
WHEN THE PURSUIT OF QUALITY DESTROYS VALUE (Part 2 of 2)
John Favaro,
Intecs Sistemi S.p.A.
ITALY
New views of mature ideas on software and quality productivity.
Note: In this article software engineering expert John Favaro points out
how our software efforts are embedded in the larger, more complex busi-
ness world. Quality must be considered in that context.
(Part 2 of 2)
FANATICAL QUALITY. I once asked a colleague what he could tell me about
another colleague I had just met. He gave me a wry smile and said,
"He's a quality man." He was referring, of course, not to quality
itself but to a certain culture that often leads to fanaticism. George
Newman put it this way ("The Case Against Quality." Across the Board,
June 1991, p. 58):
...the fadmongers [of quality] have converted a pragmatic, economic
issue into an ideological, fanatical crusade. The language is reveal-
ing. The terms of quality as an economic issue are analysis, cost,
benefit, and tradeoff. The terms of quality as a crusade are total, 100
percent quality, and zero defects; they are the absolutes of zealots.
This language may have its place in pep talks...but once it is taken
seriously and literally, we are in trouble.
As we put into place comprehensive programs like ISO 9000 to fulfill a
much-needed purpose, we must resist the tendency to build bloated, over-
zealous quality organizations that will grind down our companies' finan-
cial performance.
PREREQUISITE: QUALITY. In markets such as aerospace and defense, it is
increasingly common to require that vendors supply some "quality guaran-
tee" before even being allowed to bid on a project: ISO 9000 certifica-
tion or an SEI assessment, for example. In these cases, quality certif-
ication effectively becomes a "union card" for market participation.
This trend will likely spread to other markets. Given the level playing
field created by universal mandatory certification, only the finest
quality practitioners in such markets are likely to see any economic
rewards that can be directly linked to quality. Thus, quality by itself
is no longer a strategy that will ensure a competitive advantage. We
must learn to use quality intelligently, as one component of our overall
business strategy.
CUSTOMER SATISFACTION. Many who implement a quality program these days
focus on customer satisfaction. Surely, they reason, happier customers
must lead directly to higher profits. This is not necessarily the case.
Figure 1 demonstrates the potential consequences of pursuing such a
strategy. This graph, drawn from Marakon Associates' research, shows
four possible scenarios, each illustrated with a real-world example, in
which the value offered to the customer may be more aligned or less
aligned with the economic benefits received by the company.
Scenario 1. Satisfied customers mirror the company's financial gains.
In 1990, Microsoft introduced Windows 3.0, which was enormously success-
ful with its satisfied users and enormously profitable for the company.
Scenario 2. The value offered to customers is greater than the return
on investment made by the company. General Magic is incorporating its
justly praised Magic Cap and Telescript software into a new generation
of personal digital assistants, offering at reasonable prices to its
customers an innovative and reliable software technology. Yet the enor-
mous overhead of creating this technology caused General Magic to lose
tens of millions of dollars, and some now doubt that the company will
ever achieve its long-term goals (C. Matsumoto, "General Magic's
Motorola, AT&T Accounts Go Poof." San Francisco Business Times, Sept. 8,
1995).
Scenario 3. The product offers more value than customers will pay for.
The Environmental Systems Research Institute's ArcInfo product has long
been a leader in the geographic-information-system market. It comes
with a high price tag and relies on powerful workstation technology to
provide comprehensive, high-quality GIS services that range from data
entry to visualization. Recently, after noting the entry of less expen-
sive, PC-based systems into the market, ESRI reacted by offering a much
lower priced, Windows-based version of ArcInfo, called ArcView, which
offers customers GIS data visualization but not data-entry capabilities.
Despite the lower reliability and capacity of the Windows environment,
ArcView has been very successful and satisfied a large segment of the
GIS user community whose requirements are less stringent and whose pock-
ets are less deep.
Scenario 4. Declining customer satisfaction matches a decline in the
company's fortunes. Digital Equipment Corporation is only now recover-
ing financially from the flight of dissatisfied customers away from its
proprietary operating systems and network software. Through its embrace
of open-systems technologies, Digital is beginning to recapture some of
its lost customer base.
These scenarios show that conflicts can arise between your economic
interests and those of your customers in many ways. Focusing narrowly
on quality and customer satisfaction will not address or resolve these
conflicts.
Finally, in today's rapidly changing environment, even satisfied custo-
mers may quickly find more appealing alternatives. IBM was widely
congratulated on the acquisition of Lotus Development Corporation and
its successful, highly popular Lotus Notes product. But the wisdom of
that acquisition is already being questioned as users abandon Lotus
Notes - which must be installed on each network PC - in favor of using
the Internet to download an application only when needed.
FUTURE STRATEGY. What can you do to avoid the trap of pursuing quality
and customer satisfaction at any cost? First, simply be aware that
quality for quality's sake won't do. You need a strategic decision-
making framework that directly addresses topics such as market partici-
pation, resource allocation, and product-pricing issues. Having taken
that step, you can acquaint yourself with several approaches, such as
the concept of Return on Quality used in corporations such as AT&T
("Quality: How to Make It Pay," Business Week, August 8, 1994). ROQ
evaluates prospective quality improvements against their ability to also
improve financial performance.
Even better, familiarize yourself with management approaches that
integrate quality within a strategic framework such as value-based
management. VBM compromises a set of principles and processes that link
quality-related factors explicitly to economic value, illuminating the
inevitable tradeoffs:
- improvements in product quality versus higher economic costs,
- return on investment versus market share, and
- short-term results versus market competition.
Quality applied properly can enhance the value of your products, improv-
ing both your competitive advantage and financial performance. Used
improperly, quality can and does destroy value. You can avoid this by
using quality not as an end in itself but as a solid contributor to the
overall decision-making framework of your business.
About the Author: John Favaro is a senior consultant at Intecs Sistemi
(http://www.pisa.intecs.it) in Pisa, Italy. He may be contacted at
favaro@pisa.intecs.it.
========================================================================
Software Investments Strategy (Part 2 of 3)
by
Lawrence Bernstein and C. M. Yuhas
However, the big payoff of the expansion factor comes in the threefold
increase in productivity due to object-oriented programming and another
doubling when 80% reuse is achieved. Object-oriented programming is on
the horizon, but it presents a difficulty for reuse because it is so
obscure. The bottom-up design takes greater insight than top-down
design and early decisions can have long-reaching effects. To retrain
programmers from procedural to object-oriented programming takes 3 to 6
months of full time education. Even then, not everyone will be success-
ful. Large-scale reuse is a deeply frustrating and elusive goal.
To reuse or not to reuse?
The literature shows [Desm94 and Poul93] that it takes 1.5 to 2.2 times
the effort to write a software module in a way to be a reusable asset:
1. Standard interfaces to the operating system must exist and be fol-
lowed. For example, kernel changes to UNIX are not acceptable. This
reduces flexibility in handling new communication protocols.
2. Standard approaches to module interfaces must apply universally.
Abstract mechanisms, such as self-describing tag-value interface design,
can penalize performance.
3. Application generators need to produce about 25% of the product,
especially for user interfaces.
Roger Pressman[Pres94] points out in reference to the first two points
that there are wizards like Ken Thompson of UNIX fame who can whip out
thousands of lines of defect-free, crystalline code in some weeks, but
these constitute less than 0.5% of the programming population. All the
rest need to follow formal processes, which presumes a software theory
of design constraints to assure stable dynamic behavior of modules.
This has yet to be articulated.
The keeper of a reusable module faces the formidable task of having to
know all users when the owner must change it. Take, for example, "diff"
in UNIX, the most reused module on earth. Not many understand how it
works and fewer still try to change it. Here is a fable for our time,
told by Doug McIlroy, the AT&T Bell Laboratories inventor.
The Tale of "diff" -- A Caution for Developers of Reusable Modules
Once upon a time, there was a mathematical problem of finding the long-
est subsequence of lines common to two files. "No sweat," thought the
developer. A dynamic programming technique that takes time mn and space
mn to compare an m-line file to an n-line file would do the trick. But
space mn was unacceptable on the small machines of yesteryear. "OK,
we'll fly seat of the pants," thought our hero. So he read through both
files until he found a line that disagreed, then figured he would
somehow search forth in both until he got back in sync. 'Somehow' was
the killer. Suppose the second line in one file agreed with the fourth
line ahead in the other and vice versa. How to choose?
Then news came from afar in Princeton that the Wizard Hirschberger had
seen a way to reduce space mn by a mathematical method to space m, while
only doubling the time. "Good deal!" thought our guy. "Now we can
afford to run it. It was slow, but it did work and gave an explainable
'right' answer in a clearly defined way."
But the people complained. When they moved a paragraph, it showed up as
two changes, a deletion here and an addition there. So our hero made a
"diff" that found moves. It was again seat of the pants, but it ran
pretty well. Yet, sometimes, an evil occurred. If the people ran it on
stuff where the same line occurred in many places, like assembly
language or text processing, it discovered lots of deletions and addi-
tions that could be explained as moves. Our hero was filled with con-
sternation.
Then along came a shining knight, Harold Stone, with a dynamic program-
ming technique that reduced the running time from the product to the sum
of the file lengths, except in unnatural cases. Now here was something
fast enough to use on big files, efficient in space and time, mathemati-
cally justifiable as giving a good answer, and experimentally shown to
be physiologically useful. "O frabjous day! Calloo, callay!" he chor-
tled in his joy.
But then the people tinkered. Three times they altered output. They
added features. They added stars! And the tinkering caused the code to
increase and the manual to swell to half again its size. "Well," said
our guy. "It is important to know when to stop."
Reuse becomes profitable with the third use of a module. Studies of the
reuse of 2,954 modules of NASA programs[Selb88] showed that to reap the
benefits of the extra original effort to make a module reusable, it must
be reused virtually unchanged. No change costs 5%; the slightest change
drives the cost up to 60%. The clear message is that when you reuse a
module, do not modify it. The issues of who pays the differential and
who pays for ongoing support remain serious barriers to reuse. Within
an organization, however, success is possible.
These are the problems with reuse:
1. We have been unable to systematically reuse software across applica-
tion domains.
2. Reuse is successful only when throughput and response time are not
overriding concerns.
3. We have been unable to maintain an asset base of software modules
except when they are in C libraries and when they are utility functions.
4. We have had to maintain a high level of management attention to
detail to assure reuse success.
5. We have been unable to sustain an investment in making application
components reusable.
6. We have been unable to avoid exhaustive re-testing when reusing
modules.
7. We have trouble deciding to shift to new technology when we have a
library of reusable modules.
Ready or Not, Here Come Objects
Bjarne Stroustrup, inventor of C++, says that moving to object oriented
programming is not painless but it is worthwhile. Here is his list of
reasons for using Object Oriented Technology:
1. It forces one to think about architecture and design from the begin-
ning, not just as an afterthought.
2. Your programs will be more modular, hence easier to maintain and
extend.
3. If you design your system as a collection of classes with clean
interfaces between them, others may be able to use them.
4. You will be able to take advantage of the new generation of design
and implementation tools now becoming available.
( T O B E C O N T I N U E D )
Editors Note: Lawrence Bernstein is a frequent contributor to TTN-
Online. C. M. Yuhas is a freelance writer whose articles have appeared
in many IEEE publications, UNIX Review, DATAMATION, in COMPUTERWORLD and
in the International Journal of Systems and Network Management.
CONTACT INFORMATION: C. M. Yuhas, Freelance Writer, 4 Marion Ave. Short
Hills, NJ 07078.
========================================================================
Six Sigma: Hardware Si, Software No! (Part 1 of 2)
Robert V. Binder.
Copyright 1996, Robert V. Binder. All Rights Reserved
SUMMARY: Six sigma is a parameter used in statistical models of the
quality of manufactured goods. It is also used as a slogan suggesting
high quality. Some attempts have been made to apply 6 sigma to software
quality measurement. This essay explains what 6 sigma means and why it
is inappropriate for measuring software quality.
What is Six Sigma?
Six sigma means six standard deviations. A standard deviation is a
parameter which characterizes a set of measurements, just as the average
can characterize such a set. One standard deviation is a value such
that roughly two-thirds of all values in a set fall within the range
from one standard deviation below average to one standard deviation
above average. Sets of values which can be characterized by the average
and standard deviation may be modeled by the _normal distribution_, also
known as the "bell-shaped curve". With a larger coefficient for sigma
(1 sigma, 2 sigma, ... , 6 sigma) more of the set is included,
corresponding to a larger area under the bell-shaped curve. (See any
introductory text on statistics for more on this, e.g. [1].)
In most informal discussions, "x sigma" means the range _x_ standard
deviations above and below the average, or a span of 2_x_ (i.e., +- _x_
sigma.) For 6 sigma the total range spans 12 standard deviations. As the
sigma value increases, a larger area under the "bell curve" is included:
50% at +- 0.67 sigma, 68.3% at +- 1 sigma, 99.7% at +-3 sigma, >
99.999999% at +- 6 sigma.
1. What is the Quality Significance of Six Sigma?
As a concept in statistical quality models of physical manufacturing
processes, 6 sigma has a very specific meaning.[2]
Manufactured parts typically have a nominal design value for charac-
teristics of merit. For example, the nominal design diameter of a shaft
is 1.0 mm, weight 45mg, etc. Processes which produce parts are typi-
cally imperfect, so the actual value for characteristics of merit in any
given part will vary from nominal. Assemblies which use these parts must
be *designed* to tolerate parts with such variances. Determining these
tolerances is a classical systems engineering problem. However, once
set, any part that exceeds these limits is defective.
While it might seem that a 3 sigma tolerance is generous, it turns out
to result in a (typically) unacceptable rate of defects in multi-part
products. With 6 sigma tolerances, a single part, and stable production
process, you'd expect to have only 2 defects per billion. However,
manufacturing processes vary from batch to the next, so the batch aver-
age for a characteristic often drifts between +- 1.5 sigma. If the mean
of a batch happens to be at either extreme, many of the parts will be
defective (with a 3 sigma standard, 66810 in a million). Assuming a +-
1.5 sigma process drift, 6 sigma tolerances will result in 3.4 defects
per million parts.
Interestingly, parts and products designed to 6 sigma tolerances
tolerate *more* deviance from nominal values than those designed for
lower sigma values. It is easier to achieve a conforming part/product
designed to 6 sigma than to 3 sigma because more variance from nominal
is acceptable. This is quite the opposite of what one might expect for
a "high quality" result.
Multi-part products compound the drift problem. The expected number of
defective units for a single-part product can be modeled by the distri-
bution for that part. But as the number of parts in a product
increases, the chance of getting a product with no defective parts
drops. If all parts are designed to 3 sigma, the chance of getting a
defect free product with 100 parts is 0.0013. However, if all part
design tolerances are extended to 6 sigma, the chance of a defective
product with 10000 parts is less than 0.04 -- or, putting a more cheery
spin on this, you'd expect that at least 96% of the 10000 part products
would be defect free with 6 sigma design limits and no more than +-1.5
sigma process drift (note this assumes no faulty interactions among
"good" parts can occur.)
This is how Motorola has set their "Six Sigma" standard and why Lee Tre-
vino (in a Motorola commercial) says he'd have to make over three mil-
lion perfect golf shots to meet this goal. The related design strategy
is straightforward: fewer parts, simplify the process, reduce the number
of critical tolerances per part. (6 sigma processes are only part of the
strategy for high quality manufacturing.)
2. Should the Six Sigma Manufacturing Model be Applied to Software?
In a word, no. While high quality software is a good thing, there are at
least three reasons why the 6 sigma model does not make sense for soft-
ware.
2.1 Software Processes are Fuzzy.
Every software "part" is produced by a process which defies the kind of
predictable mechanization assumed for physical parts. Even at SEI level
5, the simple variation in human cognitive processes is enough to obvi-
ate applicability. The behavior of a software "process" is an amorphous
blob compared to the constrained, limited, and highly predictable
behavior of a die, a stamp, or a numerically controlled milling machine.
( T O B E C O N T I N U E D )
Contact Information:
---------------------------------------------------------------------
Bob Binder rbinder@rbsc.com RBSC Corporation
312 214-3280 tel http://www.rbsc.com 3 First National Plaza
312 214-3110 fax Suite 1400
847 475-3670 tel/fax Chicago, IL 60602-4205
---------------------------------------------------------------------
========================================================================
QW'96 CHAIR'S FINAL COMMENTS
Edward Miller
30 May 1996
The Ninth Annual International Software Quality Week, QW'96, held 21-24
May 1996 in San Francisco, was an especially fine success. This note is
a kind of ``Program Chair's Final Report'' to the attendees, and to all
others who may be interested.
The Attendees...
Over 825 attended the four-day QW'96 event with around 10% from the
greater San Francisco Bay area, 40% originating from the elsewhere in
the Western USA, 40% from the Eastern USA and 10% from outside the USA.
QW'96 attendees came from over 20 countries, coming from as far as Hong
Kong and Finland. Delegates from over 375 different companies, ranging
in size from consultancies to giant international corporations, attended
the event.
The Speakers...
QW'96 involved 75 speakers (Keynoters, Tutorial Presenters, Quick-Start
Presenters, and regular Speakers) from 11 different countries. QW'96
speakers' backgrounds were about equally divided among industrial
researchers, academics, and real-world practitioners.
The Sponsors...
Quality Week '96 was the first event of its kind to receive sponsorship
status from both the IEEE Computer Society (under authorization of the
Computer Society Steering Committee) and ACM (Association for Computing
Machinery) The QW'96 event was organized by SR/Institute's Executive
Director, Ms. Rita Bral.
The Exhibitors...
QW'96's vendor area had 29 exhibiting companies (listed in alphabetic
order): Atria Software, AutoTester, Automated Testing Solutions, AZOR,
Inc., British Standards Institution, Inc., Bullseye Software, Center for
Software Development, Centerline, Clarify, Direct Technology, Eden Sys-
tems, Eastern Systems, IEEE Computer Society, I.Q. Company, IntegriSoft,
ISA, Microsoft Corporation, Mercury, Performance Awareness, Peritus
Software, Pure Software, Rational Software, Segue, Softfront, Software
Research, Inc., Software Quality Engineering, Software Engineering Tech-
nologies, Software Testing Laboratories, and Teradyne, Inc.
What People Said about QW'96...
Here is a small sampling of comments from attendees...
...A good blend of academic, industry and marketing...
...Presentations provided real world techniques and best practices...
...Plenary sessions were excellent...
...Organization excellent! Keep up the good work! This was the best
Quality Week ever!
...A variety of sessions and being allowed to move freely in and out of
them...
...Separate tracks aided participants...
...The [QW'96] proceedings will make an excellent reference...
The Advisory Board...
The technical strength of QW'96 is the work of the international
Advisory Board, composed 75% from the USA and 25% from outside the USA.
They worked tirelessly to review the 185 proposed presentations, and all
of us on the Quality Week Team express our real thanks to them for a job
well done!
Our Thanks...
Please allow me this opportunity to express the Quality Week Team's
thanks to all the speakers who made the event possible, to the Advisory
Board who served so well, and especially to the four Track Chairs (Dr.
Boris Beizer, Dr. Bob Birss, Mr. Bill Bently and Mr. Rob Schultz) who
kept things on track so admirably during the event.
Finally, let me express my personal thanks to all of the QW'96 team --
organizers, Advisory Board members, speakers, and attendees -- for mak-
ing QW'96 the best and most productive event ever.
Edward Miller
QW'96 General Chair
(miller@soft.com)
========================================================================
QUALITY WEEK PROCEEDINGS AVAILABLE
Limited numbers of copies of the Proceedings and Tutorial Notes for
Quality Week 1996 and prior years are available from SR/Institute. Sim-
ply print out the form below, complete it and FAX it to: +1 (415) 957-
0730.
- - - - - - - - - c u t h e r e - - - - - - - - -
Quality Week -- Request for Proceedings & Tutorial Notes
Yes, my company is interested in acquiring the Proceedings of the Inter-
national Quality Week Conferences. I request the following publications
to be shipped to me as indicated on this form:
[ ] Quality Week Proceedings 1996 $75
[ ] Quality Week Proceedings 1995 $50
[ ] Quality Week Proceedings 1994 Sold Out
[ ] Quality Week Proceedings 1993 $50
[ ] Quality Week Tutorial Notes 1996 $50
[ ] Quality Week Tutorial Notes 1995 $50
[ ] Quality Week Tutorial Notes 1994 $50
Shipping and Handling (per publication):
USA: [ ] UPS ground: $15
[ ] Airborne 2nd Day Air: $20
[ ] Airborne Next Day Air: $25
Canada: [ ] Ground: $15
[ ] Airborne: $67
Europe: [ ] US Postal Service, by ship $35 (6 weeks to 2 months)
[ ] Next Day Air $73
Pacific Rim: [ ] US Postal Service, by ship $35 (6 weeks)
[ ] Next Day Air $72 (Tokyo, Hong Kong)
[ ] UPS (Approx. 1 week) $70 (Singapore)
[ ] Next Day Air $88 (All Other Asia)
Number of copies ordered: _________ Total Price: $_________
Advance payment by check, credit card, or Company P.O.:
[ ] Check
[ ] Company Purchase Order
[ ] Credit Card:
[ ] Visa_______________________ Exp._______
[ ] MasterCard_________________ Exp.______
Advance payment by International Wire Transfer to::
Name: Software Research Institute
Account Number: 0052-078029
Address: Wells Fargo Bank
Brannan Office
601 Third Street
San Francisco CA 94107
Routing Number: 121-000-248
Please send the Quality Week Proceedings without delay to my attention:
Name:____________________________________Title:________________________
Company:______________________________________________________________
Street: ________________________________________________________________
City:___________________________________State:____ Zipcode: ___________
Signature: _____________________________________________________________
- - - - - - - - - c u t h e r e - - - - - - - - -
========================================================================
*********************************
* C A L L F O R P A P E R S *
*********************************
A P S E C '9 6
1996 Asia-Pacific Software Engineering Conference
December 4-7, 1996, Education and Culture Center, Seoul, KOREA
Sponsored and organized by: Korea Information Science Society,
(Co-sponsored by International Institute for Software Technology, United
Nations University)
* APSEC'96 WWW home page at "http://rtse.konkuk.ac.kr/apsec96".
THEME
The objective of APSEC'96 is to bring together developers and research-
ers from industry, academia and governments to advance the science and
technology in software engineering. The conference will address the
following principal themes, but any topics relevant to the field of
software engineering will also be considered:
Requirements Engineering, Specification, Analysis and Design, Testing,
Maintenance, CASE, Software Metrics, Software Process, Reuse, Reverse
Engineering, Object Orientation, Re-engineering, Distributed Systems,
Domain Modeling, Formal Methods, Reliability, Information System
Development, Project Management, Quality Assurance, Education, Software
Development Environments, Cyberspace Systems, etc.
INFORMATION FOR AUTHORS
APSEC'96 Program Committee solicits original technical papers. All con-
tributions will be reviewed and evaluated based on originality, techni-
cal quality, and relevance to software engineering. Technical papers
must be no longer than 6000 words. All papers must include a separate
cover sheet which provides the following information: the title,
authors' names, postal and electronic mail addresses, telephone and fax
numbers, a 200 words abstract and a list of keywords. Experience papers
or practical papers are also welcome. Submitted papers must be written
in English and identify what is new and significant about the presented
work. Accepted papers will be published by an international publisher.
A limited amount of financial aid from the United Nations University is
available to the authors from developing countries whose papers are
accepted and need financial aid to present the papers.
GENERAL INQUIRES
General inquiries about APSEC'96 may be directed to:
Doo-Hwan Bae
Dept. of Information & Communication Engineering
Korea Advanced Institute of Science & Technology (KAIST)
207-43 Cheongrangni, Dongdaemun-gu
Seoul 130-012, KOREA
Tel: +82-2-958-3313
Fax: +82-2-960-2103
E-mail: bae@poppy.kaist.ac.kr
========================================================================
CLEANROOM SOFTWARE ENGINEERING EDUCATION
Editorial Note: These course outlines are reproduced with permission.
They are included because of the clear connection to software quality
issues.
IBM's Cleanroom Software Technology Center is pleased to offer a series
of courses in Cleanroom Software Engineering.
Cleanroom Software Engineering is a managerial and technical process for
the development of ultra-high quality software with certified reliabil-
ity. Elements of Cleanroom Software Engineering include:
Incremental Development
Box Structure Specification and Design
Function-Theoretic Correctness Verification
Statistical Usage Testing
More than one million lines of Cleanroom code have been developed with
an average of 90% fewer defects than are found in traditionally
developed code. Several systems have experienced zero non-trivial
defects after release.
Instructors for the courses are Cleanroom experts from the Cleanroom
Software Technology Center.
Course Titles
Cleanroom Software Engineering Overview
Cleanroom Software Development
Cleanroom Software Engineering Overview
Cleanroom Software Certification
Course Descriptions:
Cleanroom Software Engineering Overview
This class introduces the fundamental concepts and principles of Clean-
room Software Engineering. Cleanroom Software Engineering combines
rigorous methods of software specification, design, and team-based
correctness verification to enable the development of zero-defect soft-
ware, prior to first execution. Software is developed and tested incre-
mentally. Statistical software testing is utilized to certify the qual-
ity of the software and the development process, rather than to debug
the software. In addition, the successful results of a recently com-
pleted Cleanroom project are discussed, along with the challenges
experienced in adopting Cleanroom for the first time.
Cleanroom Software Development
In this class, students learn Cleanroom development and project manage-
ment skills. Cleanroom development teams produce software approaching
zero defects through the use of the Box Structure technology, a rigorous
stepwise refinement and verification process for specification and
design. All Cleanroom-developed software is subjected to correctness
verification by development teams prior to release to certification test
teams. This practical and powerful process permits the complete verifi-
cation of the correctness of software with respect to specifications.
Cleanroom project management is based on the incremental development and
certification of a pipeline of user-function increments that accumulate
into the final product. Incremental development enables early and con-
tinual assessment of product quality and user feedback, and facilitates
improvements as development progresses.
Cleanroom Software Certification
Students learn how to plan and carry out the reliability certification
of accumulating software product increments through a process of sta-
tistical usage testing. This approach tests software the way users
intend to use it. Test cases are generated based on usage probability
distributions that model anticipated software use in all possible cir-
cumstances, including unusual and stress situations. Objective statist-
ical measures of software reliability, such as Mean Time To Failure
(MTTF), are computed for informed management decision-making. The
Cleanroom Certification Assistant tools facilitate test case design and
generation, as well as reliability certification.
Cleanroom Software Technology Center
IBM Corporation
6700 Rockledge Drive
Bethesda, MD 20817 USA
301-803-2763
http://www.clearlake.ibm.com/MFG/solutions/cstc.html
Editors Note: This course description was sent by Mr. Bruce Miller
(Phone +1 (301) 803-2690) who should be contacted for more information.
========================================================================
========================================================================
------------>>> TTN SUBMITTAL POLICY <<<------------
========================================================================
The TTN On-Line Edition is forwarded on approximately the 15th of each
month to Email subscribers worldwide. To have your event listed in an
upcoming issue please Email a complete description of your or a copy of
your Call for Papers or Call for Participation to "ttn@soft.com". TTN
On-Line's submittal policy is as follows:
o Submission deadlines indicated in "Calls for Papers" should provide
at least a 1-month lead time from the TTN On-Line issue date. For
example, submission deadlines for "Calls for Papers" in the January
issue of TTN On-Line would be for February and beyond.
o Length of submitted non-calendar items should not exceed 350 lines
(about four pages).
o Length of submitted calendar items should not exceed 68 lines (one
page).
o Publication of submitted items is determined by Software Research,
Inc., and may be edited for style and content as necessary.
TRADEMARKS: STW, Software TestWorks, CAPBAK/X, SMARTS, EXDIFF,
CAPBAK/UNIX, Xdemo, Xvirtual, Xflight, STW/Regression, STW/Coverage,
STW/Advisor and the SR logo are trademarks or registered trademarks of
Software Research, Inc. All other systems are either trademarks or
registered trademarks of their respective companies.
========================================================================
----------------->>> TTN SUBSCRIPTION INFORMATION <<<-----------------
========================================================================
To request your FREE subscription, to CANCEL your current subscription,
or to submit or propose any type of article send E-mail to
"ttn@soft.com".
TO SUBSCRIBE: Use the keyword "subscribe" in front of your Email address
in the body of your Email message.
TO UNSUBSCRIBE: please use the keyword "unsubscribe" in front of your
Email address in the body of your message.
TESTING TECHNIQUES NEWSLETTER
Software Research, Inc.
901 Minnesota Street
San Francisco, CA 94107 USA
Phone: +1 (415) 550-3020
Toll Free: +1 (800) 942-SOFT (USA Only)
FAX: + (415) 550-3030
Email: ttn@soft.com
WWW URL: http://www.soft.com
## End ##