, University of Illinois, Chicago
, Hollandse Signaalapparaten BV
, Matsubara Consulting
Pages: pp. 22-25
Abstract—This focus section honors Alan Davis, editor-in-chief from Jan. 1994-June 1998.
This issue is dedicated to Alan Davis, our dear colleague, thinker, doer, leader, sometimes dreamer, and a congenial friend always.
Al surpassed the legacy that began in 1991 when the enthusiastic founding members of an Industry Advisory Board met with IEEE Software's Editorial Board to hammer out a shared vision: to transform Software into a top-rated practice-oriented publication for software professionals worldwide. It has been a long march, exhausting two editors-in-chief. IEEE Software now enjoys a widespread reputation as a magazine for the readers, by the readers, and of the readers.
During Carl Chang's term as editor-in-chief (1991-1994), the Editorial Board began an extensive dialogue with the software industry via the Industry Advisory Board. The IAB has been instrumental in strategic planning, enrichment, and development of Software's editorial calendar. Through their extensive networking, IAB members have contributed not only real-world expertise but also numerous contacts that the Editorial Board alone would not be able to reach. Many IAB members actually took the lead to edit or co-edit special issues that focused on critical and timely themes identified at the annual joint EB-IAB meeting. Such a coherent model of editorial development proved to be extremely powerful and highly regarded by the publications community within the Computer Society.
As the magazine's fourth editor-in-chief, Al deserves credit for many fine contributions. Here are just a few.
This focus section includes seven "standard" articles—standard in the sense that they conform well to the rules and guidelines defined by our genre specifications. (A Practice Tutorial article is lacking as a result of our rigorous review process.) We invited reputable authors from three continents—America, Asia, and Europe—to contribute to setting these standards.
In "The Java Virtual Machine—A Passing Fad?" Michael Franz explains why he believes that the Java Virtual Machine is probably on its way out. Microsoft may strive eagerly to make this happen, since the only hurdle is legal, according to the author. These predictions are based on Franz's experience in developing Juice, an alternative scheme to support software mobility and transportability. It is definitely a thought-provoking piece, and so serves well as our standard essay.
In "Tailoring Cleanroom for Industrial Use," Robert S. Oshana reports Raytheon's experience in a pilot process improvement program to move from CMM level 3 to level 5 by focusing on Cleanroom software engineering technology. The article shares the group's encouraging lessons learned from tailoring Cleanroom to their specific needs. Oshana provides evidence to support their claims of success, but cautions readers who want to employ the same approach to their own organizations because concerns, issues, and barriers do exist.
Kathryn A. Bassin, Theresa Kratschmer, and P. Santhanam present "Evaluating Software Development Objectively" as our standard Applied Research Results article. By employing the Orthogonal Defect Classification scheme, the authors are able to support management with a firm handle on technical decision making. Through the extensive capture and analysis of defect semantics, information on project management, test effectiveness, reliability, quality, and customer usage can be obtained. The article describes three real-life case studies, and demonstrates the applicability of their techniques.
Daniel Hoffman and David Weiss's article "Commonality and Variability in Software Engineering" serves as our standard Experience Report. The article describes how to perform domain engineering by identifying the commonalities and variabilities within a family of products. Through interesting examples dealing with reuse libraries, design patterns, and programming language design, the authors suggest a systematic Scope, Commonalities, and Variabilities approach to formal analysis. Their SCV analysis has been an integral part of the FAST (Family-oriented Abstraction, Specification, and Translation) technology applied to over 25 domains at Lucent Technologies.
Tsuneo Yamaura presents our How To article, "How To Design Practical Test Cases." Published articles seldom discuss real-world software testing in detail. Yamaura works at Hitachi Software Engineering, which is respected as a developer of high-quality software products—a feat rarely achieved at most software organizations. He reveals strategic and tactical secrets that his company has institutionalized, offers some data for actual testing activities, and describes how to achieve similar high-quality standards. He also points out the importance of designing and documenting test cases.
Mikio Aoyama's "Web-Based Agile Software Development" is our chosen standard Tool Report. Although many of us realize the importance of tools in software development and have access to a variety of conventional ones, we have not tried to use integrated tools very much because of their seeming rigidity and complexity. Along with widespread use of the Internet and intranets, new ideas for building flexible integrated tools have been proposed. The author's Web-based Agile Software Engineering Environment is grounded in a time-based rather than volume-based life cycle, and introduces the just-in-time concept.
"Exploring the Software Development Trilogy" by Daniel Le Métayer, Valérie-Anne Nicolas, and Olivier Ridoux serves as our standard Research Tutorial. Software development is concerned with more than just generation of code; the program has to have the desired properties, and these have to be demonstrated via suitable tests and correctness arguments. One interesting way of viewing these aspects is to group them into programs, properties, and data. When represented as vertices in a triangle, the edges represent processes to produce one element from another.
Most formal methods take into account these three aspects only partially; they also fail to restrict the expressiveness of predicate logic or programming languages. This results in problems that cannot be solved algorithmically. The research reported in this article aims at practical methods for automatic test generation by restricting the use of both predicate logic and programming constructs. The tradeoff between fully automated test generation and reduced expressive power is innovative and very interesting. It promises to eventually result in practical domain-specific programming languages, with a significant boost in both quality and productivity.
In the future, these published articles will serve as our genre examples for authors. The issue also includes a roundtable discussion: five contributors from around the world take up the issue of who should define standards and whether standards should even be defined at all.
We hereby present seven "standard" articles for your reference in the future. We feel this is a proper way to acknowledge Al's efforts in defining the magazine's article standards, and his constant effort to set high standards of quality in everything we published under his helm. This entire issue is meant to honor Al's faithful service to our profession.
What we learned from Al's unique leadership style is that one can lead successfully with sincerity. He says what he thinks and he does what he says. He himself has set quite a standard of work ethics; we can only imagine how much energy he devoted to the job of editor-in-chief. We wish him well in his new endeavor as a practitioner (again!).
EXPERIENCE REPORT: Describe how particular techniques, practices, or tools were used in a practical setting. Explain the environment (type of application domain, hardware and software platform, types of people building and using the system, etc.) so readers can tell whether your findings are relevant to their situation.
CASE STUDY: Describe how particular techniques, practices, or tools were used in a practical setting. Explain the environment (type of application domain, hardware and software platform, types of people building and using the system, etc.) so readers can tell whether your findings are relevant to their situation.
TOOL REPORT: Report the development of a new software tool and its application.
HOW-TO ARTICLE: Provide readers with step-by-step instructions on how to perform a specific software development task.
ESSAY: Encourage readers to think "out of the box." Give readers new perspectives. Expand readers' perspectives. Raise controversies.
PRACTICE TUTORIAL: Given a specific technology (or real-world problem), explain how the technology is applied (or how the real-world problem is solved) today in industry.
RESEARCH TUTORIAL: Given a specific technology (or real-world problem), explain the most promising research activities underway or proposed that expand our knowledge of the technology (or of how to solve the problem).
APPLIED RESEARCH RESULTS: Report to readers on the availability of some new research technology, technique, tool, or language. The general feasibility of this research should already have been demonstrated. What is required now is more widespread use of experimentation in order to confirm the effectiveness of the results.
The full author guidelines for each type of article are available at http://computer.org/software/genres.htm.
On page 27 of "Leveraging Your CMM Efforts for IEEE/EIA 12207," IEEE Software Sept./Oct. 1998, Figure A appeared with incorrect coloring. The correct figure is below, and is available on the Web at http://www.software.org/quagmire.AThe frameworks quagmire. Red indicates CMM; green indicates US government or military documents; purple indicates international standards; blue indicates commercial, professional, or industrial associations, mostly US ones; and black indicates all others. The arrows indicate "derived from," via information or people. Ovals distinguish the more popular and important frameworks.