Prof. David Parnas

In the 1960s, some scientists and mathematicians who were interested in computers observed that software development was a profession that had more in common with Engineering than it did with the fields in which they had been trained. They had mastered a body of knowledge and been taught how to extend that knowledge. They had not been taught how to build software products that would be used by strangers.

It was proposed that, in addition to “Computer Science”, there should be a new engineering discipline called “Software Engineering”. Critics said that a new field wasn’t needed but today the importance of the field is indisputable; we depend on software in the same way that previous generations depended on roads and engines. The world needs software development professionals who have learned to work with the discipline expected of professional engineers.

The early pioneers did not identify the capabilities required of practitioners in the new field. Although there have been several efforts to identify a “body of knowledge” for Software Engineering, none have captured the essence of the field. This talk addresses the question, “What should a Software Engineer be able to do?” Starting with two historical characterizations of the field by leading pioneers, it describes and explains a set of capabilities that are essential for today’s “Software Engineers”.

The talk is addressed to educators, managers, licensing authorities, and, of course, developers.

About the Tutorial

A “Crash Course” in Software Development

Abstract

While the only way to learn how to develop software is to develop software, this tutorial will introduce participants to some of the capabilities that are essential for software developers. Illustrations will be provided to introduce the participants to ways that they can do their job better. The capabilities discussed are:

1. Document driven distributed development
   Future software will be developed by teams that are located in many countries and speak many different languages. Such projects are often hampered by communication difficulties caused by the ambiguities inherent in natural language communication. This tutorial will introduce an alternative approach.
2. Communicating precisely between developers and stakeholders
   A document that provides a precise description of the externally visible behaviour of a proposed product can be used to communicate between developers and the future users (or their representatives). Such communication is essential if the development team is to build what the users need. The tutorial will show what such a document looks like.
3. Communicating precisely among developers
   Modern software is built by teams. Each team member must know what behaviour is required of the module that he/she develops as well as what behaviour can be expected of modules written by other team members. This communication requires precise interface documentation. The tutorial will show what such documents look like.
4. Designing and maintaining multi-version software
   The days when software was written, used for a short time ,and then discarded or replaced are long gone. Today’s software products must, and will, exist in many versions. The tutorial will present architectural design principles that are essential to making software that can be revised and maintained for many generations.
5. Software quality assurance
   As our world becomes increasingly dependent on software, trustworthiness and availability become increasingly important. The tutorial will illustrate how precise documentation can be used to enhance the effectiveness of software testing and inspection.

Find Detailed Tutorial Schedule Here