ZeePedia buy college essays online

Software Engineering - II

<<< Previous The Software Engineering Discipline Next >>>
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.
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
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."
"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.
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.
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.
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
[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.
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.
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.
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.
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
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
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.
Prior Software Engineering Education and Computing Curriculum
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.
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
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