Modern Software

Engineering Concepts and

Practices:
Advanced Approaches

Ali H. Doğru
Middle East Technical University, Turkey

Veli Biçer
FZI Research Center for Information Technology, Germany

InformatIon scIence reference

Hershey • New York
Senior Editorial Director: Kristin Klinger
Director of Book Publications: Julia Mosemann
Editorial Director: Lindsay Johnston
Acquisitions Editor: Erika Carter
Development Editor: Joel Gamon
Production Coordinator: Jamie Snavely
Typesetters: Keith Glazewski & Natalie Pronio
Cover Design: Nick Newcomer

Published in the United States of America by

Information Science Reference (an imprint of IGI Global)
701 E. Chocolate Avenue
Hershey PA 17033
Tel: 717-533-8845
Fax: 717-533-8661
E-mail: [email protected]
Web site: http://www.igi-global.com

Copyright © 2011 by IGI Global. All rights reserved. No part of this publication may be reproduced, stored or distributed in
any form or by any means, electronic or mechanical, including photocopying, without written permission from the publisher.
Product or company names used in this set are for identification purposes only. Inclusion of the names of the products or com-
panies does not indicate a claim of ownership by IGI Global of the trademark or registered trademark.

Library of Congress Cataloging-in-Publication Data

Modern software engineering concepts and practices : advanced approaches / Ali

H. Doğru and Veli Biçer, editors.
p. cm.
Includes bibliographical references and index.
Summary: "This book provides emerging theoretical approaches and their
practices and includes case studies and real-world practices within a range of
advanced approaches to reflect various perspectives in the discipline"--
Provided by publisher.
ISBN 978-1-60960-215-4 (hardcover) -- ISBN 978-1-60960-217-8 (ebook) 1.
Software engineering. I. Doğru, Ali H., 1957- II. Biçer, Veli, 1980-
QA76.758.M62 2011
005.1--dc22
2010051808

British Cataloguing in Publication Data

A Cataloguing in Publication record for this book is available from the British Library.

All work contributed to this book is new, previously-unpublished material. The views expressed in this book are those of the
authors, but not necessarily of the publisher.
 1

Chapter 1
A Comparative Analysis
of Software Engineering
with Mature Engineering
Disciplines Using a Problem-
Solving Perspective
Bedir Tekinerdogan
Bilkent University, Turkey

Mehmet Aksit
University of Twente, The Netherlands

ABSTRACT
Software engineering is compared with traditional engineering disciplines using a domain specific
problem-solving model called Problem-Solving for Engineering Model (PSEM). The comparative analy-
sis is performed both from a historical and contemporary view. The historical view provides lessons on
the evolution of problem-solving and the maturity of an engineering discipline. The contemporary view
provides the current state of engineering disciplines and shows to what extent software development can
actually be categorized as an engineering discipline. The results from the comparative analysis show
that like mature engineering, software engineering also seems to follow the same path of evolution of
problem-solving concepts, but despite promising advances it has not reached yet the level of mature
engineering yet. The comparative analysis offers the necessary guidelines for improving software engi-
neering to become a professional mature engineering discipline.

INTRODUCTION software engineering is. It is assumed that finding

the right answer to this question will help to cope
Since the early history of software development, with the software crisis, that is, software delivered
there is an ongoing debate what the nature of too late, with low quality and over budget (Press-
man, 2008; Sommerville, 2007). The underlying
DOI: 10.4018/978-1-60960-215-4.ch001 idea behind this quest is that a particular view

Copyright © 2011, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.
 A Comparative Analysis of Software Engineering with Mature Engineering Disciplines

on software development directly has an impact have first to understand problem-solving better.
on the software process and artifacts. Several Problem solving has been extensively studied in
researchers fairly stated that in addition to the cognitive sciences such as (Newell et al., 1976;
question what software development currently Smith et al., 1993; Rubinstein et al., 1980) and
is, we should also investigate what professional different models have been developed that mainly
software development should be. The latter ques- address the cognitive human problem solving
tion acknowledges that current practices can be activity. In this paper we provide the Problem
unprofessional and awkward and might require Solving for Engineering Model (PSEM), which
more effort and time to maturate. Although both is a domain-specific problem solving model for
the questions on what software development is engineering. This PSEM will be validated against
and what professional software development the mature engineering disciplines such as civil
should be are crucial, it seems that there are still engineering, electrical engineering and mechani-
no definite answers yet and the debate is con- cal engineering. From literature (Ertas et al., 1996;
tinuing from time to time after regular periods Ghezzi et al., 1991; Wilcox et al., 1990; Shaw et
of silence. Some researchers might consider this al., 1990) it follows that engineering essentially
just as an academic exercise. Yet, continuing the aims to provide an engineering solution for a
quest for a valid view of software development given problem, and as such, can be considered as
and a common agreement on this is important for a problem solving process. We could further state
a profound understanding, of the problems that that mature engineering disciplines are generally
we are facing with, and the steps that we need to successful in producing quality products and adopt
take to enhance software development. likewise a mature problem-solving approach. Ana-
The significant problems we may face, though, lyzing how mature engineering disciplines solve
seem not to be easily solved at the level as they their problems might provide useful lessons for
are analyzed in current debates. To be able to pro- acquiring a better view on what software develop-
vide both an appropriate answer to what software ment is, that has not yet achieved a maturity level.
engineering is, and what it should be, we must Hence, we have carried out an in-depth compara-
shift to an even higher abstraction level than the tive analysis of mature engineering with software
usual traditional debates. This view should be engineering using the PSEM. In principle, every
generally recognized, easy to understand and to discipline can be said to have been immature in
validate and as such provide an objective basis the beginning, and evolved later in time. Mature
to identify the right conclusions. We think that engineering disciplines have a relatively longer
adopting a problem solving perspective provides history than software engineering so that the vari-
us an objective basis for our quest to have a pro- ous problem solving concepts have evolved and
found understanding of software development. matured over a much longer time. Studying the
Problem-solving seems to be ubiquitous that it history of these mature disciplines will justify the
can be applied to almost any and if not, accord- problem-solving model and allow deriving the
ing to Karl Popper (2001), to all human activi- concepts of value for current software engineering
ties, software development included. But what practices. Hence, our comparative study considers
is problem-solving actually? What is the state of both the current state and the history of software
software development from a problem-solving development and mature engineering disciplines.
perspective? What needs to be done to enhance it Altogether, we think that this study is beneficial
to a mature problem solving discipline? In order in at least from the following two perspectives.
to reason about these questions and the degree First, an analysis of software engineering from
of problem-solving in software development we a problem-solving perspective will provide an

2
A Comparative Analysis of Software Engineering with Mature Engineering Disciplines

innovative and refreshing view on the current the various problem-solving models. While there
analysis and debates on software development. In are many models of problem-solving, none has
some perspectives it might be complementary to been explicitly developed to describe the overall
existing analyses on software development, and process of engineering and/or compare engineer-
in addition since problem-solving is at a higher ing disciplines in particular. There have been
abstraction level it might also highlight issues problem-solving models for representing design
that were not identified or could not have been as problem-solving (Braha et al., 1997), but no
identified before due to the limitations of the ad- broad general model has been proposed yet which
opted models for comparison. Second, the study encompasses the overall engineering process.
on mature engineering disciplines will reveal the A common model that represents engineering
required lessons for making an engineering dis- from a problem-solving will specifically show the
cipline mature. The historical analysis of mature important features of engineering. In this context,
engineering will show how these engineering we could come up with a very abstract model for
disciplined have evolved. The analysis on the problem-solving consisting essentially of two
current practices in these mature engineering concepts: Need and Artifact. Given a particular
disciplines will show the latest success factors of need (Problem) an artifact (Solution) must be
mature engineering. We could apply these lessons provided that satisfies the need. Because of its
to software engineering to enhance it to a mature very abstract nature, all engineering disciplines,
problem solving, and thus a mature engineering including software engineering, apply to this
discipline. In short, this study will help us to show overly simple model. Of course, the counterpart
what software development currently is, and what of the abstract nature of the model is that it is less
professional software development should be. useful in identifying the differences between the
The remainder of this paper is organized existing engineering disciplines and for compar-
as follows: The second section presents the ing these. Hence, we are interested in a concrete
problem-solving for engineering model (PSEM). problem-solving model that describes the separate
The model defines the fundamental concepts of important concepts needed for understanding and
problem-solving and as such allows to explicitly expressing the concepts of engineering. To this
reason about these concepts. In the third section, aim, we propose the domain specific Problem-
we use the PSEM to describe the history of ma- Solving for Engineering Model (PSEM), which
ture engineering. The fourth section reflects on is illustrated in Figure 1. In the subsequent sec-
the history of software engineering based on the tions, PSEM will serve as an objective basis for
PSEM model and compares software engineer- comparing engineering disciplines.
ing with mature engineering. In the fifth section, This domain specific model has been developed
we provide a discussion and the comparison of after a thorough literature study on both problem-
software engineering with mature engineering. solving and mature disciplines. In addition to the
The sixth section presents the related work and before mentioned problem-solving literature, we
finally the last section presents the conclusions. have studied selected handbooks including
chemical engineering handbook (Perry, 1984),
mechanical engineering handbook (Marks, 1987),
PROBLEM-SOLVING FOR electrical engineering handbook (Dorf, 1997) and
ENGINEEING MODEL civil engineering handbook (Chen, 1998). Further
we have studied several textbooks on the corre-
Several survey papers (Deek et al., 1999; Rubin- sponding engineering methodologies of me-
stein et al., 1980) represent a detailed analysis on chanical engineering and civil engineering (Cross,

3
 A Comparative Analysis of Software Engineering with Mature Engineering Disciplines

Figure 1. Problem-solving for engineering model (PSEM)

1989; Dunsheath, 1997; Shapiro, 1997), electrical • Need represents an unsatisfied situation
engineering (Wilcox et al., 1990) and chemical existing in the context. The function Input
engineering (Biegler, 1997). represents the cause of a need.
The model is based on UML statecharts and • Problem Description represents the de-
consists of a set of states and transitions among scription of the problem. The function
these states. The states represent important con- Conceive is the process of understanding
cepts, the transitions represent the corresponding what the need is and expressing it in terms
functions among these concepts. Concepts are of the concept Problem Description.
represented by means of rounded rectangles, • Solution Domain Knowledge represents
functions by directed arrows. The model consists the background information that is used
of three fundamental parts: Problem- Solving, to solve the problem. The function Search
Control and Context. In the following, we will represents the process of finding the rel-
explain these parts in more detail. evant background information that corre-
sponds to the problem.
Problem-Solving • Alternative, represents the possible alter-
native solutions. The function Generate
The problem-solving part consists of six concepts: serves for the generation of different alter-
Need, Problem Description, Solution Domain natives from the solution domain knowl-
Knowledge, Alternative, Solution Description edge. After alternatives have been generat-
and Artifact. ed, the problem description can be refined
using the function Refine. The function
Detail is used to detail the description of a
selected alternative.

4
A Comparative Analysis of Software Engineering with Mature Engineering Disciplines

• Solution Description represents a feasible the right alternative or optimizes a given

solution for the given problem. alternative to meet the criteria and the
• Artifact represents the solution for the constraints.
given need. The function Implement maps
the solution description to an artifact. The Context
function Output represents the delivery
and impact of the concept Artifact to the Both the control and the problem-solving activi-
context. The function Initiate represents ties take place in a particular context, which is
the cause of a new need because of the pro- represented by the outer rounded rectangle in
duced artifact. Figure 1. Context can be expressed as the environ-
ment in which engineering takes place including
Control a broad set of external constraints that influence
the final solution and the approach to the solution.
Problem-solving in engineering starts with the Constraints are the standards, the rules, require-
need and the goal is to arrive at an artifact by ap- ments, relations, conventions, and principles that
plying a sequence of actions. Since this may be a define the context of engineering (Newell et al.,
complex process, the concepts and functions that 1976), that is, anything, which limit the final
are applied are usually controlled. This is repre- solution. Since constraints rule out alternative
sented by the Control part in the model. A control design solutions they direct engineer’s action
system consists of a controlled system and a con- to what is doable and feasible. The context also
troller (Foerster, 1979). The controller observes defines the need, which is illustrated in Figure 1
variables from the controlled system, evaluates by a directed arrow from the context to the need
this against the criteria and constraints, produces concept. Apparently, the context may be very wide
the difference, and performs some control ac- and include different aspects like the engineer’s
tions to meet the criteria. In PSEM, the control experience and profession, culture, history, and
part consists of four concepts: Representation of environment (Rubinstein et al., 1980).
Concern, Criteria, and Adapter.

• (Mathematical) Model represents a de- HISTORICAL PERSPECTIVE

scription of the concept Alternative. The OF PROBLEM-SOLVING IN
function Analyse represents the process of MATURE ENGINEERING
analyzing the alternative.
• (Quality) Criteria represent the relevant In the following, we will explain PSEM from an
criteria that need to be met for the final engineering perspective and show how the con-
artifact. The function Evaluate assesses cepts and functions in the model have evolved
the alternative with respect to (Quality) in history in the various engineering disciplines.
Criteria and Constraints. While describing the historical developments we
• Constraints represent the possible con- will indicate the related concepts of PSEM in italic
straints either from the context or as de- format in the corresponding sentences.
scribed in Problem Statement.
• Heuristics/Optimization Techniques rep- Directly Mapping Needs to Artifacts
resents the information for finding the
necessary actions to meet the criteria and Engineering deals with the production of arti-
constraints. The function Select selects facts for practical purposes. Production in the

5
 A Comparative Analysis of Software Engineering with Mature Engineering Disciplines

early societies was basically done by hand and sible to produce an artifact by a single person.
therefore they are also called craft-based societies Moreover, when many craftsmen were involved
(Jones et al., 1992). Thereby, usually craftsmen in the production, communication about the
do not and often cannot, externalize their works production process and the final artifact became
in descriptive representations (Solution Descrip- important. A reflection on this process required
tion) and there is no prior activity of describing a fundamental change in engineering problem-
the solution like drawing or modeling before the solving. This initiated, especially in architecture,
production of the artifact. Further, these early the necessity for drafting or designing (Solution
practitioners had almost no knowledge of science Description), whereby the artifact is represented
(Solution Domain Knowledge), since there was through a drawing before the actual production.
no scientific knowledge established according Through drafting, engineers could communicate
to today’s understandings. The production of about the production of the artifact, evaluate the
the artifacts is basically controlled by tradition, artifact before production and use the drafting or
which is characterized by myth, legends, rituals design as a guide for production. This enlightened
and taboos and therefore no adequate reasons for the complexity of the engineering problems sub-
many of the engineering decisions can be given. stantially. Currently, drafting plays an important
The available knowledge related with the craft role in all engineering disciplines. At this phase of
process was stored in the artifact itself and in the engineering, the concepts of Problem Description
minds of the craftsman, which transmitted this and Solution Description became explicit.
to successors during apprenticeship. There was
little innovation and the form of a craft product Development of Solution
gradually evolved only after a process of trial and Domain Knowledge
error, heavily relying on the previous version of
the product. The form of the artifact was only Obviously classical engineers were restricted in
changed to correct errors or to meet new require- their accomplishments when scientific knowledge
ments, that is, if it is necessary. To sum up, we can was lacking. Over time, scientific knowledge
conclude that most of the concepts and functions gradually evolved while forming the basis for
of the problem-solving part in PSEM were implicit the introduction of new engineering disciplines.
in the approach, that is, there was almost a direct New advancements in physics and mathematics
mapping from the need to the artifact. Regarding were made in the 17th century (Solution Domain
the control part, the trial-and-error approach of Knowledge). Newton, for example, generalized
the early engineers can be considered as a simple the concept of force and formulated the concept
control action. of mass forming the basics of mechanical engi-
neering. Evolved from algebra, arithmetic, and
Separation of Solution geometry, calculus was invented in the 17th cen-
Description from Artifacts tury by Newton and Leibniz. Calculus concerns
the study of such concepts as the rate of change
From history, we can derive that the engineering of one variable quantity with respect to another
process matured gradually and became neces- and the identification of optimal values, which
sarily conscious with the changing context. It is is fundamental for quality control and optimiza-
hard to pinpoint the exact historical periods but tion in engineering. The vastly increased use of
over time, the size and the complexity of the arti- scientific principles to the solution of practical
facts exceeded the cognitive capacity of a single problems and the past experimental experiences
craftsman and it became very hard if not impos- increasingly resulted in the production of new

6
A Comparative Analysis of Software Engineering with Mature Engineering Disciplines

types of artifacts. The steam engine, developed in Contemporary Perspective

1769, initiated the beginnings of the first Indus- of Problem-Solving in
trial Revolution that implied the transition from Mature Engineering
an agriculture-based economy to an industrial
economy in Britain. In newly developed factories, If we consider contemporary approaches in mature
products were produced in a faster and more ef- engineering then we can observe the following.
ficient way and the production process became First, the need concept in the PSEM plays a basic
increasingly routine and specialized. In the 20th role and as such has directed the activities of engi-
century the knowledge accumulation in various neering. In mature engineering, an explicit techni-
engineering disciplines has grown including dis- cal problem analysis phase is defined whereby the
ciplines such as biochemistry, quantum theory basic needs are mapped to the technical problems.
and relativity theory. Although initial client problems are ill-defined
(Rittel, 1984) and may include many vague re-
Development of Control quirements, the mature engineering disciplines
Concepts and Automation focus on a precise formulation of the objectives
and a quantification of the quality criteria and
Besides of evolution of the concepts of the part the constraints, resulting in a more well-defined
Problem-Solving of Figure 1 one can also observe problem statement. The criteria and constraints
the evolution of the Control concepts. Primarily, are often expressed in mathematical formulas and
mathematical modeling (Mathematical Model) equations. The quality concept is thus explicit in
seems to form a principal basis for engineering the problem description and refers to the variables
disciplines and its application can be traced back and units defined by the International Systems
in various civilizations throughout the history. The of units (SI). From the given specification the
development of mathematical modeling supported engineers can easily calculate the feasibility of
the control of the alternatives selection. Much the end-product for which different alternatives
later, this has led to automation, which is first are defined and, for example, their economical
applied in manufacture. The next step necessary cost may be calculated.
in the development of automation was mechani- Second, mature problem-solving also includes
zation that includes the application of machines a rich base of extensive scientific knowledge that
that duplicated the motions of the worker. The is utilized by a solution domain analysis phase
advantage of automation was directly observable (Arrango et al., 1994) to derive the fundamental
in the increased production efficiency. Machines solution abstractions. From our study it appears
were built with automatic-control mechanisms that that each mature engineering is based on a rich sci-
include a feedback control system providing the entific knowledge that has developed over several
capacity for self-correction. Further, the advent centuries. The corresponding knowledge has been
of the computer has greatly supported the use of compiled in several handbooks and manuals that
feedback control systems in manufacturing pro- describe numerous formulas that can be applied
cesses. In modern industrial societies, computers to solve engineering problems. The handbooks
are used to support various engineering disciplines. we studied contain a comprehensive coverage in-
Its broad application is in the support for draft- depth of the various aspects of the corresponding
ing and manufacturing, that is, computer-aided engineering field from contributions of dozens
design (CAD) and computer-aided manufactur- of top experts in the field. Using the handbook,
ing (CAM). the engineer is guided with hundreds of valuable
tables, charts, illustrations, formulas, equations,

7
 A Comparative Analysis of Software Engineering with Mature Engineering Disciplines

definitions, and appendices containing extensive Summary

conversion tables and usually sections covering
mathematics. Obviously, scientific knowledge Reflecting on the history of mature engineering
plays an important role in the degree of maturity disciplines, we can conclude that the separate
of the corresponding engineering. concepts of PSEM have evolved gradually. Tra-
Third, in mature engineering different alter- ditional engineering disciplines such as electrical
natives are explicitly searched from the solution engineering, chemical engineering and mechanical
domain and often organized with respect to pre- engineering can be considered mature because the
determined quality criteria. Hereby, the quality maturity of each concept in the PSEM.
concept plays an explicit role and the alternatives Figure 2 shows the historical snapshots from
are selected in an explicit alternative space analy- the evolution of problem-solving in PSEM. In
sis process whereby mathematical optimization section 3.1, we have seen that problem-solving
techniques such as calculus, linear programming at the early phases of the corresponding engineer-
and dynamic programming are adopted. In case ing disciplines was rather simple and consisted
no accurate formal expressions or off-the-shelf of almost directly mapping needs to artifacts. In
solutions can be found heuristic rules (Coyne et Figure 2, this is represented as time Ta. Later on,
al., 1990; Cross et al., 1989) are used. the concepts of Problem Description and Solution
In mature engineering the three processes of Description evolved (time Tb), followed by the
technical problem analysis, solution domain analy- evolutions of Solution Domain Knowledge and
sis and alternative space analysis are integrated Alternatives (Tc), and finally the control concepts
within the so-called synthesis process (Maimon (Td) leading to PSEM as presented in Figure 1.
et al., 1996; Tekinerdogan et al., 2006). In the Figure 2 is an example showing several snapshots.
synthesis process, the explicit problem analysis In essence, for every engineering discipline we
phase is followed by the search for alternatives could define the maturity degrees of the problem-
in a solution domain that are selected based on solving concepts throughout the history.
explicit quality criteria.
In the synthesis process each alternative is
analyzed through generally representing it by HISTORICAL PERSPECTIVE OF
means of mathematical modeling. A mathematical PROBLEM-SOLVING IN SOFTWARE
model is an abstract description of the artifact us- ENGINEERING
ing mathematical expressions of relevant natural
laws. One mathematical model may represent We will now describe the historical development
many alternatives. In addition different mathemati- of problem-solving in software engineering.
cal models may be needed to represent various Although, the history of software engineering
aspects of the same alternative. To select among is relatively short and ranges only about a few
the various alternatives and/or to optimize the decades, this study will illustrate the ongoing
same alternative Quality Criteria are used in the evolution of its concepts in PSEM and identify
evaluation process that can be applied by means its current maturity level with respect to mature
of heuristic rules and/or optimization techniques. engineering disciplines.
Once the ‘best’ alternative has been chosen it will
be further detailed (Detailed Solution Description) Directly Mapping Needs to Programs
and finally implemented.
Looking back at the history we can assume that
software development started with the introduction

8
A Comparative Analysis of Software Engineering with Mature Engineering Disciplines

Figure 2. Historical snapshots of the evolution of engineering problem-solving

of the first generation computers in the 1940s such processing applications in business was initiated
as the Z3 computer (1941), the Colossus computer (Need), COBOL (Common Business Oriented
(1943) and the Mark I (1945) computer (Bergin Language) was developed in 1960. In parallel
et al., 1996). The first programs were expressed with the growing range of complex problems the
in machine code and because each computer had demand for manipulation of more kinds of data
its own specific set of machine language opera- increased (Need). Later on the concept of abstract
tions, the computer was difficult to program and data types and object-oriented programming were
limited in versatility and speed and size (Need). introduced (Solution Domain Knowledge) and
This problem was solved by assembly languages. included in various programming languages such
Although there was a fundamental improvement as Simula, Smalltalk, C++, Java and C#.
over the previous situation, programming was It appears that in the early years of computer
still difficult. The first FORTRAN compiler science the basic needs did not change in variety
released by IBM in 1957 (Bergin et al., 1996) and were directly mapped to programs. We can
set up the basic architecture of the compiler. The state that there was practically no design, no ex-
ALGOL compiler (1958) provided new concepts plicit solution domain knowledge and alternative
that remain today in procedural systems: symbol analysis. In fact, this is similar to the early phases
tables, stack evaluation and garbage collection of mature engineering disciplines.
(Solution Domain Knowledge). With the advent
of the transistor (1948) and later on the IC (1958) Separation of Solution
and semiconductor technology the huge size, the Descriptions from Programs
energy-consumption as well as the price of the
computers relative to computing power shrank The available programming languages that ad-
tremendously (Context). The introduction of opted algorithmic abstraction and decomposition
high-level programming languages made the have supported the introduction of many structured
computer more interesting for cost effective and design methods (DeMarco, 1978; Jackson, 1975;
productive business use. When the need for data Yourdon, 1979) during the 1970s, including differ-

9
 A Comparative Analysis of Software Engineering with Mature Engineering Disciplines

ent design notations to cope with the complexity variety of algorithms and the analysis of them
of the development of large software systems. (1967). Wirth introduced the concept of stepwise
At the start of the 1990s several object-oriented refinement (1971) of program construction and
analysis and design methods were introduced developed the teaching procedural language Pascal
(Booch, 1991; Coad et al., 1991) to fit the exist- for this purpose. Dijkstra introduced the concept
ing object-oriented language abstractions and of structured programming (1969). Parnas (1972)
new object-oriented notations were introduced. addressed the concepts of information hiding and
CASE tools were introduced in the mid 1980s to modules.
provide automated support for structured software The software engineering body of knowledge
development methods (Chikofsky, 1998). This has evolved in the last four decades (SWEBOK,
had been made economically feasible through the 2004). This seems relatively short with respect
development of graphically oriented computers. to the scientific knowledge base of mature engi-
Inspired from architecture design (Alexander, neering. Nevertheless, there is now an increasing
1977) design patterns (Gamma et al., 1995) have consensus that the body of knowledge is large and
been introduced as a way to cope with recurring mature enough to support engineering activities.
design problems in a systematic way. Software The IEEE Computer Society and the Association
architectures (Shaw et al., 1996) have been intro- for Computing Machinery (ACM) have set up
duced to approach software development from the a joint project in which the so-called Software
overall system structure. The need for systematic Engineering Body of Knowledge is developed
industrialization (Need) of software development (Bourque et al., 1999; SWEBOK, 2004) to char-
has led to component-based software develop- acterize and organize the contents of the software
ment (Solution Description) that aims to produce engineering discipline.
software from pre-built components (Szyperski,
1998). With the increasing heterogeneity of soft- Development of Control
ware applications and the need for interoperability, Concepts and Automation
standardization became an important topic. This
has resulted in several industrial standards like The Control concepts have evolved in software
CORBA, COM/OLE and SOM/OpenDoc. The engineering as well. Over the decades more and
Unified Modeling Language (UML) (Rumbaugh better case tools have been developed supporting
et al., 1998) has been introduced for standardiza- software development activities ranging from
tion of object-oriented design models. architecture design to testing and software project
management.
Development of Computer Mathematical modeling (Mathematical Model)
Science Knowledge and/or algebraic modeling is more and more in-
tegrated in software design. Empirical software
The software engineering community has ob- engineering aims to devise experiments on soft-
served an emerging development of the solution ware, in collecting data from the experiments,
domain knowledge (Solution Domain Knowl- and in devising laws and theories from this data
edge). Simultaneously with the developments of (Juristo et al., 2001). To analyze software systems,
programming languages, a theoretical basis for metrics are being developed and tested (Fenton
these was developed by Noam Chomsky (1965) et al., 1997).
and others in the form of generative grammar Process improvement approaches such as, for
models (Solution Domain Knowledge). Knuth example, the Capability Maturity Model Integra-
presented a comprehensive overview of a wide tion (CMMI) is proposed and applied (Boehm

10
A Comparative Analysis of Software Engineering with Mature Engineering Disciplines

et al., 2003). In parallel to these plan-based ap- or the performance. Of course, the importance of
proaches agile software development has been requirements engineering has seriously changed
advocated as an appropriate lightweight approach over the last decade. There is an IEEE conference
for high-speed and volatile software development on Requirements Engineering, which has been
(Boehm et al., 2003). running successfully since 1993, a Requirements
Currently the so-called model-driven software Engineering journal, several serious textbooks on
development (MDSD) aims to support the automa- requirements engineering and a lot of research,
tion of software development (Stahl et al., 2006). which deals with both formalizing and measur-
Unlike conventional software development, mod- ing functional and non-functional requirements.
els in MDSD do not constitute mere documentation Although we can observe substantial progress in
but are considered executable similar to code. this community it is generally acknowledged that
MDE aims to utilize domain-specific languages the aimed state of mature engineering is unfortu-
to create models that express application structure nately not reached yet.
and behavior in a more efficient way. The models A similar development can be observed for the
are then (semi)automatically transformed into organization and the use of knowledge for software
executable code by model transformations. engineering. The field of software engineering is
The above developments are basically related only about 50 to 60 years old and obviously is not
to the enhancement of control in software engi- as mature as in the traditional engineering disci-
neering. Although this has not yet completed we plines. The basic scientific knowledge, on which
can state that it follows similar path as in mature software engineering relies, is mainly computer
engineering. science that has developed over the last decades.
Progress is largely made in isolated parts, such as
Contemporary Perspective algorithms and abstract data types (Shaw, 1990;
of Problem-Solving in Shaw et al., 1996).
Software Engineering One of the interesting developments is the
increasing size of pattern knowledge. The goal of
We have analyzed a selected set of textbooks patterns is to create a body of literature, similar
on software engineering (Ghezzi et al., 2002; to the mature engineering disciplines, to help
Pressman, 2004; Sommerville, 2007). In software software developers resolve common difficult
engineering, the phase for conceiving the needs is problems encountered throughout all of software
referred to as requirements analysis, which usually engineering and development. Several books have
is started through an initial requirement specifica- been written including many useful patterns to
tion of the client. In mature engineering we have support to design and implementation. Never-
seen that the quality concept is already explicit theless, if we relate the quantity of knowledge to
in the problem description through the quantified the supporting knowledge of mature engineering
objectives of the client. In software engineering disciplines, the available knowledge in software
this is quite different. In contrast to mature engi- engineering is still quite meager. The available
neering disciplines, however, constraints and the handbooks of software engineering (Ghezzi et al.,
requirements are usually not expressed in quanti- 2002; Pressman, 2004; Sommerville, 2007) are
fied terms. Rather the quality concern is mostly im- still not comparable to the standard handbooks
plicit in the problem statement and includes terms of mature engineering disciplines. Moreover, on
such as ‘the system must be adaptable’ or ‘system many fundamental concepts in software engineer-
must perform well’ without having any means to ing consensus among experts has still not been
specify the required degree of adaptability and/ reached yet and research is ongoing.

11
 A Comparative Analysis of Software Engineering with Mature Engineering Disciplines

In other engineering disciplines at phases when ing, Chemical Engineering, Electrical Engineer-
knowledge was lacking we observe that the basic ing,....}.” Others argue that software engineering
attitude towards solving a problem was based on is not an engineering discipline, but that it should
common sense, ingenuity and trial-and-error. In be (McConnell, 2003). Again others claim that
software engineering it turns out that this was software is fundamentally different from other
not much different and the general idea was that engineering artifacts and as such can and should
requirements have to be specified using some not be considered as an engineering discipline.
representation and this should be refined along Based on our historical analysis we argue that
the software development process until the final currently software engineering shows the charac-
software is delivered. teristics of an engineering discipline, but has not
Regarding alternative space analysis we can evolved yet to the maturity level of the traditional
state that the concept of Alternative(s), is not engineering disciplines. If we would characterize
explicit in software engineering. The selection the current state of software engineering based on
and evaluation of design alternatives in mature Figure 2, then it would be somewhere between
engineering disciplines is based on quantitative Tb and Tc. Obviously it is not possible to define
analysis through optimization theory of math- the exact characterization in terms of crisp values
ematics. This is not common practice in software simply because each concept in the PSEM might
engineering. No single method we have studied have a maturity degree of progress that cannot be
applies mathematical optimization techniques to expressed as yes or no. Table 1 presents an analyti-
generate and evaluate alternative solutions. Cur- cal overview in which the different properties of
rently, the notion of quality in software engineering both software engineering and mature engineer-
has more an informal basis. There is however, a ing are shown. The properties (left column) are
broad agreement that quality should be taken into derived from the PSEM. For each property, we
account when deriving solutions. As in other en- have provided a short explanation derived from
gineering disciplines, in software engineering the our analysis as described in the previous sec-
quality concept is closely related to measurement, tions. Based on this we can identify the concrete
which is concerned with capturing information differences of software engineering with mature
about attributes of entities (Fenton et al., 1997). engineering and are better able to pinpoint what
needs more focus to increase the maturity level
of software engineering.
DISCUSSION In the coming years we expect that each of
these concepts will further evolve towards a ma-
Since the introduction of the term software engi- ture level. This can be observed if we consider
neering in 1968 the NATO Software Engineering the current trends in software development in
Conference, there has been many debates on the which the concepts are developing in a relatively
question whether software development is an engi- high pace. By looking at the concepts in Table 1
neering discipline or not. We can identify different we can give several examples in this perspective.
opinions in this perspective. Some authors view For example, Michael Jackson (2000) provides
software engineering as a branch of traditional in his work on so-called problem-frames an explicit
engineering often believe that concepts from notion of problem in requirements engineering.
traditional engineering need to apply to software In the aspect-oriented software development
development. For example, Parnas (1998) argued community the notion of concern has been in-
that software engineering is a “an element of the troduced and several approaches are proposed to
set, {Civil Engineering, Mechanical Engineer- identify, specify and compose concerns (Filman

12
A Comparative Analysis of Software Engineering with Mature Engineering Disciplines

Table 1. Comparison of mature engineering with software engineering

Mature Engineering Software Engineering

Technical Explicit problem description specified with quantified Usually implicitly defined as part of the requirements
Problem Analysis metrics. Well-defined problems. and usually no quantification of required solution.
Ill-defined problems.
Availability of Domain Very extensive solution domain knowledge compiled Basically knowledge for isolated domains in computer
Knowledge in different handbooks. science. Increasing number of pattern catalogs
Application of Domain Explicit domain analysis process for deriving abstrac- Solution domain analysis not a common practice. In
Knowledge tions from solution domain. general applied in case reuse is required.
Solution Description Rich set of notations for different problems. Various design notations. Still lack of global standards.
Alternative Analysis Explicit alternative space analysis; optimization tech- Implicit. Almost no systematic support for alternative
niques for defining the feasible alternatives space analysis.
Quality Explicit quality concerns both for development and Quality is usually implicit. No systematic support
Measurement evaluation. for measuring quality in common software practices
Application of Heuristics Explicitly specified in handbooks as a complemen- Implicit in software development methods.
tary means to mathematical techniques for defining
feasible solutions.

et al., 2004). In a sense, concerns can be viewed continuous evolution of design notations and the
as similar to the notion of technical problem that related tools (Budgen, 2003).
we have defined in this paper. Alternative analysis is not really explicitly
The organization and modeling of domain addressed but there are several trends that show
knowledge has been addressed, for example, in directions towards this goal. In software product
SWEBOK (2004) and other work on taxonomies line engineering variability analysis is an important
(Glass et al., 1995). In parallel with this we can topic and the process for application engineering
see the increasing number of publication of dif- is applied to develop different alternative products
ferent pattern catalogs for various phases of the from a reusable asset base (Clements et al., 2002).
software life cycle. Also we observe that textbooks The case of quality measurement has been explic-
on software engineering provide a broader and itly proposed in the work on software measurement
more in-depth analysis of software engineering and experimentation (Fenton et al., 1997).
and related concepts, which is reflected by the
large size of the volumes.
The application of domain knowledge to derive RELATED WORK
the abstractions for software design is represented
in the so-called domain analysis process that Several publications have been written on software
was first introduced in the reuse community and engineering and the software crisis. Very often
software product line engineering (Clements et software engineering is considered fundamentally
al., 2002). Currently we see that it is also being different from traditional engineering and it is
gradually integrated in conventional software claimed that it has particular and inherent com-
design methods, which are indicating on the use plexities that are not present in other traditional
of domain-driven approaches (Evans, 2004). engineering disciplines. The common cited causes
Regarding design notations we can state that of the software crisis are the complexity of the
the software engineering community is facing a problem domain, the changeability of software, the
invisibility of software and the fact that software

13
 A Comparative Analysis of Software Engineering with Mature Engineering Disciplines

does not wear out like physical artifacts (Booch, which she describes as follows: “Historically,
1991; Budgen, 2003; Pressman, 2004). Most of engineering has emerged from ad hoc practice
these studies, however, lack to view software in two stages: First, management and production
engineering from a broader perspective and do techniques enable routine production. Later, the
not attempt to derive lessons from other mature problems of routine production stimulate the
engineering disciplines. development of a supporting science; the mature
We have applied the PSEM for describing science eventually merges with established prac-
problem-solving from a historical perspective. tice to yield professional engineering practice”.
Several publications consider the history of com- Using her model, she compares civil engineering
puter science providing a useful factual overview and chemical engineering and concludes that these
of the main events in the history of computer sci- engineering disciplines have matured because of
ence and software engineering. The paper from, the supporting science that has evolved. Shaw
for example, Shapiro (1997) provides a very nice distinguishes between craft, commercial and
historical overview of the different approaches in professional engineering processes. These distinct
software engineering that have been adopted to engineering states can be each expressed as a dif-
solve the software crisis. Shapiro maintains that ferent instantiation of the PSEM. The immature
due to the inherently complex problem-solving craft engineering process will lack some of the
process and the multifaceted nature of software concepts as described by the PSEM. The mature
problems from history it follows that a single professional engineering process will include all
approach could not fully satisfy the fundamental the concepts of the PSEM.
needs and a more pluralistic approach is rather Several authors criticize the lack of well-
required. designed experiments for measurement-based
Some publications claim in accordance with assessment in software engineering (Fenton et
the fundamental thesis of this paper that lessons al., 1997). They state that currently the evalua-
of value can be derived from other mature engi- tion of software engineering practices depend on
neering disciplines. Petroski (1992) claims that opinions and speculations rather than on rigorous
lessons learned from failures can substantially software-engineering experiments. To compare
advance engineering. Baber (1997) compares the and improve software practices they argue that
history of electrical engineering with the history there is an urgent need for quantified measure-
of software engineering and thereby focuses on ment techniques as it is common in the traditional
the failures in both engineering disciplines. Ac- scientific methods. In the PSEM measurement
cording to Baber software development today is and evaluation is represented by the control part.
in a pre-mature phase analogous in many respects As we have described before, mature engineering
to the pre-mature phases of the now traditional disciplines have explicit control concepts. The
engineering discipline that had also to cope with lack of these concepts in software engineering
numerous failures. Baber states that the fundamen- indicates its immature level.
tal causes of the failures in software development
today are the same as the causes of the failures in
electrical engineering 100 years ago, that is, lack CONCLUSION
of scientific mathematical knowledge or the failure
to apply whatever such basis may exist. This is Software engineering is in essence a problem-
in alignment with our conclusions. Shaw (1990) solving process and to understand software
provides similar conclusions. She presents a model engineering it is necessary to understand problem-
for the evolution of an engineering discipline, solving. To grasp the essence of problem-solving

14
A Comparative Analysis of Software Engineering with Mature Engineering Disciplines

we have provided an in-depth analysis of the REFERENCES

history of problem-solving in mature engineering
and software engineering. This has enabled us to Alexander, C., Ishikawa, S., Silverstein, M., Jacob-
position the software engineering discipline and son, M., Fiksdahl-King, I., & Angel, S. (1977). A
validate its maturity level. To explicitly reason pattern language: Towns, buildings, construction.
about the various problem-solving concepts in New York: Oxford University Press.
engineering, in section 2 we have presented the Arrango, G. (1994). Domain analysis methods.
Problem-solving for Engineering Model (PSEM) In Schäfer, R., Prieto-Díaz, R., & Matsumoto,
that uniquely integrates the concepts of problem- M. (Eds.), Software reusability. Ellis Horwood.
solving, control and context. It appears that mature
engineering conforms to the PSEM and this matu- Baber, R.L. (1997). Comparison of electrical
ration process has been justified by a conceptual engineering of Heaviside’s times and software
analysis from a historical perspective. engineering of our times. IEEE Annals of the
The PSEM and the analysis have provided History of Computing archive, 19(4), 5-17.
the framework and the context for the debates
Bergin, T. J., & Gibson, R. G. (Eds.). (1996). His-
on whether software development should be
tory of programming languages. Addison-Wesley.
considered as an engineering discipline or not.
From our conceptual analysis we conclude that Biegler, L. T., Grossmann, I. E., & Westerberg,
software engineering is still in a pre-mature en- A. W. (1997). Systematic methods of chemical
gineering state. This is justified by the fact that it process design. Prentice Hall.
lacks several concepts that are necessary for effec-
Boehm, B., & Turner, R. (2003). Balancing agility
tive problem-solving. More concretely, we have
and discipline. Addison-Wesley.
identified the three processes of technical problem
analysis, solution domain analysis and alternative Booch, G. (1991). Object-oriented analysis and
space analysis that are not yet complete and fully design, with applications. Redwood City, CA:
integrated in software development practices. The Benjamin/Cummins Publishing Company.
Nevertheless, despite the differences between
Bourque, P., Dupuis, R., & Abran, A. (1999).
software engineering and mature engineering, one
The guide to the software engineering body
of the key issues in this analysis is that software
of knowledge. IEEE Software, 16(6), 35–44.
development does follow the same evolution of
doi:10.1109/52.805471
the problem-solving concepts that can also be
observed from the history of mature engineering Braha, D., & Maimon, O. (1997). The design
disciplines. Although it has not yet achieved the process: Properties, paradigms, and structure.
state of a professional mature engineering disci- IEEE Transactions on Systems, Man, and Cy-
pline the consciousness on the required concepts bernetics, 27(2).
is increasing. With respect to the developments
Brooks, F. (1975). The mythical man-month.
in other engineering disciplines, our study shows
Reading, MA: Addison-Wesley.
even a higher pace of the evolution of problem-
solving concepts in software engineering and we Budgen, D. (2003). Software design (2nd ed.).
expect that it will approach mature engineering Addison-Wesley.
disciplines in the near future.
Chen, W. F. (1998). The civil engineering hand-
book. CRC Press.

15
 A Comparative Analysis of Software Engineering with Mature Engineering Disciplines

Chikofsky, E. J. (1989). Computer-Aided Software Evans, E. (2004). Domain-driven design: Tackling

Engineering (CASE). Washington, D.C.: IEEE complexity in the heart of software. Addison-
Computer Society. Wesley.
Chomsky, N. (1965). Aspects of the theory of Fenton, N. E., & Phleeger, S. L. (1997). Software
syntax. MIT Press. metrics: A rigorous & practical approach. PWS
Publishing Company.
Clements, P., & Northrop, L. (2002). Software
product lines: Practices and patterns. Addison- Filman, R.E. Elrad, T., Clark, S. & Aksit, M.
Wesley. (2004). Aspect-oriented software development.
Pearson Eduction.
Coad, P., & Yourdon, E. (1991). Object-oriented
design. Yourdon Press. Gamma, E., Helm, R., Johnson, R., & Vlissides,
J. (1995). Design patterns: Elements of reusable
Colburn, T. R. (2000). Philosophy of computer
object-oriented software. Reading, MA: Addison-
science, part 3. In Philosophy and Computer Sci-
Wesley.
ence (pp. 127–210). Armonk, USA: M.E. Sharpe.
Ghezzi, C., Jazayeri, M., & Mandrioli, D. (2002).
Coyne, R. D., Rosenman, M. A., Radford, A. D.,
Fundamentals of software engineering. Prentice-
Balachandran, M., & Gero, J. S. (1990). Knowl-
Hall.
edge-based design systems. Addison-Wesley.
Glass, R. L., & Vessey, I. (1995). Contemporary
Cross, N. (1989). Engineering design methods.
application domain taxonomies. IEEE Software,
Wiley & Sons.
12(4), 63–76. doi:10.1109/52.391837
Deek, F. P., Turoff, M., & McHugh, J. A. (1999). A
Jackson, M. (1975). Principles of program design.
common model for problem solving and program
Academic Press. Jackson, M. (2000). Problem
development. IEEE Transactions on Education,
frames: Analyzing and structuring software de-
4, 331–336. doi:10.1109/13.804541
velopment problems. Addison-Wesley.
DeMarco, T. (1978). Structured analysis and
Jacobson, I., Booch, G., & Rumbaugh, J. (1999).
system specification. Yourdon Inc.
The unified software development process.
Diaper, D. (Ed.). (1989). Knowledge elicitation. Addison-Wesley.
Chichester, UK: Ellis Horwood.
Jones, J. C. (1992). Design methods: Seeds of
Dijkstra, E. W. (1969). Structured programming, human futures. London: Wiley International.
software engineering techniques. Brussels: NATO
Juristo, N., & Moreno, A. M. (2001). Basics of
Science Committee.
software engineering experimentation. Kluwer
Dorf, R. C. (1997). The electrical engineering Academic Publishers.
handbook. New York: Springer Verlag.
Knuth, D. (1967). The art of computer program-
Dunsheath, P. (1997). A history of electrical en- ming. Addison-Wesley.
gineering. London: Faber & Faber.
Knuth, D. (1974). Computer programming as an
Ertas, A., & Jones, J. C. (1996). The engineering art. Communications of the ACM, 17(12), 667-
design process. Wiley. 673. Transcript of the 1974 Turing Award lecture.

16
A Comparative Analysis of Software Engineering with Mature Engineering Disciplines

Maimon, O., & Braha, D. (1996). On the complex- Rubinstein, M. F., & Pfeiffer, K. (1980). Con-
ity of the design synthesis problem. IEEE Trans- cepts in problem solving. Englewood Cliffs, NJ:
actions on Systems, Man, and Cybernetics, 26(1). Prentice-Hall.
Marks, L. S. (1987). Marks’ standard handbook Rumbaugh, J., Jacobson, I., & Booch, G. (1998).
for mechanical engineers. McGraw-Hill. The unified modeling language reference manual.
Addision-Wesley.
McConnell, S. (2003). Professional software
development: Shorter schedules, better projects, Shapiro, S. (1997). Splitting the difference: The
superior products, enhanced careers. Boston: historical necessity of synthesis in software engi-
Addison-Wesley. neering. IEEE Annals of the History of Computing,
19(1), 20–54. doi:10.1109/85.560729
Newell, N., & Simon, H. A. (1976). Human prob-
lem solving. Englewood Cliffs, NJ: Prentice-Hall. Shaw, M. (1990). Prospects for an engineering
discipline of software. IEEE Software, 15–24.
Parnas, D. L. (1972). On the criteria to be
doi:10.1109/52.60586
used in decomposing systems into mod-
ules. Communications of the ACM, 15(12). Shaw, M., & Garlan, D. (1996). Software archi-
doi:10.1145/361598.361623 tecture: Perspectives on an emerging discipline.
Prentice Hall.
Parnas, D. L. (1998). Software engineering
programmes are not computer science pro- Smith, A. A., Hinton, E., & Lewis, R. W. (1983).
grammes. Annals of Software Engineering, 19–37. Civil engineering systems analysis and design.
doi:10.1023/A:1018949113292 Wiley & Sons.
Perry, R. (1984). Perry’s chemical engineer’s Smith, G. F., & Browne, G. J. (1993). Conceptual
handbook. New York: McGraw-Hill. foundations of design problem solving. IEEE
Transactions on Systems, Man, and Cybernetics,
Petroski, H. (1992). To engineer is human: The
23(5). doi:10.1109/21.260655
role of failure in successful design. New York:
Vintage Books. Sommerville, I. (2007). Software engineering.
Addison-Wesley.
Popper, K. (2001). All life is problem solving.
Routledge. Stahl, T., & Völter, M. (2006). Model-driven
software development. Wiley.
Pressman, R. S. (2008). Software engineering: A
practitioner’s approach. McGraw-Hill. SWEBOK. (2004). Guide to the software engi-
neering body of knowledge.
Rapaport, B. (2006). Philosophy of computer
science: What I think it is, what I teach, & how Szyperski, C. (1998). Component software:
I teach it. Herbert A. Simon Keynote Address. Beyond object-oriented programming. Addison-
NA-CAP Video. Wesley.
Rittel, H. W., & Webber, M. M. (1984). Planning Tekinerdoğan, B., & Akşit, M. (2006). Introducing
problems are wicked problems. Policy Sciences, the concept of synthesis in the software architec-
4, 155–169. doi:10.1007/BF01405730 ture design process. Journal of Integrated Design
and Process Science, 10(1), 45–56.

17
 A Comparative Analysis of Software Engineering with Mature Engineering Disciplines

Upton, N. (1975). An illustrated history of civil Williams, M. R. (1997). A history of computing

engineering. London: Heinemann. technology. IEEE Computer Society.
von Foerster, F. (1979). Cybernetics of cybernetics. Wirth, N. (1971). Program development by step-
In Krippendorff, K. (Ed.), Communication and wise refinement. Communications of the ACM,
control in society. New York: Gordon and Breach. 14(4), 221–227. doi:10.1145/362575.362577
Wilcox, A. D., Huelsman, L. P., Marshall, S. V., Yourdon, E., & Constantine, L. L. (1979). Struc-
Philips, C. L., Rashid, M. H., & Roden, M. S. tured design. Prentice-Hall.
(1990). Engineering design for electrical engi-
neers. Prentice-Hall.

18