The Road Map to Software Engineering: A Standards-Based Guide: 2 (Software Engineering Standards Series) - Softcover

Moore, James W.

Softcover

ISBN 10: 0471683620 ISBN 13: 9780471683629

Publisher: Wiley-IEEE Computer Society Pr, 2005

Synopsis

The Road Map to Software Engineering: A Standards-Based Guide organizes relevant IEEE software and systems standards using two frameworks: the SWEBOK Guide's topical knowledge areas and the widely used IEEE/EIA 12207 standard. This useful guide is endorsed and recommended by the Software and Systems Engineering Standards Committee of the IEEE Computer Society for both practitioners and students.

About this title

About the Author

JAMES W. MOORE is a thirty-five-year veteran of software engineering and a fifteen-year veteran of software engineering standardization. With degrees from the University of North Carolina and Syracuse, he has worked in both the commercial and defense sectors for IBM and, now, The MITRE Corporation. Currently he serves as the Vice President for Electronic Products and Services of the IEEE Computer Society and as the liaison between ISO/IEC JTC 1/SC 7 and the IEEE Software and Systems Engineering Standards Committee, the world's two largest providers of software and systems engineering standards. He is an Executive Editor of the IEEE Computer Society's Guide to the Software Engineering Body of Knowledge and a member of the Editorial Board of the recent revision of the Encyclopedia of Software Engineering.

From the Back Cover

The Road Map to Software Engineering: A Standards-Based Guide by James Moore is recommended by the Software and Systems Engineering Standards Committee of the IEEE Computer Society as a useful guide for software practitioners applying software engineering standards.

Using software engineering standards in producing effective software

This book provides a single overview of "codified software engineering," the set of knowledge and best practices that apply to most projects most of the time. By laying out the accepted techniques, the text allows managers―as well as those paying the bill―to eliminate wasteful experimentation with unproved software practices while giving more attention to true innovations.

Prepared in accordance with the Guide to the Software Engineering Body of Knowledge (SWEBOK), The Road Map to Software Engineering organizes relevant IEEE software and systems standards, along with standards from other sources, using two frameworks: the SWEBOK Guide's topical knowledge areas and the widely used IEEE/EIA 12207 standard. Each framework reinforces the other, showing when other standards should be applied, as well as how they relate to one another.

The Road Map to Software Engineering allows practitioners to quickly locate the standards pertinent to questions arising in real projects. Providing students with a comprehensive body of knowledge, the text also assists experienced professionals in finding and filling gaps in their understanding. Endorsed and recommended by the Software and Systems Engineering Standards Committee of the IEEE Computer Society, this book is a useful guide for both practitioners and students.

Using software engineering standards in producing effective software

This book provides a single overview of "codified software engineering," the set of knowledge and best practices that apply to most projects most of the time. By laying out the accepted techniques, the text allows managers—as well as those paying the bill—to eliminate wasteful experimentation with unproved software practices while giving more attention to true innovations.

Prepared in accordance with the Guide to the Software Engineering Body of Knowledge (SWEBOK), The Road Map to Software Engineering organizes relevant IEEE software and systems standards, along with standards from other sources, using two frameworks: the SWEBOK Guide's topical knowledge areas and the widely used IEEE/EIA 12207 standard. Each framework reinforces the other, showing when other standards should be applied, as well as how they relate to one another.

The Road Map to Software Engineering allows practitioners to quickly locate the standards pertinent to questions arising in real projects. Providing students with a comprehensive body of knowledge, the text also assists experienced professionals in finding and filling gaps in their understanding. Endorsed and recommended by the Software and Systems Engineering Standards Committee of the IEEE Computer Society, this book is a useful guide for both practitioners and students.

Excerpt. © Reprinted by permission. All rights reserved.

The Road Map to Software Engineering

A Standards-Based GuideBy James W. Moore

John Wiley & Sons

Copyright © 2006 James W. Moore
All right reserved.
ISBN: 978-0-471-68362-9

Chapter One

Introduction

On an outside wall of the thirteenth century town hall in Rothenburg-ob-der-Tauber, Germany, hangs an equally old iron standard used to measure the length of loaves of bread. Subject to punishment were bakers who made their loaves too short-for cheating their customers-as were those who made their loaves too long-for raising unrealistic expectations. The goal of this chapter is to provide general material about software engineering and software engineering standards and to address the reader's expectations regarding the usefulness of the standards.

1. SOFTWARE ENGINEERING

The Institute of Electrical and Electronics Engineers defines software engineering, in IEEE Std 610.12, as:

(1) The application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software, that is, the application of engineering to software. (2) The study of approaches as in (1).

Most of the standards on this subject are practice standards rather than product standards, concerned with norms for the practice of software engineering rather than the interfaces of the products produced.

1.1. Is It Engineering?

One could be excused for denying the premise of this book. With few exceptions, software engineering is not among the engineering professions licensed in the United States and nearly all states have laws forbidding an unlicensed individual from offering services as an "engineer." There an unmistakable signs of change, though [SWEBOK04]:

Several universities, e.g., the University of New South Wales (Australia), McMaster University (Canada), the Rochester Institute of Technology (US), and the University of Sheffield (UK), offer undergraduate degrees in software engineering.

In the US, the Engineering Accreditation Commission of the Accreditation Board for Engineering and Technology (ABET) is responsible for the accreditation of undergraduate software engineering programs.

The Canadian Information Processing Society has published criteria to accredit software engineering undergraduate university programs.

The Texas Board of Professional Engineers licenses software engineers.

The Association of Professional Engineers and Geoscientists of British Columbia has begun registering software professional engineers and the Professional Engineers of Ontario has also announced requirements for licensing.

The Association for Computing Machinery (ACM) and the Computer Society of the Institute of Electrical and Electronics Engineers (IEEE) have jointly developed and adopted a Code of Ethics for software engineering professionals.

The IEEE Computer Society offers the Certified Software Development Professional certification for software engineering.

Recently, the US Department of Labor recognized "computer software engineer" as a distinct occupation [BLS04]. Most importantly, though, the IEEE Computer Society has published its Guide to the Software Engineering Body of Knowledge [SWEBOK04], providing a definitive characterization of the knowledge base underlying a profession. In deference to common usage and these promising developments, this book will use the term "software engineering"; readers may choose to view the term as a statement of a goal or an ideal rather than as a statement of a fact.

Engineering can be viewed as a closed feedback loop as shown in Figure 1. An engineering process consists of related activities performed in response to a statement of needs and consuming resources to produce a product. In order to manage or improve the process, one must exert control. Control is a decision-making mechanism that considers goals and constraints in the formulation of action that is intended to direct or modify the process. The decision to take action is based on measurements, quantitative evidence regarding the state of the process. Measurements can be made of conditions inside the process, products of the process, and the satisfaction of users of the products [SESC93]. We would expect software engineering standards to contribute to the implementation of such a model with respect to the development, operation, and maintenance of software systems.

Indeed, we will find standards related to the process, product, and resources involved in the software discipline. We will find standards describing the treatment of needs in software development, not only as requirements and specifications, but articulating less formal needs from more remote stakeholders. We will find standards describing management plans, measurements, and actions for the purpose of controlling the ongoing processes. Finally, we will find methods to articulate goals and constraints, even informal ones, to guide the managers.

So, even if the software discipline has not yet formalized the empirical underpinnings of an engineering discipline, we will find that, in many ways, it is acting as if it has.

1.2. Relationship to Other Disciplines

Software engineering occupies a position intermediate between, on the one hand, the mathematical and physical disciplines of computer science and technology and, on the other hand, the requirements of the particular application domains, applying the findings of the former to solve problems of the latter (see Figure 2). The techniques for the engineering of software can be viewed, in part, as specializations of those of more general disciplines, such as project management, systems engineering, and quality management. Furthermore, a software project must implement requirements imposed by cross-cutting disciplines like dependability and safety. These contextual disciplines are important to the reader of this book because software engineering standards must often be applied in conjunction with the standards from the other disciplines.

1.3. Body of Knowledge

The engineering style of education deals with rapidly changing technology by teaching well-accepted fundamentals; students are provided little choice regarding their curriculum. As a consequence, there is a set of things that we can expect every engineer to know [Parnas95]. The teaching material is based on a common, principle-based body of knowledge, codified by some more-or-less officially designated organization, often enforced by licensing requirements. For software engineering, this need has been filled by the publication of the IEEE Computer Society's Guide to the Software Engineering Body of Knowledge, with the purpose of providing "a consensually-validated characterization of the bounds of the software engineering discipline and ... a topical access to the Body of Knowledge supporting that discipline" [SWEBOK04]. The SWEBOK Guide provides a basis for both academic and professional development. The new Software Engineering volume of the joint IEEE-CS/ACM Computing Curriculum is largely based on the knowledge breakdown of the SWEBOK Guide-albeit normalized to the needs of undergraduate education. The Computer Society's Certified Software Development Professional (CSDP) certification is gained, in part, through an examination that traces to the SWEBOK Guide.

1.4. Fundamental Principles

In other fields, practice standards can be traced to a body of fundamental scientific and engineering principles that constrain the standards. A trivial example is that mechanical engineering standards are constrained by the three-dimensional geometry of physical objects. The codification of software engineering standards is faced by particular challenges in this area. First, the subject of the standards-software-is inherently intangible and unconstrained by the common laws of physics. Second, the discipline is relatively new, compared to other engineering disciplines, and many of its important concepts remain immature. Finally, unlike product interface standards, there are few market forces to cause convergence on selected technologies.

This has caused some problems. Unfettered by any integrating forces of principles or dominant products, some software engineering standards are ad hoc recordings of individual practices claimed to be "best." This is not bad when each standard is considered in isolation, but when the standards are considered as a body, we too often find them to be dis-integrated, capriciously different in detail, overlapping and occasionally contradictory. These characteristics put the erstwhile adopter of the corpus of standards into a difficult situation, because the adopters must themselves develop some mechanism to rationalize, explain, and relate the various standards chosen for implementation.

Part of the solution to the problem is the adoption of a framework of vocabulary, key relationships, and other constraints to which each individual standard must adhere. In fact, IEEE Software and Systems Engineering Standards Committee (S2ESC) and its international counterpart, ISO/IEC JTC 1/SC 7, have taken steps in this direction, efforts that are described elsewhere in this book. Perhaps a more basic requirement is for the identification of a set of fundamental principles that would serve to explain and motivate the provisions of the various standards. There are steps in this direction.

Figure 3 shows a notional depiction of the role of principle standards. The principles of software engineering would be regarded as selected, adapted, and specialized from the principles of engineering in general. The provisions of practice standards would be motivated by the software engineering principles and would be traceable to those principles. So-called "best practices" would be viewed as the detailed implementation of the provisions of the practice standards. Viewed in the other direction, practice standards would be regarded as descriptions of observed, effective best practices and the principles as abstractions of the practice standards. The principles found to be relevant beyond the scope of software engineering (perhaps those related to complexity, for example) might be considered as general principles of engineering.

In this model, we can view practice standards as existing in a tension between the consolidating and integrating forces exerted by the principles and the expansive and innovative forces exerted by the recognition of new, effective practices.

IEEE S2ESC has participated in efforts to identify fundamental principles for software engineering. A workshop at the 1996 Software Engineering Standards Forum considered candidate principles and developed a set of criteria to be applied to candidates [Jabir98]. Alternating workshops and Delphi exercises produced a candidate set of principles [Bourque02]:

Apply and use quantitative measurements in decision making Build with and for reuse Control complexity with multiple perspectives and multiple levels of abstraction Define software artifacts rigorously Establish a software process that provides flexibility Implement a disciplined approach and improve it continuously Invest in the understanding of the problem Manage quality throughout the life cycle as formally as possible Minimize software component interaction Produce software in a stepwise fashion Set quality objectives for each deliverable product Since change is inherent to software, plan for it and manage it Since tradeoffs are inherent to software engineering, make them explicit and document them To improve design, study previous solutions to similar problems Uncertainty is unavoidable in software engineering. Identify and manage it

2. SOFTWARE ENGINEERING STANDARDS

For the purposes of this book, the characterization of standards provided in [SESC93] is helpful:

A standard can be: (1) an object or measure of comparison that defines or represents the magnitude of a unit; (2) a characterization that establishes allowable tolerances or constraints for categories of items; and (3) a degree or level of required excellence or attainment. Standards are definitional in nature, established either to further understanding and interaction, or to acknowledge observed (or desired norms) of exhibited characteristics or behavior.

Most of the standards described in this book have been developed by Standards Developing Organizations (SDO) operating on the principles of consensus development and voluntary adoption. For the purposes of this book, the organizations are regarded as national (US, with a few exceptions) or international.

2.1. The Nature of Standards

Probably the most important word in the quotation above is the word "acknowledge." Many users have the belief that standards impose mandatory requirements. Of course, they don't because the use of a standard is generally voluntary. In the typical situation, a supplier applies a standard-not because it is required-but because it represents an opportunity to publicly claim conformity, a claim that is "acknowledged" by the marketplace. Suppliers seek this acknowledgment to distinguish themselves from competitors or, at the least, to mark that their products are suitable for a particular use.

Given that suppliers are interested in seeking the acknowledgment of the marketplace, there is an implicit competition among makers of standards to provide the best or most popular opportunity to make these claims. In short, the standards-makers want to maximize the number of users of their standard. One obvious way to do this is to make the conformance requirements easy to achieve or, at least, vague. The approach is shortsighted, though, because such standards gain little respect in the marketplace; hence, claims of conformity are poorly respected and do not provide the competitive advantage desired. In fact, capable suppliers desire the level of difficulty to be set high, to more sharply distinguish themselves from competitors. Left to their own devices, such suppliers would set standards so high as to serve as a barrier to competing products.

Therefore, standards necessarily exist in an uneasy tension between ease and difficulty of conformance. Various makers of standards may trade off the conflicting forces in different ways, leading to different compromises. That's one reason why there may be different standards on the same subject.

More fundamentally, though, consider what a standard does. It divides a class of products into two subclasses-those that conform and those that don't. But, why only two? Is it sensible to have more than two subclasses? In some cases it is, and some standards provide more than one class of conforming product. Furthermore, some standards provide specialized requirements for a specialized subset or niche of products; having many such standards for a particular product class simply provides lots of different subsets, suitable for different purposes.

In short, standards should be viewed simply as a way of naming things. Citing any particular standard, say PDQ-123, is shorthand for a statement that would otherwise be a long explanation of characteristics. PDQ-123 is simply a name for the subclass of products-the subclass that conforms to the provisions of the standard. Having many standards simply means that we have rich space of names and can distinguish among many similar subclasses of products.

(Continues...)

Excerpted from The Road Map to Software Engineeringby James W. Moore Copyright © 2006 by James W. Moore. Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

Edition details

• Publisher: Wiley-IEEE Computer Society Pr
• Publication date: 2005
• Language: English
• ISBN 10: 0471683620
• ISBN 13: 9780471683629
• Binding: Paperback
• Edition number: 1
• Number of pages: 434