Date: Mon, 3 Jul 95 21:47:34 EDT From: parnas@triose.crl.McMaster.CA (Dave Parnas) Subject: Two Short-Courses on Software Engineering McMaster University Faculty of Engineering presents Two Short-Courses on Software Engineering SOFTWARE DESIGN: AN ENGINEERING APPROACH ----------------------------------------- August 8-12, 1995 INSPECTING CRITICAL SOFTWARE ---------------------------- August 15-17, 1995 instructed by Prof. David L. Parnas Department of Electrical and Computer Engineering McMaster University's Faculty of Engineering is pleased to present two courses on Software Engineering. "Inspecting Critical Software" was presented last summer and was well received by all who attended. "Software Development: An Engineering Approach" a course previously taught on-site at several development organizations, provides a broader, more basic, introduction to software design principles and will be useful for those developing software that does not require critical inspection. It is aimed at engineers who want to know how to design software well. THE INSTRUCTOR Dr. David L. Parnas is an internationally known expert and researcher in the area of software engineering. He is well known as the first person to write about "information hiding" which is the basis of modern "object-oriented" techniques. He has also been a leader in the development of mathematical models for software description. Dr. Parnas, whose motto is "connecting theory to practice", initiated and led the US Navy's Software Cost Reduction project. He has also been a consultant to the Canadian Atomic Energy Control Board, U.S. Navy, IBM's Federal Systems Division and many other organizations. He has won several "best paper" awards, has an honorary doctorate from the ETH in Zurich, and has provided education for many industrial organizations. He is a project leader for the Telecommunications Research Institute of Ontario. Dr. Parnas is a Fellow of the Royal Society of Canada, a Fellow of the ACM, and a Senior Member of the IEEE. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - SOFTWARE DESIGN: AN ENGINEERING APPROACH A Practical 4-day Course BACKGROUND Although the process and technology of software development has been the subject of serious study for three decades, the results of this study have not found their way into engineering practice. Engineers learn about programming language and other tools from manuals and "hard knocks"; they rely on their intuition instead of well-established software-design principles. This course teaches a better approach. CONTENT This 4-day course has been created to teach design, documentation and validation principles to those who are now building software in their day-to-day work or as a profession. It shows how to use engineering approaches in software design and provides some introductory experience in using the notations and techniques that are presented. A working example will be used throughout the four days, providing continuity to illustrate the principles and techniques of the course. This practical course is intended for professionals who are skilled in one or more computer languages, and are looking for design principles and analytical techniques. PROGRAM Monday 08:00-10:00 Overview of the Software Development Process 10:15-12:00 Mathematics for Software Engineering 13:00-14:15 Exercise: Describing Software Mathematically 14:30-16:00 Functional Documentation of Computer Systems 16:15-17:00 Exercise: Controlled and Monitored Variables Tuesday 08:00-09:30 Documenting Requirements Part I - The 4 Variable Model 09:45-11:00 Documenting Requirements Part II - Notation 11:00-12:00 Exercise: Requirements 13:00-13:30 Discussion: Requirements 13:30-14:45 Exercise: Requirements (cont'd.) 15:00-16:00 Module Structure: Basic Information Hiding/Abstraction 16:00-17:00 Exercise: Module Structure Wednesday 08:00-09:00 Module Structure: More Complex Systems 09:15-09:45 Module Structure Revisited 10:00-11:00 Design of Module Interfaces 11:00-12:00 Exercise: Module Interface Design 13:00-14:30 Module Interface Specifications 14:45-16:00 Exercise: Interface Specifications 16:00-17:00 Hierarchical Structure in Software Design Thursday 08:00-10:00 Internal Module (Program) Documentation 10:15-11:00 Exercise: Program Design for Bicycle Speed Displays 11:00-12:00 Full Documentation of a Circular Queue 13:00-14:30 Quality Assurance for Critical Software 14:45-16:00 Software Aging 16:00-17:00 Final Discussion - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - INSPECTING CRITICAL SOFTWARE An Intensive 3-day Course BACKGROUND Software is critical to the operation of modern companies and is frequently a key component of modern products. Some pieces of software are particularly critical; if they are not correct, the system will have serious deficiencies. Systematic inspection is essential. This course teaches a procedure for software inspection that is based on a sound mathematical model and can be carried out systematically by large groups. The software inspection procedure combines methods used at IBM, work originally done at the U.S. Naval Research Laboratory for the A-7E aircraft, and procedures applied to the inspection of software at the Darlington Nuclear Power Generating Station. The method has been refined and enhanced by the Software Engineering Research Group at McMaster University. It can be applied to software written in any imperative programming language. CONTENT This 3-day course will give participants an understanding of the way that mathematics can be used to document and analyze programs. Participants should be experienced programmers and willing to use some basic mathematics. The mathematics is classical and takes up only a few hours of the course, however, it is fundamental to the method. It is expected that the participants will be accustomed to reading code written by others and it will be helpful if they can read Pascal. The method is language independent. On the third day, participants inspect code written in a language that they use in their workplace. This course presents an approach to active design reviews that has the reviewers writing precise documentation about the program and explaining their documentation to an audience of other reviewers. A significant part of each day is spent using the ideas that have been presented. On the last day, participants inspect a small program that they bring with them from their company. In previous courses, unexpected discrepancies were found in every program that was inspected. PROGRAM Monday 09:00-10:15 Overview and Case Study: A discussion of previous applications of the method 10:30-12:00 Predicate Logic: Evaluation rules for predicate expressions 13:30-15:00 Tabular Expressions: Writing of readable predicates using two-dimensional notations. 15:30-17:00 Describing Program Function: Writing program descriptions using predicates and tables Tuesday 08:30-10:00 Presentation of "palav" 10:15-11:15 Participant decomposition and inspection of "palav" 11:30-12:00 Discussion of inspection results 13:30-14:30 Presentation of Dijkstra's Dutch National Flag (DNF) Problem: Participants will be given a copy of E.W. Dijkstra's explanation of a program along with several sample programs. They will be asked to apply the inspection method and approve or reject each program. 14:30-16:15 Participant inspection of DNF Problem 16:30-17:00 Discussion Wednesday 08:30-12:00 Inspection of a 'Real' Program Each participant should bring a small program, perhaps 50-100 lines, that is critical to some project. We prefer mature code; it should compile and have survived some testing or use. Working in small groups, the participants will take a section of the program and inspect it using the method learned so far, producing documentation as they go. 13:30-15:30 Report on the Inspection Results The first part of the afternoon will be devoted to a series of reports by the participants on the results of their efforts in the morning. 15:45-17:00 Software Testing The remainder of the afternoon will be devoted to a discussion of the interaction between testing and inspection. We treat testing, not as an alternative to inspection, but as complementary. We discuss the way that the documentation produced in the inspection process can be used in the testing process. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - INQUIRIES Inquiries concerning either course should be directed to: Jan Arsenault McMaster University Phone: (905) 525-9140, ext. 24910 Fax: (905) 577-9099 e-mail: arsenau@mcmaster.ca ------------------------------