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 =======+
+======= August 1996 =======+
+===================================================+
TESTING TECHNIQUES NEWSLETTER (TTN), On-Line Edition, is Emailed 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
provided that the entire document/file is kept intact and this copyright
notice appears with it.
========================================================================
INSIDE THIS ISSUE:
o ESA Press Release: ARIANE 501 Enquiry Board Report
o 1996 International Conference on Software Maintenance (ICSM'96)
o Annals of Software Engineering -- New Journal
o ICSE'97 -- International Conference on Software Engineering
o Certify, License or Register Software Professionals? by Larry
Bernstein, President, National Software Council
o Request from Members of the Software Reliability Community
o Call for Papers-- 1997 ACM SIGMETRICS Conference
o Useful Features of a Test Automation System (Part 1 of 3), by
James Bach
o Testing Computer Telephony Systems and Networks (Book
Announcement)
o Workshop Announcement -- WITAT '96
o COMPASS'97 -- Call for Papers
o Reaching SR for information about TestWorks
o TTN SUBSCRIPTION INFORMATION
========================================================================
ESA/CNES JOINT PRESS RELEASE -- ARIANE 501
ESA Press Release [33-96]: Paris, 23 July 1996
ARIANE 501 -- Presentation of Inquiry Board report
Editors Note: This press release was taken off the ESA WWW site
on 24 July 1996. The implications of what was said and perhaps
even how it was said should be of significant interest to everyone
in the software testing and software quality community.
To set the stage, consider these comments from The Economist (June
1st, 1996, p. 77): "...Even though Ariane is built around familiar
technologies, she will fly only if a lot of new designs work well
together: new engines, a main stage that burns liquid rather than
solid fuel, booster rockets ten time bigger than anything yet
built in Europe, to say nothing of new electronics and software."
That same article goes on to predict: "...After years of tests --
and a delay of 19 months -- Ariane 5's engineers are convinced
there will be no disaster." -efm
On 4 June 1996 the maiden flight of the Ariane 5 launcher ended in a
failure. Only about 40 seconds after initiation of the flight sequence,
at an altitude of about 3700 m, the launcher veered off its flight path,
broke up and exploded.
Mr. Jean-Marie Luton, ESA Director General, and Mr. Alain Bensoussan,
CNES Chairman, immediately set up an independent Inquiry Board (see
ESA-CNES Press Release of 10 June 1996), which has now submitted its
report.
The report begins by presenting the causes of the failure, analysis of
the flight data having indicated:
o Nominal behavior of the launcher up to H0 + 36 seconds;
o Simultaneous failure of the two inertial reference systems;
o Swivelling into the extreme position of the nozzles of the two solid
boosters and, slightly later, of the Vulcain engine, causing the
launcher to veer abruptly;
o Self-destruction of the launcher correctly triggered by rupture of the
electrical links between the solid boosters and the core stage.
A chain of events, their inter-relations and causes have been
established, starting with the destruction of the launcher and tracing
back in time towards the primary cause. These provide the technical
explanations for the failure of the 501 flight, which lay in the flight
control and guidance system. A detailed account is given in the report,
which concludes:
"The failure of Ariane 501 was caused by the complete loss
of guidance and attitude information 37 seconds after start
of the main engine ignition sequence (30 seconds after
lift-off). This loss of information was due to specification
and design errors in the software of the inertial reference
system.
The extensive reviews and tests carried out during the
Ariane 5 development program did not include adequate
analysis and testing of the inertial reference system or of
the complete flight control system, which could have
detected the potential failure"
Despite the series of tests and reviews carried out under the program,
in the course of which thousands of corrections were made, shortcomings
in the system approach concerning the software resulted in failure to
detect the fault. It is stressed that [the] alignment function of the
inertial reference system, which served a purpose only before lift-off
(but remained operative afterwards), was not taken into account in the
simulations and that the equipment and system tests were not
sufficiently representative.
Without implicating the system architecture, the report makes a series
of recommendations for ensuring that the launcher's software operates
correctly. The Ariane 5 program will be taking action in line with all
these recommendations, as follows:
o correction of the problem in the SRI (inertial reference system) that
led to the accident;
o reexamination of all software embedded in equipment;
o improvement of the representativeness (vis-a-vis the launcher) of the
qualification testing environment;
o introduction of overlaps and deliberate redundancy between successive
tests:
> at equipment level,
> at stage level,
> at system level;
o improvement and systematization of the two-way flow of information:
> up from equipment to system: nominal and failure-mode behavior;
> down from system to equipment: use of equipment items in flight.
More specifically, the following corrective measures will be applied:
o to the inertial reference system:
> switch-off or inhibition of the alignment function after liftoff,
> analysis/modification of processing, particularly on detection of a
fault (no processor shutdown),
> testing to check the coverage of the SRI flight domain;
o to the system qualification environment:
> general improvement of representativeness through systematic use of
real equipment and components wherever possible,
> simulation of real trajectories on SRI electronics.
o In addition, the following general measures will be taken:
> critical reappraisal of all software (flight program and embedded
software),
> review of mechanisms for managing double failures,
> improvement of facilities for acquisition and retrieval of telemetry
data,
> improvement of overall coordination relating to software.
The ESA Director General and CNES Chairman will be making a joint
presentation of the plan of action put into effect and its programmatic
consequences at a press conference in September 1996.
========================================================================
Annals of Software Engineering -- New Journal
Annals of Software Engineering is a NEW interdisciplinary journal
covering all aspects of software engineering. Each volume focuses on a
particular topic of SE and contains state-of-the-art survey and tutorial
papers as well as industrial and academic research and application
papers.
Please find below a selection of papers accepted for publication in
Volume 2, 1996:
G. Booch, Managing object-oriented software development
B.G. Cain, J.O. Coplien and N.B. Harrison, Social patterns in productive
software development organizations
T. Case, B. Henderson-Sellers and G.C. Low, A generic object-oriented
design methodology incorporating database considerations
M. Dodani, Formal methods for object-oriented software engineering
L. Jian, Developing parallel object-oriented programs in the framework
of VDM
J. Lin, D.C. Kung and P. Hsia, Object-oriented specification and formal
verification of real-time systems
J.D. McGregor, B.A. Malloy and R.L. Siegmund, A comprehensive program
representation of object-oriented software
L.R. Welch, M. Lankala, W. Farr and D.K. Hammer, Metrics for quality and
concurrency in object-based systems
For a complete overview on what has been published, please consult
http://www.baltzer.nl/
========================================================================
1996 International Conference on Software Maintenance
Monterey, CA November 4-8, 1996
ICSM'96 provides an effective forum for discussing software maintenance
and modernization through refereed papers, experience reports, panel
sessions, exhibits, and informal meetings. ICSM'96 presents the most
important practical, experimental, and theoretical work currently
conducted to support software maintenance. Participants include
practitioners and researchers from industry, academia, and government.
The Workshop on Software Maintenance held in Monterey, California in
1983 marked the first in a series of software maintenance conferences
that have evolved into the International Conference on Software
Maintenance (ICSM). ICSM is recognized as the world's premier forum for
state-of-the-art developments in the field of software maintenance. In
returning to Monterey in 1996, it is only appropriate to examine
developments in software maintenance over the past thirteen years and to
assess the extent to which these developments have added value to
software products and processes.
ICSM'96 THEME: SOFTWARE MODERNIZATION
Software modernization is a key area where software maintenance
technology is making an impact today. Whether it involves moving from an
old platform to a new, migrating stovepipe systems into an integrated
architecture, or renovating an aging software system to be more
responsive to change, software modernization involves modifying existing
systems to suite their ever-changing environments. Software
modernization is increasingly becoming a key activity as software
organizations attempt to contain maintenance costs and maximize
investments in their software assets.
This conference examines how software maintenance as a discipline has
evolved to handle more effectively software modernization since 1983.
Software maintenance in 1983 focused on programming-in-the-small
(changes to modules) while in the 1990's it has turned toward
programming-in-the-large (changes to architecture). The conference will
include: tutorials, paper and panel sessions, an industry track, tools
fair, and a workshop on empirical studies in software maintenance.
Contact:
Norman Schneidewind, General Chair
Information Systems Group
Code SM/Ss
Naval Postgraduate School
Monterey, CA 93943, USA
Email: schneidewind@nps.navy.mil
========================================================================
ICSE 97 -- International Conference on Software Engineering
Theme: Pulling Together
THE COMPLETE CALL FOR PARTICIPATION IS AVAILABLE ELECTRONICALLY VIA:
World Wide Web: http://www.ics.uci.edu/icse97/
May 18-23, 1997, Boston, Massachusetts, USA
Sponsors:
ACM Special Interest Group on Software Engineering (SIGSOFT)
IEEE Computer Society - Technical Council on Software Engineering (TCSE)
Council of European Professional Informatics Societies
The creation, deployment, evolution, and meaning of software and its
role in modern society is changing and expanding as a result of new
technologies, new applications, and new social factors. The Internet,
the World-Wide-Web, multimedia interfaces, and neighborhood software
stores have added new dimensions to traditional issues and topics in
software engineering. The International Conference on Software
Engineering is changing with the discipline to encompass the new
emphases and the broadened sweep of topics and concerns which confront
today's software professionals and researchers.
The theme of the 1997 International Conference on Software Engineering
is "Pulling Together." Pulling together denotes coordinated action of
many individuals in achieving a common goal. It also describes the
coming together of many different perspectives, concerns, and abilities
to find a common ground and a way of achieving cooperation. Pulling
together is fundamentally dynamic in nature, and is often a matter of
explicit negotiation and communication. Major changes have been
instituted in ICSE 97 to help the software engineering community pull
together, in the full sense of that phrase.
ICSE 97 includes a widened range of conference activities, a widened
range of participants, and new technical areas. A broadened outlook
challenges old beliefs, promotes new ideas and new synergies, and
provides for a dynamic, exciting program. New or expanded conference
activities include a doctoral symposium, lessons and reports from
software engineering organizations, a mentor program, posters, and a
commercial exhibit.
A major addition to the conference is a suite of sessions and activities
focusing on the interests and needs of the practicing professional.
Numerous invited presentations, timely panel topics, experience reports,
and an expanded tutorial program are included.
As the discipline expands, papers and presentations on topics such as
software engineering and the WWW, end-user involvement in software
development and customization, usability testing, design for an
international marketplace, and intelligent applications are encouraged.
We hope that you will pull together with us, bringing new ideas, new
concerns, and new goals, thus helping us to find common ground and reach
new objectives.
Contacts:
Alfonso Fuggetta
Dipartimento di Elettronica e Informazione
Politecnico di Milano
P.za Leonardo da Vinci, 32
20133 Milano, Italy
fuggetta@elet.polimi.it
+39-2-2399-3540
+39-2-2399-3411 (fax)
http://www.elet.polimi.it/~fuggetta
Richard N. Taylor
Information and Computer Science
University of California, Irvine
Irvine, California, 92697-3425 U.S.A.
taylor@ics.uci.edu
+1-714-824-6429
+1-714-824-4056 (fax)
http://www.ics.uci.edu/~taylor
Anthony I. Wasserman
IDE
595 Market Street, 12th floor
San Francisco, California 94105 U.S.A.
tonyw@ide.com
+1-415-543-0900
+1-415-543-0145 (fax)
========================================================================
Certify, License or Register Software Professionals?
by Larry Bernstein, President NSC
TO: Friends of the National Software Council
RE: NSC Forum on Licensing of Software Professionals
Here are notes from the National Software Council Forum on the Licensing
of Software Professionals and my proposal for action.
The NSC sponsored a Forum to debate the need to provide a certification
and licensing program for software professionals, specifically, software
engineers. This issue is very hot within university and government
circles. The meeting, held in St. Louis on 21 and 22 June 1996,
involved leading persons from academia, industry, and government who
lead the debate on certification.
The ACM was represented by Steward Zweben, President of the ACM and the
IEEE by Elliot Chikofsky, Chair of the Technical Activity Group on
Software Engineering of the IEEE Computer Society.
Mary Shaw of Carnegie Mellon University spoke on "Should US Software
Engineers be licensed?" She argued against licensing. She said that
software engineering is immature compared with civil or chemical
engineering. For software engineering to mature requires a
consolidation and validation of its body of knowledge. She asked if
software engineering was closer to mathematics than engineering? She
suggested that the software engineering knowledge base is not stable
enough to support licensing and certification. Before we embark on any
certification or licensing program she demands that we develop and adopt
a robust software engineering body of knowledge.. Industry, government,
professional societies and universities must accept a single software
engineering taxonomy, which only then would be the basis for a
certification or licensing program. Shaw does not believe that today's
body of knowledge is sufficient. Shaw also discussed the need for
standards. She called for a codification of our body of software
engineering knowledge.
Norm Gibbs of Guilford College, North Carolina, (and recently headed the
software education program of the SEI) spoke about the software
engineering curricula in the United States. He proposed that the medical
profession's certification and licensing program become the model
software engineering. Gibb's insisted that we must leverage on the
investment that industry is making in training programs. He implored us
to agree on a practice. Gibbs contrasted current engineering
certification and licensing programs. He concluded that the while
certification assures a level of education, licensing is aimed at
accountability
Most of the debate was in favor of certification and licensing with the
lack a sufficient body of knowledge being the stumbling block. Don
Gotterbarn of the Tennessee State University argued that such a body of
knowledge existed and disagreed with Shaw. Gotterbarn went on to give
his views on the lack of accepted ethics of software engineering
practice. He warned that if the software engineering community does not
step certify and license its professionals, the professional engineering
community will. Today's state licensing examinations have little
relevance to software engineering.
Nancy Mead of the Software Engineering Institute discussed their
initiatives to improve software engineering education.
Stewart Zweben called for a more compelling reason for certification and
licensing than just the good of the profession. Professional societies
must make the case for how certification and licensing will benefit
society.
Pat Douglas, of IBM, has been working on a survey of software
engineering. This effort under the guidance of the joint IEEE/ACM
steering committee needs support and leadership.
Michael Berens, representing the ASQC, argued for certification and
urged the NSC to make it happen.
Perhaps the most revealing dialogue took place in the summary session.
These are the findings from the Forum: 1. There is a lack of high level
industry participation or interest. 2. The leaders of the profession
are silent. 3. Why should the NSC become involved? Can it be a forcing
function to set a national agenda and help the various factions
coalesce? 4. Gibbs endorsed the concept of certification (versus
licensing). More work is needed on the mechanics of such a program. 5.
There is a consensus for certification within specialties 6. The goal is
to have a program in place by October 1997.. 7. The NSC should be
active in the IEEE/ACM steering committee activity, perhaps even
chairing the committee. 8.. The NSC should participate in IEEE/ACM/STC
conferences on this subject.
There is a consensus for a certification program in software
engineering, and that the NSC should provide leadership in bringing such
a program to realization.
Larry Bernstein's Proposal for Registration: The National Software
Council registers systems as "Safety Critical" ones. These are systems
that can effect human health and welfare, privacy, financial controls,
national security or trade secrets. Any customer or supplier can
register their request for a system, their working system or their
developing system as "Safety Critical" with the NSC if and only if:
1. They are a member of the NSC.
2. There is a named NSC registered software architect responsible for
all technical decisions.
3. There is a named NSC registered software project manager
responsible for the trade-offs between features/functions, schedule,
costs, through-put, response time and availability. This person may
be the same as the software architect.
4. They advocate and practice code of software engineering ethics for
safe systems:
a. Systems will not de-humanize
b. Systems will be tested.
c. Software Engineers will be current with technology and
practices.
d. Risks and confidence levels for successful operation will be
identified.
e. Efforts used to make the system safe will be explicitly
identified.
Safe systems are those that have been verified to perform their
functions properly and can sense when they are about to fail and recover
or shut down in an orderly way.
To be a registered safety-critical software architect or project manager
one must:
a. Be endorsed in writing by two others registered safety-critical
software architects or project managers.
b. Be a member in good standing of the NSC.
c. Be an advocate and practitioner of a code of ethics
d. Be current in the field
e. Provide a written rationale for decisions
f. Follow a defined process
When these conditions are met the system, architect or project manager
may use a 'NSC Safety Assured' seal.
Thanks to Walt Ellis and John Marciniak for preparing these notes and to
Rick Linger for chairing the NSC Forum in St. Louis.
Please send your comments nsc@nscusa.org or to me at
"lbernstein@worldnet.att.net".
Larry Bernstein. President NSC
========================================================================
Request from Members of the Software Reliability Community
Anneliese von Mayrhauser
avm@cs.colostate.edu
I want to bring to your attention the Call for Papers of the 1997 IEEE
Aerospace Conference. I am organizing a session on Software Quality,
Reliability and Testing. Details on the conference can be found on the
web:
http://chirp.plk.af.mil:1050/ieee/index.html
Please, mention in your submission that I solicited your contribution.
The conference is held February 1-8, 1997 in Snowmass, CO (great
skiing!!!). It is considered one of the premier events in aerospace
conferences.
========================================================================
Call for Papers-- 1997 ACM SIGMETRICS Conference
International Conference on Measurement and Modeling of Computer Systems
Seattle, WA June 15-18, 1997
Sponsored by ACM SIGMETRICS
An international forum for state-of-the-art work on performance issues
in computer systems: theory, practice and case studies. Topics include
but are not restricted to:
* Performance-oriented design and evaluation studies of: Communication
networks, Computer architecture, Database systems, Distributed
systems, File and I/O systems, Fault-tolerant systems, Memory
systems, High speed networks, ATM, Interconnection networks,
Multimedia systems, Operating systems, Real-time systems, Network
management systems, Service management systems.
* Techniques and algorithms for: Performance optimization, Stochastic
modeling, Model verification and validation, Experimental design,
Petri Nets, Reliability analysis and measurement, Workload
characterization, System measurement and monitoring, Simulation and
statistical analysis.
Information on Sigmetrics '97 will be maintained at:
http://www.research.att.com/conf
Contact:
John Zahorjan, General Chair University of Washington
zahorjan@cs.washington.edu, Phone: +1 206 685 2695
========================================================================
Useful Features of a Test Automation System (Part 1 of 3)
by
James Bach
Editors Note: This article, by noted testing guru Jim Bach, is his
personal set of hints and recommendations about how to get the
best out of your effort at building a regression test system. You
can reach Jim at STL, South King St. Suite 414, Seattle, WA 98104.
I've run test teams at Apple and Borland. We tried to automate our
tests. We had some success with it, but mostly we failed. Test
automation for modern GUI software is very challenging. Along the way,
though, I've collected this list of useful features and caveats that you
might want to consider in doing your automation.
o Suite is structured to support team development.
Break large monolithic source files down into smaller, cohesive
units. Put the system under source control to prevent team members
from overwriting each other's work. Naturally, this applies only if
the suite is being developed jointly, but beware of those small
projects that become big projects, it might be worthwhile to plan
ahead.
o Suite can be distributed across a network of test execution systems.
As your test suite grows in size, and as your organization gains more
test suites and products to test, you will find it increasingly
difficult to make efficient use of your test machines. One way of
maximizing efficiency is to centralize a group of test machines (at
Borland there is a lab with 50 or more identical, centrally
controlled systems), and create test suites that can be distributed
to a number of machines at once. This can substantially reduce the
time needed for a test cycle, and eliminate the possibility that a
problem with one machine will stop the whole suite from running.
Another idea is to make the suite distributable to machines that are
not otherwise dedicated to testing, such as computers normally used
in development or administration. There are obvious risks to this
strategy (such as the possibility of an automated test destroying a
programmer's hard disk), but if your company has very few computers
and a big need to test, it's useful to have the option of borrowing a
few systems and getting each of them to run part of the test cycle.
o Suite can execute tests individually, or by group.
You might design the suite such that it can run an individual test, a
set of specific tests, a group of related tests, all tests, all tests
except specific tests or groups of tests, or only tests that failed
the last time through. Also, allow the order of tests to be modified.
You get the idea-- the suite should provide flexibility in test
execution.
o Suite interoperates with bug tracking system (bugs and tests are
linkable).
Depending on the kind of testing that you do, enabling the test suite
to record a failure directly into your bug tracking system (whether
that system is a flat file database or something more elaborate) may
save time and effort. It may also waste time, if a high percentage of
failures are due to automation problems and not defects in the
product. Another possible linkage might be the ability of the test
automation to look in the bug tracking system for all fixed bugs and
verify that they are still fixed. This requires that each bug report
is accompanied by an automated test. Similar to that is the idea of
marking a test as a "known failure until bug #3453 is fixed"; and
design the suite to execute that test, but ignore the failure until
the associated bug is marked as fixed in the database. The most
feasible linkage I can think of is the ability to navigate directly
from a bug in the tracking system to the part of the test suite that
relates to it, and vice versa.
o Suite can perform hard reset of test machines in case of system
crashes.
It's common for test machines to crash during testing, so you want
some way to restart the hardware if that happens. In one project, we
used a software controllable power strip attached to each test
machine, and used another computer to monitor the status of each test
machine. If a crash was detected the monitoring computer would cycle
the power on that system. With modern O/S's, it's sometimes possible
to monitor the status of one process from within another process on
the same computer. That may be easier and cheaper to arrange than the
hardware reset.
o Suite can execute unattended.
While a test suite that must be continually monitored can still be a
lot better than manual testing, it's often more valuable to design it
to run to completion without any help.
o Suite execution can be restarted from the point of interruption in
case of catastrophic failure (eg. power loss).
The more tests that you automate, the less you want your tests to
start all over from the beginning if the suite is halted in the
middle of execution. This isn't as easy as it may sound, if your test
drivers are dependent on variables and structures stored in memory.
By designing the system to write checkpoints out to disk, and to have
an automatic start process that activates on reboot, and to have a
means of resynchronizing to any other systems that it is connected to
(such as file servers, which typically take longer to reset after the
power goes out) your suite will survive a power outage and still be
kicking.
(TO BE CONTINUED)
========================================================================
Testing Computer Telephony Systems and Networks
by Steve Gladstone
Editors Note: The blurb below is from a catalog of books on computer
telephony sent as part of the 1996 Computer Telephony Conference.
Contact: 12 West 21 Street, New York, NY 10019. Phone: +1 (212) 691-
8215.
The book is structured to systematically help you:
1. Understand Computer Telephony testing. Chapters devoted to
understanding CT testing identify key components, issues, and likely CT
problems to familiarize you with quality impacting CT issues.
2. Address service objectives. Key to any system or network is
understanding how you want the system to work. These chapters help you
understand issues key to developing your service objectives.
3. Develop the test plan. The test plan is the document that will guide
the actual testing process. These chapters help you develop the
processes, tools, testing methods, and the actual tests which will
encompass your test plan.
4. Select test tools. These chapters help you understand what tools are
needed and provides guidelines for test automation tools.
5. Test and analyze. These chapters provide concrete examples on how to
perform high-leverage CT tests.
========================================================================
Workshop Announcement -- WITAT '96
3rd Annual Workshop on
Information Technology -- Assurance and Trustworthiness
September 3-5, 1996
Columbia Hilton, Columbia, MD
Co-sponsored by
Aerospace Computer Security Associates
National Institute of Standards and Technology
University of Maryland Institute for Advanced Computer Studies
-- Are you sure your information is adequately protected?
-- How do you know that your privacy is being guarded?
-- Can your customers trust you?
The Workshop on Information Technology Assurance and Trustworthiness
(WITAT) investigates and promotes promising methods of gaining assurance
in information technology.
WITAT '96 is the third in a series of annual workshops addressing the
assurance and trustworthiness. The first workshop identified and
analyzed crucial issues on assurance in IT systems and provided input to
the development of policy guidance for determining the type and level of
assurance appropriate in a given environment. The participants came to
the consensus that no one technique can provide comprehensively adequate
assurance. The second workshop built upon the first by making
recommendations based on the issues and problems identified.
Building upon the results of the previous two workshops, WITAT '96
recognizes the existence and emergence of numerous methods to obtain
assurance. However, the relative value, promise, and applicability of
each is unclear for specific systems. These will be discussed through
the presentation of alternative assurance approaches to assurance
stakeholders and producers, receiving immediate feedback from a diverse
audience, reviewing reaction to presented approaches and creating a
strategy for moving ahead.
Information on WITAT '96, costs, and registration information can be
found at WWW address: http://aaron.cs.umd.edu/witat/witat96.html.
Send mail to witat-info@cs.umd.edu for a copy of the complete call for
participation, including fees, and registration form.
WORKSHOP COMMITTEE
Marshall Abrams The MITRE Corp. Diana Akers The MITRE Corp.
Maryam Alavi Univ. of Maryland Lynn Ambuel Natl. Security Agency
Karen Ferraiolo Arca Systems, Inc. Jay Kahn The MITRE Corp.
*Douglas Landoll Arca Systems, Inc. Carolyn Wichers BDM
Jeff Williams Arca Systems, Inc. Marvin Zelkowitz Univ. of Maryland
* - Workshop Chair
REGISTRATION
Costs: Tutorial (Sept. 3) $110.00 (includes lunch)
Workshop (Sept. 4-5) $120.00 (includes lunches)
Location: Columbia Hilton, 5485 Twin Knolls Road, Columbia, MD. 410-997-1060.
========================================================================
COMPASS'97 -- Call for Papers
12th Annual Conference on Computer Assurance
June 16-20, 1997
Gaithersburg, MD
Sponsored by
IEEE Aerospace & Electronic Society
IEEE National Capital Area Organization
The purpose of COMPASS is to bring together researchers, developers,
integrators, and evaluators interested in problems related to
specifying, building, and certifying high-assurance systems. What
distinguishes COMPASS from similar conferences is its emphasis on
bridging the gap between theory and practice. The theme of COMPASS
focus discussion on whether the approaches that have been developed and
reported on during the past 25 years have any hope for solving today's
assurance problems. In addition to exposing technical weaknesses in the
state-of-the-art and state-of-the-practice, conference goals include:
identifying barriers to applying existing assurance technologies in
industry, understanding the properties new technologies must have to
meet industrial needs, and identifying evidence where advanced
technologies are effective in attacking the key problem areas of safety,
security, fault-tolerance, and real-time.
For researchers, COMPASS '97 provides an opportunity to present new
theories, techniques, methods, or results of case studies to other
researchers and to practitioners who can put them to use. COMPASS '97
also provides a unique opportunity to learn from practitioners about
issues and problems encountered in constructing practical systems.
Practitioners have the opportunity to present results and lessons
learned to researchers as well as to learn of new research targeted to
problems in high-assurance systems. For practitioners, COMPASS provides
the unique opportunity to influence future research directions.
The conference will be held June 16-20, 1997, at the National Institute
of Standards and Technology (NIST) in Gaithersburg, Maryland, a suburb
of Washington, D.C. The proceedings will be published by the IEEE
Computer Society.
Contact:
Dolores R. Wallace
National Institute of Standards & Technology
Bldg 820NN, RM517
Gaithersburg, MD 20899
dwallace@nist.gov
+1 (301) 926-3696 fax
+1 (301) 975-3340 voice
http://hissa.ncsl.nist.gov/
========================================================================
Reaching SR for Information about TestWorks
As readers may know, SR's TestWorks product line is a multi-function,
multi-platform suite of test tools designed for professional level
software quality enhancement. We will be pleased to send information
about TestWorks to you. Here's how you can reach SR in various modes
for various purposes.
Mail: 901 Minnesota Street
San Francisco, CA 94107 USA
Phone: +1 (415) 550-3020
FAX: +1 (415) 550-3030
WWW/URL: http://www.soft.com
Email: info@soft.com (for general information questions)
support@soft.com (technical issues with TestWorks products)
licenses@soft.com (license questions)
sales@soft.com (sales information)
seminars@soft.com (information about TestWorks seminars)
training@soft.com (information about TestWorks training events)
users@soft.com (details about upgrades, user services)
qw@soft.com (information about Quality Week '97)
========================================================================
TTN Printed Edition Eliminated
Because of the much-more-efficient TTN-Online version and because of the
widespread access to SR's WWW, we have discontinuing distributing the
Printed Edition (Hardcopy Edition) of Testing Techniques Newsletter.
The same information that had been contained in the Printed Edition will
be available monthly in TTN-Online, issues of which will be made
available ~2 weeks after electronic publication at the WWW site:
URL: http://www.soft.com/News/
Issues of TTN-Online from January 1995 are archived there.
========================================================================
------------>>> 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 Email to
"ttn@soft.com".
TO SUBSCRIBE: Send Email to "ttn@soft.com" and include in the body of
your letter the phrase "subscribe ".
TO UNSUBSCRIBE: Send Email to "ttn@soft.com" and include in the body of
your letter the phrase "unsubscribe ".
TESTING TECHNIQUES NEWSLETTER
Software Research, Inc.
901 Minnesota Street
San Francisco, CA 94107 USA 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 ##