National Academies Press: OpenBook

Summary of a Workshop on Software Certification and Dependability (2004)

Chapter: 3 Summary of Closing Session

« Previous: 2 Summary of Panel Sessions and Presentations
Suggested Citation:"3 Summary of Closing Session." National Research Council. 2004. Summary of a Workshop on Software Certification and Dependability. Washington, DC: The National Academies Press. doi: 10.17226/11133.
×

3
Summary of Closing Session

The workshop finished with a brainstorming session, the goal of which was to identify the important questions and issues raised during the workshop and to determine those that merit further investigation by the committee. The participants reviewed the following aspects of software certification: applications, lessons learned from failures and successes, scope, techniques, process-based and product-based methods, and obstacles to effective certification.

Certification has traditionally been applied to safety-critical infrastructure that is procured or regulated by the government. Participants wondered whether it should be applied more widely. Some suggested that even consumer software was an appropriate target for certification, as it has a substantial impact on the quality of life, while others advocated certification of operating systems and development platforms. Some participants cautioned that too-strict certification requirements could have negative impacts, such as the expenditure of resources on the production of ultimately unhelpful documents. At the same time, it was noted that regulation and associated certification processes exist to defend and protect those who have no other voice in the product development process, and that it would be unfortunate if truly high quality software were confined to the domain of nuclear reactors and airplanes. The committee was encouraged to host a panel of representatives from areas where certification is generally considered effective (such as avionics) to discuss the potential for broader applicability of certification.

It was also suggested that the committee study certification failures. Failures may include certification of a device or system that failed to achieve the goals for its dependability and certification whose costs caused the project to fail. The National Security Agency’s Orange Book1 was suggested as an example of a certification effort with, at best, mixed outcomes. According to one panelist, “Systems were evaluated and blessed at C2 [a particular level of assurance determined in the Orange Book]; people thought that it meant something, but it didn’t.” Participants suggested that the committee attempt to get honest assessments from a few people who would be candid about what went wrong. It was also suggested that the committee investigate certification successes. The FAA, for example, has been certifying software for quite some time and may be able to offer lessons learned from what has worked and what has not.

Participants disagreed about the appropriate scope of certification. Some thought it should focus on one or two narrow attributes, while others argued that it should encompass all realistic requirements in a common context in order to address the fact that requirements frequently interfere

1  

More formally known as the DOD Trusted Computer System Evaluation Criteria, DOD 5200, 28-STD, December 26, 1985.

Suggested Citation:"3 Summary of Closing Session." National Research Council. 2004. Summary of a Workshop on Software Certification and Dependability. Washington, DC: The National Academies Press. doi: 10.17226/11133.
×

with one another. There did appear to be some consensus among panelists that certification processes should focus on the desired properties rather than on the manner in which the artifact is constructed. It was observed, however, that some properties that are not directly observable may require secondary evidence. There was substantial interest in certifying components for composability. There was also interest in certification processes that can be applied to a software component as it evolves.

There was some discussion of appropriate techniques for certification. Several participants contended that formal methods have a role to play in certification and that although there are limits to what they can achieve, “we should continue the long march of formal methods.” It was suggested that scale and adoptability should be the primary aim of continued research in this area, with a focus on “small theorems about large programs.” There was also controversy over the maturity of certification techniques and of software development in general. Some felt that generally reliable software can be achieved using existing software development techniques but that certification could be used to “raise the bar.” Others emphasized the need for more research on the use of tools and techniques to increase software quality.

The question of process-based versus product-based certification was discussed. There was some consensus that a combination of the two is necessary, and that “process evidence is only secondary to product evidence.” The new European standards ESARR 62 and SW013 were offered as examples of the combination approach. It was suggested that formal methods could offer support for “baking the evidence of process into the artifact itself,” using such techniques as proof-carrying code.

Panelists warned of several obstacles to effective certification. For example, standards that mandate adherence to untestable criteria are unlikely to be effective, as are certification processes that lack accountability. Standards that provide insufficient connection to the end goal can increase the cost of creating software without increasing its actual dependability. Standards may be too technology dependent, mandating methods of constructing (or not constructing) software. They may mandate the production of enormous documents that have little if any impact on the dependability of the software, or the measurement of “trivia” that is easily measurable but offers only a false sense of security.

Finally, participants briefly touched on some additional considerations, and the session concluded with suggestions for the committee in the preparation of its final report. There was some support for the notion that software development companies should be required to publish defect rates. It was noted that software products are often licensed without the “fitness-for-purpose” requirements that apply to other goods. The education of both professionals and consumers was a recurring topic: “We should make tools that give people best practices demos, so people can tell how to write good software, and can tell the difference. Consumer pressure [to produce dependable systems] is not as powerful as people had hoped.”

The committee was encouraged “not to be hidebound by current practices” and to take a longer-range view about what people involved in the development of complex software systems need to learn and know. What are the criteria for a good study in the area of certifiably dependable systems? What should the committee do to ensure that such a study provides value to the community and capitalizes on the wisdom and experience of the community at large?

It was suggested that the committee’s final report should, at least in part, be positive. Participants observed that the community tends to be negative but that much has been achieved. It

2  

The Eurocontrol Safety Regulatory Requirement (ESARR 6) provides a set of guidelines to ensure that risks associated with operating any software in safety-related ground-based air traffic management systems are reduced to a tolerable level. This guideline was developed by the European Organisation for the Safety of Air Navigation.

3  

SW01 is part of a larger set of civil aviation guidelines and standards called CAP 670 established by the Civil Aviation Authority in the United Kingdom. SW01 deals specifically with the design and assessment of ground-based services, including air traffic control systems.

Suggested Citation:"3 Summary of Closing Session." National Research Council. 2004. Summary of a Workshop on Software Certification and Dependability. Washington, DC: The National Academies Press. doi: 10.17226/11133.
×

was suggested that clear recognition of the problems and acknowledgment that they are being worked on are equally important. Achieving certifiably dependable systems is a long-term goal, with many unknowns and the potential for significant changes in the way things are done. Changes will take a long time to implement, and so the goal should be to set out a road map. It is important to clearly distinguish between what can be done now and what is desirable but requires technology that does not yet exist.

Suggested Citation:"3 Summary of Closing Session." National Research Council. 2004. Summary of a Workshop on Software Certification and Dependability. Washington, DC: The National Academies Press. doi: 10.17226/11133.
×

This page intentionally left blank.

Suggested Citation:"3 Summary of Closing Session." National Research Council. 2004. Summary of a Workshop on Software Certification and Dependability. Washington, DC: The National Academies Press. doi: 10.17226/11133.
×
Page 21
Suggested Citation:"3 Summary of Closing Session." National Research Council. 2004. Summary of a Workshop on Software Certification and Dependability. Washington, DC: The National Academies Press. doi: 10.17226/11133.
×
Page 22
Suggested Citation:"3 Summary of Closing Session." National Research Council. 2004. Summary of a Workshop on Software Certification and Dependability. Washington, DC: The National Academies Press. doi: 10.17226/11133.
×
Page 23
Suggested Citation:"3 Summary of Closing Session." National Research Council. 2004. Summary of a Workshop on Software Certification and Dependability. Washington, DC: The National Academies Press. doi: 10.17226/11133.
×
Page 24
Next: Appendix A: Workshop Agenda »
Summary of a Workshop on Software Certification and Dependability Get This Book
×
Buy Paperback | $29.00 Buy Ebook | $23.99
MyNAP members save 10% online.
Login or Register to save!
Download Free PDF

Certification of critical software systems (e.g., for safety and security) is important to help ensure their dependability. Today, certification relies as much on evaluation of the software development process as it does on the system’s properties. While the latter are preferable, the complexity of these systems usually makes them extremely difficult to evaluate. To explore these and related issues, the National Coordination Office for Information technology Research and Development asked the NRC to undertake a study to assess the current state of certification in dependable systems. The study is in two phases: the first to frame the problem and the second to assess it. This report presents a summary of a workshop held as part of the first phase. The report presents a summary of workshop participants’ presentations and subsequent discussion. It covers, among other things, the strengths and limitations of process; new challenges and opportunities; experience to date; organization context; and cost-effectiveness of software engineering techniques. A consensus report will be issued upon completion of the second phase.

  1. ×

    Welcome to OpenBook!

    You're looking at OpenBook, NAP.edu's online reading room since 1999. Based on feedback from you, our users, we've made some improvements that make it easier than ever to read thousands of publications on our website.

    Do you want to take a quick tour of the OpenBook's features?

    No Thanks Take a Tour »
  2. ×

    Show this book's table of contents, where you can jump to any chapter by name.

    « Back Next »
  3. ×

    ...or use these buttons to go back to the previous chapter or skip to the next one.

    « Back Next »
  4. ×

    Jump up to the previous page or down to the next one. Also, you can type in a page number and press Enter to go directly to that page in the book.

    « Back Next »
  5. ×

    Switch between the Original Pages, where you can read the report as it appeared in print, and Text Pages for the web version, where you can highlight and search the text.

    « Back Next »
  6. ×

    To search the entire text of this book, type in your search term here and press Enter.

    « Back Next »
  7. ×

    Share a link to this book page on your preferred social network or via email.

    « Back Next »
  8. ×

    View our suggested citation for this chapter.

    « Back Next »
  9. ×

    Ready to take your reading offline? Click here to buy this book in print or download it as a free PDF, if available.

    « Back Next »
Stay Connected!