% >From make@hulk.hut.fi  Thu Apr 18 11:38:05 1991
% Return-Path: <make@hulk.hut.fi>
% Received: from santra by ngs.fi (5.61++/SMI-4.0)
% 	id AA01461; Thu, 18 Apr 91 11:38:05 +0300
% From: <make@hulk.hut.fi>
% Received: from hulk.hut.fi by santra.hut.fi
% 	(5.65+/8.0/TeKoLa) id AA07646; Thu, 18 Apr 91 11:39:53 +0300
% Received: by hulk.hut.fi (5.61++/6.8/S-TeKoLa)
% 	id AA27681; Thu, 18 Apr 91 11:39:36 +0300
% Message-Id: <9104180839.AA27681@hulk.hut.fi>
% Subject: Here is my written work!
% To: Pekka.Nikander@ngs.uucp
% Date: Thu, 18 Apr 91 11:39:34 EET DST
% X-Mailer: ELM [version 2.3 PL0]

\chapter{A Generic View of Software Engineering}
\author{Marko Nieminen}

\section{History of programming}

In the history of the electronic digital computer, the 1950s and 1960s
were the decades of hardware.  The 1970s were a period of transition
and a time of recognition of software.  The 1980s was the first pure
decade of software.  In fact, advances in computing may become limited
by our inability to produce quality software that can use the enormous
capacity of the 1980-era processors.

During the 1970s we recognized circumstances that are called the
software crisis.  Actually the software crisis, which was quite a big
problem, was first recognized in 1968 at the International Conference
on Software Engineering.  Software costs increased dramatically,
becoming the largest item of money in many computer-based systems.
Schedules and deadlines were set, but rarely kept.  As software
systems grew larger, quality became suspect.  Persons responsible for
software development projects had limited historical data to use as
guides and less control over the course of a project.

The essence of the software crisis is that it is much more difficult
to build software systems than we think it should be.  After all,
aren't we just throwing together some symbols that tell our computer
what to do?  Experience shows us that the world is much more complex
than that.

In computer science education, we can build systems consisting of
several hundred or even a couple of thousand lines of code and then
feel confident that we fully understand the entire program.  Modifying
such software is not very difficult, since we can remember the
structure of its design for many days after completing our first
version.  If our testing finds problems, we could even start over
again.  However, when we are dealing with software consisting of
several hundreds of thousands of lines of code it is self evident that
we cannot restart our project.  The effort required to complete such a
job is clearly beyond the capacity of one person.  So we need other
people to work with us.This brings other difficulties, such as
communication problems between the members of our team etc.

The software crisis will not disappear overnight.  Recognizing
problems and their causes are the first steps toward solutions.  Then,
the solutions themselves must provide practical assistance to the
software developer, im\-prove software quality, and finally, allow the
software world to keep pace with the hardware world.

There is no single best approach to a solution for the software
crisis.  However, by combining comprehensive methods for all phases in
software development: better tools for automating these methods, more
powerful building blocks for software implementation, better
techniques for software quality assurance, and an overriding
philosophy for coordination, control, and management, we can achieve a
discipline for software development --- a discipline called software
engineering.

\section{A definition for software engineering}

An early definition of software engineering was proposed at the first
major conference dedicated to the subject:
\begin{quote}
	The establishment and use of sound engineering principles in
	order to obtain economically software that is reliable and
	works efficiently on real machines.
\end{quote}

Although many other definitions have been proposed, all state that
engineering discipline in software development is very important.
Software engineering is an outgrowth of hardware and system
engineering.  It encompasses a set of three key elements --- methods,
tools, and procedures --- that enable the manager to control the process
of software development.

Software engineering methods provide the technical knowledge for
building software.  Methods consist of tasks that include: project
planning and estimation, system and software requirements analysis,
design of a data structure, program architecture, and algorithm
procedure (coding, testing, and maintenance). Methods for software
engineering often introduce a special language-oriented or graphical
notation and a set of criteria for software quality.

Software engineering tools provide automated or semi-automated support
for methods.  When tools are integrated so that information created by
one tool can be used by another, a system for the support of software
development, called computer-aided software engineering (CASE), is
established.  CASE combines software, hardware, and a software
engineering data base to create a software engineering environment.

Software engineering procedures are the glue that holds the methods
and tools together and enables rational development of computer
software.  Procedures define the sequence in which methods will be
applied, the deliverables that are required, the controls that help
assure quality and coordinate change, and milestones that enable
software managers to assess progress.

\section{The phases of software engineering}

The software development process contains three generic phases.  The
three phases, definition, development, and maintenance, are
encountered in all software development, regardless of application
area, project size, or complexity.

The definition phase focuses on {\it what}. That is, during definition,
the software developer attempts to identify what information is to be
processed, what functions and performance are desired, what interfaces
are to be established, what design constraints exist, and what
validation criteria are required to define a successful system.  Thus
the key requirements of the system and the software are identified.

The development phase focuses on {\it how}. That is, during development,
the software developer attempts to describe how data structure and
software architecture are to be designed, how procedural details are
to be implemented, how the design will be translated into a
programming language, and how testing will be performed.

The maintenance phase focuses on {\it change} that is associated with
error correction, adaptations required as the software's environment
evolves, and modifications due to enhancements brought about by
changing customer requirements.  The maintenance phase reapplies the
steps of the definition and development phases, but does so in the
context of existing software.

\section*{Glossary}

\begin{tabular}{ll}
to keep pace with		&	saavuttaa			\\
comprehensive			&	laaja, kattava, monipuolinen	\\
outgrowth			&	syy, seuraus			\\
encompass			&	yhdist\"a\"a			\\
establish			&	perustaa			\\
assess				&	arvioida, m\"a\"ar\"at\"a, vahvistaa\\
\end{tabular}

\section*{References}

{\parindent=0pt\parskip=3pt
Booch, G., {\it Software Engineering with Ada}, The Benjamin/Cummings
Publishing Company, 1986, second edition.

Pressman, R.  S., {\it Software Engineering: A Practitioner's Approach},
McGraw-Hill Book Company, 1987, second editiond.
}
