ACM '81, November 9-11, 1981

Tutorial Abstract

SOFTWARE ENGINEERING TUTORIAL

Murray R. Berkowitz, Gordon Davis,

Kenneth T. Orr, James A. Senn,
Darrell Ward *

the practical application of scientific knowledge

in the design and construction of computer programs
and the associated documentation required to develop, operate, and maintain them."[l]

INTRODUCTION
The field of Software Engineering has undergone some of the most profound changes in the last
decade.
In recent years, the National ACM Conferences have been giving increasing attention to
Software Engineering --"Structured Program Planning
and Design:
Standardization Needs" (ACM '79 Detroit) and "More on Structured Design" (ACM '80 Nashville).

The application of basic engineering methods

to software system building has resulted in a number of new system development disciplines:

This session contains treatment of software

engineering with emphasis on real applications.
Presented are state-of-the-art software techniques
including the latest refinements in structured
analysis and design and programming methodologies.
Several issues related to the portrayal of software
design include architectural, structural, behavioral,
and informational considerations.
Stressed are
techniques for implementing reliable, maintainable
software.
Also offered are software management
approaches.
Highlights include:

i.

Structured Requirements

2.

Structured Analysis

3.

Structured Design

4.

Structured Programming

5.

Walkthroughs

6.

Top-Down Implementation

7.

Software Tools

8.

Software Metrics

Software Engineering within a Microprocessor

Environment

In combination, these are often referred to as

"software engineering."

Structured Systems Requirements

For over a decade, the computer science/data

processing community has been investigating and
applying the techniques we have called "structured"
and now are calling "software engineering." While
"software engineering" is a very broad and illdefined term, it is clearly more than "structured
programming" or even "structured design"; software

Database Considerations of the Software

Engineering Problem
Software Test Engineering Methodology
Documentation Techniques

*Murray R. Berkowitz - Visiting Professor, Graduate

School of Management, University of Dallas; Visiting
Industrial Professor, Dept. of Computer Science
and Engineering, Southern Methodist University;
Sr. Computer Systems Engineer, Advanced Computer
Systems Laboratory, Texas Instruments Incorporated.

OVERVIEW
According to Barry Boehm, "Software Engineering
is the means by which we attempt to produce all of
this software in a way that is both cost-effective
and reliable enough to deserve our trust .... (It is)

Gordon Davis - Professor, Dept. of Management

Information Systems, University of Minnesota
Kenneth T. Orr - President, Ken Orr & Associates
James A. Senn - Professor, School of Management,
State University of New York at Binghamton.
Darrell Ward - Assoc. Professor, Dept. of Computer
Sciences, North Texas State University; Software
Systems Engineer, Advanced Computer Systems
Laboratory, Texas Instruments Incorporated.

169

ACM '81, November 9-11, 1981

Tutorial Abstract

engineering subsumes these and more. We have been

"structuring" the design of programs, of systems,
and lately, of management.
The problems are that
not all installations use the structured techniques
and those that use structured planning and design
do not use it for all their tasks or consistently.
There is no standard as to either the criteria for
measuring the effectiveness of the design or its
representation and documentation.
The fluid environment of computer professionals necessitates a
training or retraining period for personnel new to
a particular installation.
This is perceived as
not being cost-effective, and hence there is some
reluctance on the part of many installations to
adopt any software engineering methodology.
Standardization of the techniques of, criteria for
measurement, and representation and documentation
across software engineering methodologies applied
to the planning and design of computer-based
systems and programs would increase its utilization.
The need for standards and standardization was addressed at an earlier ACM conference [2].

tools, etc. that complicate the development of

systems within this environment. Also, most systems developed within such an environment require
the utmost with respect to hardware/software reliability. Thus, one can see the need to direct
attention, from a software engineering perspective,
to the special attributes that characterize this
environment.
This tutorial develops the ongoing work addressing these two considerations within the microprocessor environment. The objective is to present
the current tools supporting this environment as
well as the future needs of such an environment.
STRUCTURED SYSTEMS REQUIREMENTS
In 1976, Barry Boehm put forth the following
definition of software requirements engineering:
"Software requirements engineering is the discipline for developing a complete, consistent,
unambiguous specification - which can serve as a
basis for common agreement among all parties concerned - describing what the software product will
do (but not how it will do it; this is to be done
in the design specification)."[l]

An overall goal of software engineering is to

enhance the quality of the software systems we
build.
It is widely accepted that a problem in
achieving this goal is that the definition of
"software quality" is subjective and intuitive.
According to McClure [3], "we cannot realistically
institute quality control measures unless we first
define quality in more rigorous, quantitative
terms."

Unfortunately, since then we have made very little

progress in the techniques used for determining
software requirements other than a general ad hoc
manual blend of systems analysis and common sense
or (more often) ad hoc manual blends of politics,
preconceptions, and salesmanship.

Software engineering is a broadly used term.

A major difficulty in implementing software engineering is motivating software developers to a
belief in the utility of the methodology.

Current technology includes the ISDOS system

developed by Teichroew and his group at the
University of Michigan [4], the Software Requirements Engineering Program (SREP) developed by TRW
for the U.S. Army Ballistic Missile Defense
Advanced Technology Center [5,6,7], the work on
Structured Systems Requirements by Ken Orr &
Associates in the commercial sector, and various
efforts for developing "Programming Environments"
including Unix, Interlisp, and the Ada Integrated
Environment (per "Stonemmn").

SOFTWARE ENGINEERING WITHIN A

MICROPROCESSOR ENVIRONMENT
With the recent proliferation of microprocessor use, the question of software engineering use
within this unique environment has become very
prominent. There are two primary aspects for consideration within this environment:
i. How can the micrcprocessor environment be
utilized to support the development of systems
on all types of computer mainframes (e.g. from the micro systems to the large computing
environments)?

It is evident that there will continue to be

different schools of requirements engineering,
just as there are different schools of systems,
programming, and database design. The requirements engineering schemes will continue to be
affected by the various approaches used at the
design level. Some techniques will be more complex than others.

2. Does the microprccessor environment present

special problems requiring drastically different approaches with respect to system
development?

Requirements engineering is concerned with the

functional systems of the organization whose realworld outputs are the products and decisions of the
organization [8,9,10,11,12].
It is concerned with
the definition of the tasks that must be carried on
in the organization and the information involved to
support those tasks. Currently much of the work
traditionally done in the design phase of the life
cycle has migrated to the requirements phase. By
the end of requirements engineering, all parties
concerned should have a clear idea of exactly what
the system will and will not provide.

There has been considerable activity recently

directed to the identification of tools that would
support the system developer.
Certainly, many of
these tools are viable for implementation on per~
sonal computing systems, thus providing the system
developer a personal tool for assisting in the system development. This area is clearly a fertile
research area and will continue to be as this technology continues its dramatic advances.
Clearly, the microprocessor environment presents constraints with respect to memory size,
peripheral device support, execution speed, software

Unfortunately, it takes a long time before

state-of-the-art becomes state-of-the-industry.

170

ACM '81, November 9-11, 1981

Tutorial Abstract

Progress will probably not be evolutionary The

trend involves the impact of having formal, machineanalyzable requirements specifications. This will
improve software reliability and make our software
more portable. The requirements thus engineered
serve to drive the design engineering and test
engineering phases.

To assist with the requirements, design, construction, and testing of systems the CASED would
provide models.
These would graphically describe
a conceptual design and would be used as a baseline
for a system or subsystem development. For any
given firm, the majority of software development is
fairly similar; the models would be standard for
the firm. The productivity gains from such a
system are great.

SOFTWARE ENGINEERING DESIGN

Over the last few years, with the great changes
in hardware and software technology, it has become
increasingly possible to use the computer extensively in the development and maintenance of
systems. It has now become clear that the possibility of Computer-Aided Software Engineering
Design (CASED) is real. Hardware costs are now reduced to the point that it becomes entirely feasible
to have work stations and computer systems for the
analyst, programmer, manager, and user. These work
stations can be dedicated solely to the systems development process. Given current inflationary
economics, cost-effective systems and software
become even more important.

A good CASED system must also consider the management needs for planning and project management.
Within the system would be tools to assist with the
major planning functions, including:
Administrative planning and reporting
Conversion and implementation plans
Cost and time estimating
Documentation
Project management controls and reporting

Vendors are now providing a long line of products: language generators, data dictionaries, data
bases, screen and report generators, simple model
languages, "user-friendly" systems, multi-purpose
application packages, and on-line, interactive
tools. The problem is that each of these only
attacks a very small piece of the problem.

Quality assurance controls and reporting

Scheduling
The need for a CASED exists, as evidenced by the
variety of ongoing efforts in this area. As computer software becomes yet more important and complex, the need for such a system for requirements,
design, construction, test, and maintenance is
obvious.

As Software Engineering Design becomes more

rigorous, there will be an increasing capability to
automate the tools used. The long term goal is an
integrated computer system intended specifically to
support software engineering and management activities and to improve software productivity and product quality. This system will provide highperformance automation of modern methodologies of
software design, development, testing, documentation
and management for a variety of target machine
architectures, applications and programming languages. The system will incorporate intelligent,
interactive programmers workstations with low-cost
local host processors and, through them, access to
a worldwide network of information systems, databases, and engineering and management tools. The
programmers workstation will provide a single,
uniform, convenient interface between its users
and all host computer systems. It will support
word processing and program text generation in
most commonly used languages. Special attention
will be given to the development environments
needed for high order languages and to integrated
hardware/software development activities.

DATABASE CONSIDERATIONS OF THE

SOFTWARE ENGINEERING PROBLEM
At ACM '80, a comparison was made between
the structured design techniques and database
methodologies [13]. The applicability of Structured
Design techniques in the structuring of Data Bases
was examined. The methodologies of Flavin [14],
Molina [15], and Teorey and Fry [16] were shown to
be similar and applicable to the database considerations within a software engineering problem.
Further, it was shown that each of the database
methodologies was merely a special application of
the general structured design techniques of software
engineering.
"Structured Data Base" was defined as the
"Design of structures to support data by systematically decomposing the tasks into successively simpler parts deriving from a set of user information
and processing requirements and maintaining the
distinction between the logical and physical views
of this realm."[13]

The basic functions of a CASED system must

be editing, system construction, and file manage~
ment. The editing function will allow the enter~
ing, updating, and storage of software and related
documentation.
System construction would translate
these into code, programs and procedures, to be
executed on a specified computer system. File
management would be internal to the system, but
database management would be transparent to the
user and transportable.
It would control access,
backup, recovery, and auditing of all objects or
files used by or stored in the CASED system,

Operational strengths and problem areas were discussed. Specifically, the database methodologies
were seen as being compatible with the structured
design techniques, the database methodologies were
shown to be valuable as a DBMS selection tool, and
the structured design techniques could be used for
managing a database design project. The conflicting
demands of efficient database design versus optimal
database design were viewed as problem areas, as

171

ACM '81, November 9-11, 1981

Tutorial Abstract

were the many system design decisions that have

been dictated by the target DBMS and the view
equating database design to the design of the
entire system.

cases should concentrate on the input, output, and

functional boundaries. The input boundaries are
the upper limits, lower limits, and other boundaries associated with the system inputs. Output
boundaries are the upper limits, lower limits, and
other boundaries associated with the outputs produced by the system. Functional boundaries are
intrinsic to the specific module or component being
tested. For example, suppose a module LISTSORT has
been specified to sort a list of items. The functional boundaries would be exercised by determining
what happens if:

Areas for further research and development

remain database design aids including automated
tools for logical design, the information structure design phase of logical design, the development of data model independent tools and DBMS
independent tools; more research emphasis on
logical design of databases including how the
logical structure should model the real world and
be adaptable to constantly changing user requirements; the expanded role of data dictionaries; and
better documentation and associated tools.

i.

The list is empty.

2.

The list is unique.

STRUCTURED TEST ENGINEERING METHODOLOGY

3.

The list is already in sequence.

Unfortunately, software testing and reliability

activities are typically not considered until the
coding has been run and found not to work. It is
greatly acknowledged that at this stage of the life
cycle the cost of reworking the project is extremely
high. We need to develop a methodology to guide
software engineers in test engineering and acceptance testing. Emphasis would be on the development
of a "testing life cycle" methodology. This methodology would build upon what is currently known
about software reliability models, software error
data, test sufficiency and program proving, program
verification, and fault-tolerance. Automated tools
could perform static code analysis, test case preparation, test monitoring and output checking, fault
isolation and debugging, and integration of routines
into systems.

4.

All of the entries of the list are the

same.

5.

The list is full.

The union of the above produces a quality assurance

test set.
Some automated aids have been integrated into
programming languages and compilers (e.g. - static
code checking). We should see added useful criteria
and tools for test completeness, especially as
regards "exercising all data elements" in an appropriate way. While the advances in test engineering
tools have begun to be made available to those
working in higher-level languages, it is probably
going to be some time before assembly-level language
software development efforts cease, if ever. Tools
based on cross-compiler capabilities on large
machines can provide relief. This is a further
outgrowth from the "host-target" ideas evolving
from programming environments.

Acceptance testing requires the development of

a test plan. The plan should establish responsibility for testing the system, establish procedures
and standards for testing, establish the criteria
for the completion of various forms of testing, and
schedule the activities and resources needed by the
testing effort. The completion criteria must emphasize the quality of testing and might include:

DOCUMENTATION TECHNIQUES
Until recently, much of the computing community
demonstrated little or no knowledge of the importance documentation should have in the systems
development effort. Belying this was the attitude
that design, coding, and implementation of new
systems was more important and there was not time
to be concerned with documentation. Documentation
remains an ill-defined, undesirable chore to be put
off as long as possible, if not indefinitely. It
is still not realized by all software professionals
that a major contributor to the problems encountered
is the inadequacy or non-existence of documentation.

Every module in the system must have been invoked at least once, though not all possible
combinations of modules may have been executed.
Every instruction must have been executed at
least once, though not necessarily with the
full range of data elements.
Every decision must have been exercised,
though not all combinations of decisions
may have been exercised.
A certain number of known bugs might be
secretly "seeded" in the system, and the
number of seeded bugs found during the testing process can determine the "effectiveness"
of the test data.
Further, all testing procedures should include a
description of the test, complete with test data and
expected results. It is obvious that it is impossible to generate every test case for every item in
the data dictionary or for every data element.
Research has shown that errors tend to cluster,
particularly at the "boundary"conditions. The test

i.

The actual writing of the documentation for

individual programs of the system.

2.

Filing and storage of the documentation.

3.

Traditional documentation did not recognize

the existence of the non-programmer/analyst
audience - the user.

In today's environment, good documentation is essential. Documentation must begin when a program or
system is first conceived and continue throughout
the project life cycle. Good documentation cannot
exist without management commitment, well-conceived

172

ACM '81, November 9-11, 1981

Tutorial Abstract

documentation standards, and documentation

techniques.
These must consider documentation
within the context of the particular organization
structure and the project characteristics.

REFERENCES

A logical, systematic approach toward the generation, control, handling, filing, referencing,
and retrieving of documentation is both desirable
and critical in software engineering.
During the
development of a project, project team members will
want up-to-date, easily accessible documentation.
The programmers and engineers "in the field" need
quick turnaround on working documents they use
daily. As these documents mature and stabilize,
they may be turned over to those responsible for
production documents.
Three significant distinctions are:

[i]

Boehm, B. W.; "Software engineering," IEEE

TRANSACTIONS ON COMPUTERS, C-25, 12(December
1976), 1226-41.

[2]

Berkowitz, M. R.; "Structured program planning

and design:
Standardization needs,"
PROCEEDINGS OF THE 1979 ANNUAL CONFERENCE,
ACM, October 1979.

[3]

McClure, C.; "Developing software with maintainability in mind," 1981 ACM COMPUTER
SCIENCE CONFERENCE, ACM, February 1981.

[4]

Teichrow, D. and Sayani, H.; "Automation of

systems building," DATAMATION, 17,
16(August 15, 1971), 25-30.

[5]

Davis, C. G. and Vick, C. R.; "The software

development system," IEEE TRANSACTIONS ON
SOFTWARE ENGINEERING, SE-3, l(January 1977),
69-84.

[6]

Afford, M.; "A requirements engineering

methodology for real-time processing requirements," IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, SE-3, l(January 1977), 60-69.

[7]

Bell, T. E., Bixler, D. C., and Dyer, M. E.;

"An extendable approach to computer-aided
software requirements engineering," IEEE
TRANSACTIONS ON SOFTWARE ENGINEERING, SE-3,
1(January 1977), 49-60.

[8]

Orr, K. T.; STRUCTURED REQUIREMENTS DEFINITION

Topeka, Kansas: Ken Orr and Associates
(formerly LKA).

[9]

Ross, D. and Schoman, K.; "Structured

analysis for requirements definition,"
SECOND INTERNATIONAL CONFERENCE ON SOFTWARE
ENGINEERING, San Francisco, California, 1976.

Information ori$inators versus document

writers;
Lo$ical versus physical text formatting; and
Workin$ versus production documents.
These working documents must be simple and easy-todigest for management to monitor the progress being
made and for the end-user to meaningfully communicate and participate with software development professionals in the execution of the project tasks.
Following system implementation, the end-user
and system operations need production documentation
that is readily available and pertinent to the
routine operation and management of the system.
Automated systems are needed which facilitate
creation and dissemination of documentation from
one department to another, from one project phase
to the next, and from a filing mode to a reference
or retrieval mode. Such an automated system would
have tools which facilitate generation, flow, and
retention of the documentation, and which permit
filing of related documentation in the same facility. The choice of recording/storage media should
not be a factor.
Efforts are underway to assist in documentation. These include the programming environments
as well as those similar to Tredennick and
Shimamoto of IBM. They are working to help
authors write scientific papers in an interactive
session with the computer.
They have organized a
data base that allows associative query-by-example
to provide everything from assistance with spelling
to help in finding "bigger" words to suggestions
for phrases, conjunctions, and passive-voice
sentence construction.
They are also trying to
create a template for scientific papers.
It is
envisioned that the template "will be sophisticated, with passlve-voice construction, repetition
of ideas, and other features of scientific papers.
They will lack only the nouns associated with the
topic."[17] While the specifics may be argumentative, the general "template" concept is extremely
sound.

173

[i0]

Warnier, J.-D.; GUIDE DES UTILISATEURS DU

SYSTEME INFORMATIQUE, Paris: Les Editions
Informatiques, 1980.

[ii]

Warnier, J.-D.; L'ORGANIZATION DES DONNES DUN

SYSTEME, Paris: Les Editions Informatiques,
1974.

[12]

Wilson, M.; A SEMANTICS-BASED REQUIREMENTS AND

DESIGN METHOD, San Jose, California: IBM, 1979.

[13]

Berkowitz, M. R.; "Structured design and

structured data bases: A comparison,"
PROCEEDINGS OF THE 1980 ANNUAL CONFERENCE,
ACM, October 1980.

[14]

Flavin, Matt'; "Information modeling,"

YOURDON, Inc., May 1980.

[15]

Molina, F. W.; "A practical data base design

method," DATA BASE, ii, l(Summer 1979), 3-11.

[16]

Teorey, T. J. and Fry, J. P.; "The logical

record access approach to database design,"
COMPUTING SURVEYS, 12, l(June 1980), 179-211.

[17]

Tredennick, N. and Shimamoto, B.; "On systematic generation of scientific papers,"

COMPUTER, 14, 5(May 1981), 102-105.