Professor of Computer Science,

Embry-Riddle Aeronautical University, Daytona Beach, Florida, USA

1. Context

The last twenty years have witnessed significant advancements in the education of computing professionals (in fields such as computer science, software engineering, computer engineering and information systems). The Association for Computing Machinery (ACM), the IEEE Computer Society (IEEE-CS), and the Computer Sciences Accreditation Board (CSAB) have given encouragement, support, and guidance in developing curricula that are viable and relevant. We have moved from language and coding centered curricula to programs that emphasize theory, abstraction, and design. However, most academic programs in computing still devote little time to areas such as requirements modeling, design methods, architecture, reuse, software processes, quality issues, team skills, and other areas of software engineering essential to effective commercial software development. The use of formal methods in the development of software artifacts has received even less attention.

In recent year there has been a lot of interest and a number of activities associated with advancing the state of the software engineering profession. Since 1993, the IEEE-CS and ACM have been actively promoting software engineering as a profession. Special task forces have been directed at establishing a software engineering code of ethics and professional practice, determining accreditation criteria for software engineering programs supporting curriculum development, and preparing a guide to the software engineering body of knowledge. In 1998 the IEEE-CS and the ACM formed the Software Engineering Coordinating Committee (SWEEC) to foster the evolution of software engineering as a professional computing discipline and to coordinate the various software engineering "maturing" activities [SWECC]. A major part of the effort is the definition of a software engineering body of knowledge (SWEBOK) [Dupuis 00]. Another SWECC project is the Software Engineering Education Project (SWEEP). It was established to develop curriculum recommendations for software engineering programs [Barnes 98]. The SWEEP activities are part of a larger effort to update and improve computing curricula guidance that is embodied by the Computing Curriculum 2001 effort [CC2001].

There is still much confusion and misunderstanding about the various related computing disciplines (software engineering (SE), computer science (CS) and computer engineering (CE)). In the whole scheme of things, this is rather natural since the computing discipline is still new (compared say to mathematics and civil engineering) and as dynamic as any other field of research and practice. Unfortunately, the lack of common agreement about the nature of the discipline can and does cause problems in communicating about its critical issues. With this in mind and for the purpose of our discussions, I suggest the following definitions (from [Modesitt 00]):

2. Current State of Software Development

Software plays an increasingly important and central role in almost all aspects of daily life. The number, size, complexity, and application domains of programs being developed is growing dramatically. Unfortunately, there are serious problems in the cost, timeliness, and quality of development of many software products. The code in consumer products is doubling every two years; it is almost the norm for software projects to overrun their planned cost and schedule. Too many large-scale development projects are never completed, and many of those completed do not meet the user requirements and are of poor quality. Most software projects spend more than half their development time in testing and many deliver products with defect densities above 10 defects/KLOC. For the software discipline, this is not just a commercial issue, but a professional and ethical problem that would not be tolerated in other fields of engineering and science.

The central issue seems to be one of immaturity. Although, the term software engineer is becoming a popular title for software developers, there is little evidence to show that the practice of software engineering compares with rigor and discipline that is required for practice in other engineering fields. The quality problems arise from incomplete and imprecise requirements specifications, shoddy designs with poor documentation, and the almost sole reliance on testing for software quality assurance. The concepts of mathematical modeling and rigorous verification (the staple of other engineering fields) is rarely used in commercial software development.

From my own experience and research, industry is making little use of formal methods in the development of software, and mathematical techniques are not part of the normal practice of software engineering. This is highlighted in survey of software engineers ([Lethbridge 00] - a comprehensive study of the knowledge used by software engineers in their work), where the engineers ranked the importance of 75 knowledge areas. "Formal Specification Methods" was ranked 37th and "Predicate Logic" was ranked 39th. (Things like "specific programming languages", "data structures", "software architectures" and "requirements elicitation" was ranked at the top and things like "differential equations" and "VLSI" were ranked at the bottom.)

3. Current State of Computing Curricula

There are currently over a thousand undergraduate computing degree programs in the U.S. The vast majority of the graduates of these programs go into the software industry. Unfortunately, most are ill-prepared to use disciplined engineering practices to develop high-quality software. Currently most computing curricula (at least in the U.S.) require only a few courses that have substantial mathematical content. Typically a CS or CE program would have required courses in calculus, discrete mathematics, and a course in algorithms with a theoretical orientation. Beyond this, many would have required courses such as programming languages and operating systems, which would have some mathematical content. However, very few would have courses (or significant parts of courses) devoted to formal methods (methods used to develop and verify software artifacts such as requirements and design specifications). There are a number of emerging SE undergraduate programs (ten or so), most of which will have a required course in formal methods. The recent efforts of SWEEP and CC2001 are beginning to address these problems. It appears that both these activities have some promise of improving the use of mathematical techniques in computing curricula.

4. Some Ideas

First, the ideas that I am advocating are meant for the masses; that is, the discussion is in the spirit of "what should every graduate of a computing program know about formal methods".

In the design of any curriculum, the starting point should be the program objectives. Although objectives will differ across institutions, I believe the following objectives should be relevant to most programs and could be effectively combined with other curriculum objectives.

Objectives: Students that complete this program will be able to

• Describe how formal methods can be used in the development of software.
• Discuss, in detail, an industrial use of formal methods in the development of a commercial/government software product.
• Perform a trade-off analysis of the use of formal methods versus non-formal approaches in the development of a software product.
• Describe how informal and formal techniques can be integrated during software life-cycle development.
• Apply a formal method (formal language, techniques, tools, and process) to the requirements specification of a modest software system.
• Use formal methods to formally verify the design of a modest software system.

It seems that the objectives could best be accomplished by distributing formal methods content and activities throughout the curriculum. The first two years should include a course in discrete mathematics that covers basic set theory, predicate logic, proof techniques, and the introduction of a formal language (e.g. Z or VDM). The beginning computer science sequence (CS!, CS2, CS3) should introduce formalisms into design of small programs or modules (abstract data types, loop invariants, pre-conditions and post-conditions, symbolic execution, algorithm analysis). In other existing courses in the curriculum (such organization of programming languages, computer architecture and operating systems) the formal methods aspects of the subject matter should be pointed and where appropriate emphasized. In the last two years a course dedicated to formal methods seems appropriate. The course would give a breath view of methods, techniques, tools and literature; and it would involve a significant case study and a formal methods project. Final course work on software design and a life-cycle team project would involve the use of formal methods in concert with informal-traditional techniques. To help in this area, I believe that to ensure effective application of a method (formal or informal), there needs to be a defined process for using the method. The development and use of software processes is an active area in efforts to improve software engineering. In [Hilburn 96], I discuss a process for applying Z to a team requirements specification project.

These ideas are still somewhat imprecise, but hopefully with additional work and interaction with the working group they can become more clearly formulated.

The following references cover a variety of material related to computing curricula, formal methods, and software engineering.