The Software Engineering Discipline

<< INTRODUCTION

Guiding Principles >>

Chapter 2: The Software Engineering Discipline

This chapter discusses the nature of software engineering and some of the history and

background that is relevant to the development of software engineering curriculum guidance.

The purpose of the chapter is to provide context and rationale for the curriculum materials in

subsequent chapters.

2.1

The Discipline of Software Engineering

Since the dawn of computing in the 1940s, the applications and uses of computers have grown at

a staggering rate. Software plays a central role in almost all aspects of daily life: in government,

banking and finance, education, transportation, entertainment, medicine, agriculture, and law.

The number, size, and application domains of computer programs have grown dramatically; as a

result, hundreds of billions are being spent on software development, and the livelihood and lives

of most people depend on the effectiveness of this development. Software products have helped

us to be more efficient and productive. They make us more effective problem solvers, and they

provide us with an environment for work and play that is often safer, more flexible, and less

confining. Despite these successes, there are serious problems in the cost, timeliness, and quality

of many software products. The reasons for these problems are many and include the following:

· Software products are among the most complex of man-made systems, and software by its

very nature has intrinsic, essential properties (e.g., complexity, invisibility, and

changeability) that are not easily addressed [Brooks 95].

Programming techniques and processes that worked effectively for an individual or a small

team to develop modest-sized programs do not scale-up well to the development of large,

complex systems (i.e., systems with millions of lines of code, requiring years of work, by

hundreds of software developers).

The pace of change in computer and software technology drives the demand for new and

evolved software products. This situation has created customer expectations and competitive

forces that strain our ability to produce quality of software within acceptable development

schedules.

It has been over thirty-five years since the first organized, formal discussion of software

engineering as a discipline took place at the 1968 NATO Conference on Software Engineering

[Naur 1969]. The term "software engineering" is now widely used in industry, government, and

academia: hundreds of thousands of computing professionals go by the title "software engineer";

numerous publications, groups and organizations, and professional conferences use the term

software engineering in their names; and there are many educational courses and programs on

software engineering. However, there are still disagreements and differences of opinion about

the meaning of the term. The following definitions provide several views of the meaning and

nature of software engineering. Nevertheless, they all possess a common thread, which states, or

strongly implies that software engineering is more than just coding - it includes quality, schedule

and economics, and the knowledge and application of principles and discipline.

SE2004 Volume 8/23/2004

Definitions of Software Engineering

Over the years, numerous definitions of the discipline of Software Engineering have been

presented. For the purpose of this document, we highlight the following definitions:

· "The establishment and use of sound engineering principles (methods) in order to obtain

economically software that is reliable and works on real machines" [Bauer 1972].

"Software engineering is that form of engineering that applies the principles of computer

science and mathematics to achieving cost-effective solutions to software problems."

[CMU/SEI-90-TR-003]

"The application of a systematic, disciplined, quantifiable approach to the development,

operation, and maintenance of software" [IEEE 1990].

There are aspects of each of these definitions that contribute to the perspective of software

engineering used in the construction of this volume. One particularly important aspect is that

software engineering builds on computer science and mathematics. But, in the engineering

tradition, it goes beyond this technical basis to draw upon a broader range of disciplines.

These definitions clearly state that software engineering is about creating high-quality software

in a systematic, controlled, and efficient manner. Consequently, there are important emphases

on analysis and evaluation, specification, design, and evolution of software. In addition, there are

issues related to management and quality, to novelty and creativity, to standards, to individual

skills, and to teamwork and professional practice that play a vital role in software engineering.

2.2

Software Engineering as a Computing Discipline

A common misconception about software engineering is that it is primarily about process-

oriented activities (i.e., requirements, design, quality assurance, process improvement, and

project management). In this view, competency in software engineering can be achieved by

acquiring a strong engineering background, a familiarity with a software development process

and a minimal computing background, including experience using one or more programming

languages. Such a background is, in fact, quite insufficient; the misconception that leads to such

thinking is based on an incomplete view of the nature and challenges of software engineering.

In the historical development of computing, computer scientists produced software and electrical

engineers produced the hardware on which the software runs. As the size, complexity, and

critical importance of software grew, so did the need to ensure that software performs as

intended. By the early 1970's, it was apparent that proper software development practices

required more than just the underlying principles of computer science; they need both the

analytical and descriptive tools developed within computer science and the rigor that the

engineering disciplines bring to the reliability and trustworthiness of the artifacts they engineer.

Software engineering thus is different in character from other engineering disciplines, due to

both the intangible nature of software and to the discrete nature of software operation. It seeks to

integrate the principles of mathematics and computer science with the engineering practices

developed to produce tangible, physical artifacts. Drawing on computing and mathematics as

foundations, software engineering seeks to develop systematic models and reliable techniques

SE2004 Volume 8/23/2004

for producing high-quality software; and these concerns extend all the way from theory and

principles to the development practices that are most visible to those outside of the discipline.

While it is not expected that every software engineer will have deep expertise in all of aspects of

computing, a general understanding of their relevance and some expertise in particular aspects

are a necessity. The definition of the body of the Software Engineering Education Knowledge

(SEEK) described in Chapter 4 reflects the reliance of software engineering on computer

science, with the largest component of the SEEK being Computing Essentials.

2.3

Software Engineering as an Engineering Discipline

The study and practice of software engineering is influenced both by its roots in computer

science and its emergence as an engineering discipline. A significant amount of current software

engineering research is conducted within the context of computer science and computing

departments or colleges. Similarly, software engineering degree programs are being developed

by such academic units as well as within engineering colleges. Thus, the discipline of software

engineering can be seen as an engineering field with a stronger connection to its underlying

computer science discipline than the more traditional engineering fields. In the process of

constructing this volume, particular attention has been paid to incorporating the practices of

engineering into the development of software, so as to distinguish this curriculum from computer

science curricula. To prepare for the more detailed development of these ideas, this section

examines the engineering methodology and how it applies to software development.

We must also point out that although there are strong similarities between software engineering

and more traditional engineering (as listed in section 2.3.1), there are also some differences (not

necessarily to the detriment of software engineering):

· Foundations are primarily in computer science, not in natural sciences.

The focus is on discrete rather than continuous mathematics.

The concentration is on abstract/logical entities instead of concrete/physical artifacts.

There is no "manufacturing" phase in the traditional sense.

Software "maintenance" primarily refers to continued development, or evolution, and not to

conventional wear and tear.

2.3.1

Characteristics of Engineering

There is a set of characteristics that is not only common to every engineering discipline, but is so

predominant and critical that they can be used to describe the underpinnings of engineering. It is

these underpinnings that should be viewed as desirable characteristics of software engineers.

Thus they have influenced the development of software engineering and the contents of this

volume.

[1] Engineers proceed by making a series of decisions, carefully evaluating options, and

choosing an approach at each decision-point that is appropriate for the current task in the

current context. Appropriateness can be judged by tradeoff analysis, which balances costs

against benefits.

[2] Engineers measure things, and when appropriate, work quantitatively; they calibrate and

SE2004 Volume 8/23/2004

validate their measurements; and they use approximations based on experience and

empirical data.

[3] Engineers emphasize the use of a disciplined process when creating a design and can

operate effectively as part of a team in doing so.

[4] Engineers can have multiple roles: research, development, design, production, testing,

construction, operations, management, and others such as sales, consulting, and teaching.

[5] Engineers use tools to apply processes systematically. Therefore, the choice and use of

appropriate tools is key to engineering.

[6] Engineers, via their professional societies, advance by the development and validation of

principles, standards, and best practices.

[7] Engineers reuse designs and design artifacts.

It should be noted that while the term engineer and engineering will be used extensively in the

following sections, this document is about the design, development and implementation of

undergraduate software engineering curricula. It must be acknowledged that much of the work

in this document is based on the work of numerous individuals and groups that have advanced

the state of computer science and information technology, and have developed programs that

help prepare graduates to practice software development in a professional manner.

2.3.2

Engineering design

Design is central to any engineering activity, and it plays a critical role in regard to software. In

general, engineering design activities refer to the definition of a new artifact by finding technical

solutions to specific practical issues, while taking into account economic, legal, and social

considerations. As such, engineering design provides the prerequisites for the "physical"

realization of a solution, by following a systematic process, that best satisfies a set of

requirements within potentially conflicting constraints.

Software engineering differs from traditional engineering because of the special nature of

software, which places a greater emphasis on abstraction, modeling, information organization

and representation, and the management of change. Software engineering also includes

implementation and quality control activities normally considered in the manufacturing process

design and manufacturing steps of the product cycle. Furthermore, continued evolution (i.e.,

"maintenance") is also of more critical importance for software. Even with this broader scope,

however, a central challenge of software engineering is still the kind of decision-making known

as engineering design. An important aspect of this challenge is that the supporting process must

be applied at multiple levels of abstraction. An increasing emphasis on reuse and component-

based development hold hope for new, improved practices in this area.

2.3.3

Domain-specific software engineering

Within a specific domain, an engineer relies on specific education and experience to evaluate

possible solutions, keeping in mind various factors relating to function, cost, performance and

manufacturability. Engineers have to determine which standard parts can be used and which

SE2004 Volume 8/23/2004

parts have to be developed from scratch. To make the necessary decisions, they must have a

fundamental knowledge of the domain and related specialty subjects.

Domain-specific techniques, tools, and components typically provide the most compelling

software engineering success stories. Great leverage has been achieved in well-understood

domains where standard implementation approaches have been widely adopted. To be well

prepared for professional practice, graduates of software engineering programs should come to

terms with the fundamentals of at least one application domain. That is, they should understand

the problem space that defines the domain as well as common approaches, including standard

components (if any), used in producing software to solve problems in that domain.

2.4

Professional Practice

A key objective of any engineering program is to provide graduates with the tools necessary to

begin the professional practice of engineering. As indicated in Chapter 3, an important guiding

principle for this document is "The education of all software engineering students must include

student experiences with the professional practice of software engineering." The content and

nature of such experiences are discussed in subsequent chapters, while this section provides

rationale and background for the inclusion of professional practice elements in a software

engineering curriculum.

2.4.1

Rationale

Professionals have special obligations that require them to apply specialist knowledge on behalf

of members of society who do not themselves have such knowledge. All of the characteristics of

engineering discussed section 2.3.1 relate, directly or indirectly, to the professional practice of

engineering. Employers of graduates from engineering programs often speak to these same

needs [Denning 1992]. Each year, the National Association of Colleges and Employers conducts

a survey to determine what qualities employers consider most important in applicants seeking

employment [NACE 2003]. In 2003, employers were asked to rate the importance of candidate

qualities and skills on a five-point scale, with five being "extremely important" and one being

"not important." Communication skills (4.7 average), honesty/integrity (4.7), teamwork skills

(4.6), interpersonal skills (4.5), motivation and initiative (4.5), and strong work ethic (4.5) were

the most desired characteristics.

The dual challenges of society's critical dependence on the quality and cost of software, and the

relative immaturity of software engineering, make attention to professional practice issues even

more important to software engineering programs than many other engineering programs.

Graduates of software engineering programs need to arrive in the workplace equipped to meet

these challenges and to help evolve the software engineering discipline into a more professional

and accepted state. Like other engineering professionals, when appropriate and feasible, software

engineers need to seek quantitative data on which to base decisions, yet also be able to function

effectively in an environment of ambiguity and avoid the limitations of over-simplified or

unverified "formula-based" modeling.

SE2004 Volume 8/23/2004

2.4.2

Software Engineering Code of Ethics and Professional Practices

Software Engineering as a profession has obligations to society. The products produced by

software engineers affect the lives and livelihoods of the clients and users of those products.

Hence, software engineers need to act in an ethical and professional manner. The preamble to the

Software Engineering Code of Ethics and Professional Practice [ACM 1998] states

"Because of their roles in developing software systems, software engineers have

significant opportunities to do good or cause harm, to enable others to do good or

cause harm, or to influence others to do good or cause harm. To ensure, as much

as possible, that their efforts will be used for good, software engineers must

commit themselves to making software engineering a beneficial and respected

profession. In accordance with that commitment, software engineers shall adhere

to the following Code of Ethics and Professional Practice."

To help insure ethical and professional behavior, software engineering educators have an

obligation to not only make their students familiar with the Code, but to also find ways for

students to engage in discussion and activities that illustrate and illuminate the Code's eight

principles, including common dilemmas facing professional engineers in typical employment

situations.

2.4.3

Curriculum Support for Professional Practice

A curriculum can have an important direct effect on some professional practice factors (e.g.,

teamwork, communication, and analytic skills), while others (e.g. strong work ethic, self-

confidence) are subject to the more subtle influence of a college education on an individual's

character, personality and maturity. In this volume, elements of professional practice that should

be part of any curriculum, and expected student outcomes, are identified in Chapter 4. Chapters

5 and 6 contain guidance and ideas for incorporating material about professional practice into a

software engineering curriculum. In particular, there is consideration of material directly

supportive of professional practice, such as technical communications, ethics, engineering

economics, etc., and ideas about the modeling of work environments, such as case studies,

laboratory work, and team project courses.

There are many elements, some outside the classroom, which can have a significant effect on a

student's preparation for professional practice. The following are some examples: involvement

in the core curriculum by faculty who have professional experience; student work experience as

an intern or as part of a cooperative education program; and extracurricular activities, such as

attending colloquia, field trips visits to industry, and participating in student professional clubs

and activities.

2.5

Prior Software Engineering Education and Computing Curriculum

Efforts

In the late 1970s, the IEEE-CS initiated an effort to develop curriculum recommendations for

software engineering, which was used in the creation of a number of masters programs across in

the U.S. [Freeman 1976, Freeman 1978]. While this effort centered on graduate education, it

formed the basis for a focus on software engineering education in general. In the U.K., the first

SE2004 Volume 8/23/2004

undergraduate level named software engineering programs commenced at Imperial College in

1985 and at University of Sheffield in 1988 [Finkelstein 1993, Cowling 1998].

In the late 1980s and early 1990s, software engineering education was fostered and supported by

the efforts of the Education Group of the Software Engineering Institute (SEI), at Carnegie

Mellon University. These efforts included the following: surveying and reporting on the state of

software engineering education, publishing curriculum recommendations for graduate software

engineering programs, instituting a Masters of Software Engineering program at CMU,

organizing and facilitating workshops for software engineering educators, and publishing

software education curriculum modules [Budgen 2003, Tomayko 1999].

The SEI initiated and sponsored the first Conference on Software Engineering Education &

Training (CSEET), held in 1987. The CSEET has since provided a forum for SE educators to

meet, present, and discuss SE education issues, methods, and activities. In 1995, as part of its

education program, the SEI started the Working Group on Software Engineering Education and

Training (WGSEET) (http://www.sei.cmu.edu/collaborating/ed/workgroup-ed.html). The

WGSEET objective is to investigate issues, propose solutions and actions, and share information

and best practices with the software engineering education and training community. In 1999, the

Working Group produced a technical report offering guidelines on the design and

implementation of undergraduate software engineering programs [Bagert 1999]. Outside the US

there have been a number of national and international efforts to raise awareness of issues

relating to Software Engineering education. Most of these have consisted of education streams

within larger events (for example in the 1996 Professional Awareness in Software Engineering

Conference [Myers, 1997]), or small conferences devoted just to Software Engineering

education, such as the IFIP 1993 Working Conference in Hong Kong [Barta, 1993] and an

International Symposium held in Rovaniemi, Finland in 1997 [Taipale, 1997]).

In 1993, the IEEE-CS and the ACM established the IEEE-CS/ACM Joint Steering Committee

for the Establishment of Software Engineering as a Profession. Subsequently, the Steering

committee was replaced by the Software Engineering Coordinating Committee (SWECC), which

coordinated the work of three efforts: the development of a Code of Ethics and Professional

Practices [ACM 1998]; the Software Engineering Education Project (SWEEP), which developed

a draft accreditation criteria for undergraduate programs in software engineering [Barnes 1998];

and the development of a Guide to the Software Engineering Body of Knowledge (SWEBOK)

[Bourque 2001]. Also, Curriculum 1991 report [Tucker 1991] and the CCCS volume [ACM

2001] has been a major influence on the structure and content of this document. All these efforts

have influenced the philosophy and the content of this volume.

2.6

SWEBOK and other BOK Efforts

A major challenge in providing curriculum guidance for new and emerging, or dynamic,

disciplines is the identification and specification of the underlying content of the discipline.

Since the computing disciplines are both relatively new and dynamic, the specification of a

"body of knowledge" is critical.

In Chapter 4, a body of knowledge is specified that supports software engineering education

curricula (called SEEK - Software Engineering Education Knowledge). The organization and

SE2004 Volume 8/23/2004

content was influenced by a number of previous efforts at describing the knowledge that comes

from other related disciplines. The following is a description of such efforts:

· The SWEBOK is a comprehensive description of the knowledge needed for the practice of

software engineering. One of the objectives of this project was to "Provide a foundation for

curriculum development ...". To support this objective, the SWEBOK includes a rating

system for its knowledge topics based on Bloom's levels of educational objectives [Bloom

1956]. Although the SWEBOK was one of the primary sources used in the development of

the SEEK and there has been close communication between the SWEBOK and SE2004

projects, there were assumptions and features of the SWEBOK that differentiate the two

efforts:

The SWEBOK is intended to cover knowledge after four years of practice.

The SWEBOK intentionally does not cover non-software engineering knowledge that a

software engineer must have.

The SE2004 is intended to support only undergraduate software engineering education.

The PMBOK (Guide to the Project Management Body of Knowledge) [PMI 2000] provides a

description of knowledge about project management (not limited to software projects).

Besides its relevance to software project management, the PMBOK's organization and style

has influenced similar, subsequent efforts in the computing disciplines.

The IS'97 report (Model Curriculum and Guidelines for Undergraduate Degree Programs in

Information Systems) [Davis, 1997] describes a model curriculum for undergraduate degree

programs in Information Systems. The document includes a description of an IS body of

knowledge, which included SE knowledge, and also a metric similar to Bloom's levels for

prescribing the required depth of knowledge for undergraduates.

The report "Computing as a Discipline" [ACM 1989] provides a comprehensive definition of

computing and formed the basis for the work on Computing Curriculum 1991, and its

successor Computing Curriculum 2001. It specifies nine subject areas that cover the

computing discipline, including software engineering.

The Guidelines for Software Engineering Education [Bagert 1999] (developed by the

WGSEET), describes a curriculum model for undergraduate software engineering education

that is based on a body of knowledge consisting of four areas: Foundations, Core, Recurring

and Support.

SE2004 Volume 8/23/2004

Table of Contents: