Showing posts with label SOFTWARE ENGINEERING. Show all posts
Showing posts with label SOFTWARE ENGINEERING. Show all posts
Sunday, 18 September 2011
SOFTWARE PROCESS MODELS
To solve actual problems in an industry setting, a software engineer or a team of engi-
neers must incorporate a development strategy that encompasses the process, meth-
ods, and tools layers described in Section 2.1.1 and the generic phases discussed in
Section 2.1.2. This strategy is often referred to as a process model or a software engi-
neering paradigm. A process model for software engineering is chosen based on the
nature of the project and application, the methods and tools to be used, and the con-
trols and deliverables that are required. In an intriguing paper on the nature of the
software process, L. B. S. Raccoon [RAC95] uses fractals as the basis for a discussion
of the true nature of the software process.
neers must incorporate a development strategy that encompasses the process, meth-
ods, and tools layers described in Section 2.1.1 and the generic phases discussed in
Section 2.1.2. This strategy is often referred to as a process model or a software engi-
neering paradigm. A process model for software engineering is chosen based on the
nature of the project and application, the methods and tools to be used, and the con-
trols and deliverables that are required. In an intriguing paper on the nature of the
software process, L. B. S. Raccoon [RAC95] uses fractals as the basis for a discussion
of the true nature of the software process.
All software development can be characterized as a problem solving loop (Figure
2.3a) in which four distinct stages are encountered: status quo, problem definition,
technical development, and solution integration. Status quo “represents the current
state of affairs” [RAC95]; problem definition identifies the specific problem to be solved;
technical development solves the problem through the application of some technol-
ogy, and solution integration delivers the results (e.g., documents, programs, data,
new business function, new product) to those who requested the solution in the first
place. The generic software engineering phases and steps defined in Section 2.1.2
easily map into these stages.
This problem solving loop applies to software engineering work at many different
levels of resolution. It can be used at the macro level when the entire application is
considered, at a mid-level when program components are being engineered, and
(b)
2.3a) in which four distinct stages are encountered: status quo, problem definition,
technical development, and solution integration. Status quo “represents the current
state of affairs” [RAC95]; problem definition identifies the specific problem to be solved;
technical development solves the problem through the application of some technol-
ogy, and solution integration delivers the results (e.g., documents, programs, data,
new business function, new product) to those who requested the solution in the first
place. The generic software engineering phases and steps defined in Section 2.1.2
easily map into these stages.
This problem solving loop applies to software engineering work at many different
levels of resolution. It can be used at the macro level when the entire application is
considered, at a mid-level when program components are being engineered, and
(b)
even at the line of code level. Therefore, a fractal4 representation can be used to pro-
vide an idealized view of process. In Figure 2.3b, each stage in the problem solving
loop contains an identical problem solving loop, which contains still another prob-
lem solving loop (this continues to some rational boundary; for software, a line of
code).
Realistically, it is difficult to compartmentalize activities as neatly as Figure 2.3b
implies because cross talk occurs within and across stages. Yet, this simplified view
leads to a very important idea: regardless of the process model that is chosen for a
software project, all of the stages—status quo, problem definition, technical develop-
ment, and solution integration—coexist simultaneously at some level of detail. Given
the recursive nature of Figure 2.3b, the four stages discussed apply equally to the
analysis of a complete application and to the generation of a small segment of code.
Raccoon [RAC95] suggests a “Chaos model” that describes “software develop-
ment [as] a continuum from the user to the developer to the technology.” As work
progresses toward a complete system, the stages are applied recursively to user needs
and the developer’s technical specification of the software.
In the sections that follow, a variety of different process models for software engi-
neering are discussed. Each represents an attempt to bring order to an inherently
chaotic activity. It is important to remember that each of the models has been char-
acterized in a way that (ideally) assists in the control and coordination of a real soft-
ware project. And yet, at their core, all of the models exhibit characteristics of the
Chaos model.
.
vide an idealized view of process. In Figure 2.3b, each stage in the problem solving
loop contains an identical problem solving loop, which contains still another prob-
lem solving loop (this continues to some rational boundary; for software, a line of
code).
Realistically, it is difficult to compartmentalize activities as neatly as Figure 2.3b
implies because cross talk occurs within and across stages. Yet, this simplified view
leads to a very important idea: regardless of the process model that is chosen for a
software project, all of the stages—status quo, problem definition, technical develop-
ment, and solution integration—coexist simultaneously at some level of detail. Given
the recursive nature of Figure 2.3b, the four stages discussed apply equally to the
analysis of a complete application and to the generation of a small segment of code.
Raccoon [RAC95] suggests a “Chaos model” that describes “software develop-
ment [as] a continuum from the user to the developer to the technology.” As work
progresses toward a complete system, the stages are applied recursively to user needs
and the developer’s technical specification of the software.
In the sections that follow, a variety of different process models for software engi-
neering are discussed. Each represents an attempt to bring order to an inherently
chaotic activity. It is important to remember that each of the models has been char-
acterized in a way that (ideally) assists in the control and coordination of a real soft-
ware project. And yet, at their core, all of the models exhibit characteristics of the
Chaos model.
.
THE SOFTWARE PROCESS
A software process can be characterized as shown in Figure 2.2. A common process
framework is established by defining a small number of framework activities that are
applicable to all software projects, regardless of their size or complexity. A number
of task sets—each a collection of software engineering work tasks, project milestones,
framework is established by defining a small number of framework activities that are
applicable to all software projects, regardless of their size or complexity. A number
of task sets—each a collection of software engineering work tasks, project milestones,
work products, and quality assurance points—enable the framework activities to be
adapted to the characteristics of the software project and the requirements of the
project team. Finally, umbrella activities—such as software quality assurance, soft-
ware configuration management, and measurement2—overlay the process model.
Umbrella activities are independent of any one framework activity and occur through-
out the process.
In recent years, there has been a significant emphasis on “process maturity.” The
Software Engineering Institute (SEI) has developed a comprehensive model predi-
cated on a set of software engineering capabilities that should be present as organ-
izations reach different levels of process maturity. To determine an organization’s
current state of process maturity, the SEI uses an assessment that results in a five
point grading scheme. The grading scheme determines compliance with a capability
maturity model (CMM) [PAU93] that defines key activities required at different levels
of process maturity. The SEI approach provides a measure of the global effectiveness
of a company's software engineering practices and establishes five process maturity
levels that are defined in the following manner:
Level 1: Initial. The software process is characterized as ad hoc and occa-
sionally even chaotic. Few processes are defined, and success depends on indi-
vidual effort.
Level 2: Repeatable. Basic project management processes are established
to track cost, schedule, and functionality. The necessary process discipline is
in place to repeat earlier successes on projects with similar applications.
adapted to the characteristics of the software project and the requirements of the
project team. Finally, umbrella activities—such as software quality assurance, soft-
ware configuration management, and measurement2—overlay the process model.
Umbrella activities are independent of any one framework activity and occur through-
out the process.
In recent years, there has been a significant emphasis on “process maturity.” The
Software Engineering Institute (SEI) has developed a comprehensive model predi-
cated on a set of software engineering capabilities that should be present as organ-
izations reach different levels of process maturity. To determine an organization’s
current state of process maturity, the SEI uses an assessment that results in a five
point grading scheme. The grading scheme determines compliance with a capability
maturity model (CMM) [PAU93] that defines key activities required at different levels
of process maturity. The SEI approach provides a measure of the global effectiveness
of a company's software engineering practices and establishes five process maturity
levels that are defined in the following manner:
Level 1: Initial. The software process is characterized as ad hoc and occa-
sionally even chaotic. Few processes are defined, and success depends on indi-
vidual effort.
Level 2: Repeatable. Basic project management processes are established
to track cost, schedule, and functionality. The necessary process discipline is
in place to repeat earlier successes on projects with similar applications.
Level 3: Defined. The software process for both management and engi-
neering activities is documented, standardized, and integrated into an organi-
zationwide software process. All projects use a documented and approved
version of the organization's process for developing and supporting software.
This level includes all characteristics defined for level 2.
Level 4: Managed. Detailed measures of the software process and product
quality are collected. Both the software process and products are quantitatively
understood and controlled using detailed measures. This level includes all char-
acteristics defined for level 3.
Level 5: Optimizing. Continuous process improvement is enabled by quan-
titative feedback from the process and from testing innovative ideas and tech-
nologies. This level includes all characteristics defined for level 4.
The five levels defined by the SEI were derived as a consequence of evaluating
responses to the SEI assessment questionnaire that is based on the CMM. The results
of the questionnaire are distilled to a single numerical grade that provides an indi-
cation of an organization's process maturity.
The SEI has associated key process areas (KPAs) with each of the maturity levels.
The KPAs describe those software engineering functions (e.g., software project plan-
ning, requirements management) that must be present to satisfy good practice at a
particular level. Each KPA is described by identifying the following characteristics:
• Goals—the overall objectives that the KPA must achieve.
• Commitments—requirements (imposed on the organization) that must be met
to achieve the goals or provide proof of intent to comply with the goals.
• Abilities—those things that must be in place (organizationally and technically)
to enable the organization to meet the commitments.
• Activities—the specific tasks required to achieve the KPA function.
• Methods for monitoring implementation—the manner in which the activities
are monitored as they are put into place.
• Methods for verifying implementation—the manner in which proper practice
for the KPA can be verified.
Eighteen KPAs (each described using these characteristics) are defined across the
maturity model and mapped into different levels of process maturity. The following
KPAs should be achieved at each process maturity level:3
Process maturity level 2
• Software configuration management
• Software quality assurance
3 Note that the KPAs are additive. For example, process maturity level 4 contains all level 3 KPAs
plus those noted for level 2.
neering activities is documented, standardized, and integrated into an organi-
zationwide software process. All projects use a documented and approved
version of the organization's process for developing and supporting software.
This level includes all characteristics defined for level 2.
Level 4: Managed. Detailed measures of the software process and product
quality are collected. Both the software process and products are quantitatively
understood and controlled using detailed measures. This level includes all char-
acteristics defined for level 3.
Level 5: Optimizing. Continuous process improvement is enabled by quan-
titative feedback from the process and from testing innovative ideas and tech-
nologies. This level includes all characteristics defined for level 4.
The five levels defined by the SEI were derived as a consequence of evaluating
responses to the SEI assessment questionnaire that is based on the CMM. The results
of the questionnaire are distilled to a single numerical grade that provides an indi-
cation of an organization's process maturity.
The SEI has associated key process areas (KPAs) with each of the maturity levels.
The KPAs describe those software engineering functions (e.g., software project plan-
ning, requirements management) that must be present to satisfy good practice at a
particular level. Each KPA is described by identifying the following characteristics:
• Goals—the overall objectives that the KPA must achieve.
• Commitments—requirements (imposed on the organization) that must be met
to achieve the goals or provide proof of intent to comply with the goals.
• Abilities—those things that must be in place (organizationally and technically)
to enable the organization to meet the commitments.
• Activities—the specific tasks required to achieve the KPA function.
• Methods for monitoring implementation—the manner in which the activities
are monitored as they are put into place.
• Methods for verifying implementation—the manner in which proper practice
for the KPA can be verified.
Eighteen KPAs (each described using these characteristics) are defined across the
maturity model and mapped into different levels of process maturity. The following
KPAs should be achieved at each process maturity level:3
Process maturity level 2
• Software configuration management
• Software quality assurance
3 Note that the KPAs are additive. For example, process maturity level 4 contains all level 3 KPAs
plus those noted for level 2.
• Software subcontract management
• Software project tracking and oversight
• Software project planning
• Requirements management
Process maturity level 3
• Peer reviews
• Intergroup coordination
• Software product engineering
• Integrated software management
• Training program
• Organization process definition
• Organization process focus
Process maturity level 4
• Software quality management
• Quantitative process management
Process maturity level 5
• Process change management
• Technology change management
• Defect prevention
Each of the KPAs is defined by a set of key practices that contribute to satisfying its
goals. The key practices are policies, procedures, and activities that must occur before
a key process area has been fully instituted. The SEI defines key indicators as "those
key practices or components of key practices that offer the greatest insight into whether
the goals of a key process area have been achieved." Assessment questions are
designed to probe for the existence (or lack thereof) of a key indicator.
• Software project tracking and oversight
• Software project planning
• Requirements management
Process maturity level 3
• Peer reviews
• Intergroup coordination
• Software product engineering
• Integrated software management
• Training program
• Organization process definition
• Organization process focus
Process maturity level 4
• Software quality management
• Quantitative process management
Process maturity level 5
• Process change management
• Technology change management
• Defect prevention
Each of the KPAs is defined by a set of key practices that contribute to satisfying its
goals. The key practices are policies, procedures, and activities that must occur before
a key process area has been fully instituted. The SEI defines key indicators as "those
key practices or components of key practices that offer the greatest insight into whether
the goals of a key process area have been achieved." Assessment questions are
designed to probe for the existence (or lack thereof) of a key indicator.
SOFTWARE ENGINEERING A LAYERED TECHNOLOGY
Although hundreds of authors have developed personal definitions of software engi-
neering, a definition proposed by Fritz Bauer [NAU69] at the seminal conference on
the subject still serves as a basis for discussion:
[Software engineering is] the establishment and use of sound engineering principles in
order to obtain economically software that is reliable and works efficiently on real machines.
Almost every reader will be tempted to add to this definition. It says little about the
technical aspects of software quality; it does not directly address the need for cus-
tomer satisfaction or timely product delivery; it omits mention of the importance of
measurement and metrics; it does not state the importance of a mature process. And
yet, Bauer’s definition provides us with a baseline. What “sound engineering princi-
ples” can be applied to computer software development? How do we “economically”
build software so that it is “reliable”? What is required to create computer programs
that work “efficiently” on not one but many different “real machines”? These are the
questions that continue to challenge software engineers.
The IEEE [IEE93] has developed a more comprehensive definition when it states:
Software Engineering: (1) The application of a systematic, disciplined, quantifiable approach
to the development, operation, and maintenance of software; that is, the application of
engineering to software. (2) The study of approaches as in (1).
2.1.1 Process, Methods, and Tools
Software engineering is a layered technology. Referring to Figure 2.1, any engineer-
ing approach (including software engineering) must rest on an organizational com-
mitment to quality. Total quality management and similar philosophies foster a
continuous process improvement culture, and this culture ultimately leads to the
neering, a definition proposed by Fritz Bauer [NAU69] at the seminal conference on
the subject still serves as a basis for discussion:
[Software engineering is] the establishment and use of sound engineering principles in
order to obtain economically software that is reliable and works efficiently on real machines.
Almost every reader will be tempted to add to this definition. It says little about the
technical aspects of software quality; it does not directly address the need for cus-
tomer satisfaction or timely product delivery; it omits mention of the importance of
measurement and metrics; it does not state the importance of a mature process. And
yet, Bauer’s definition provides us with a baseline. What “sound engineering princi-
ples” can be applied to computer software development? How do we “economically”
build software so that it is “reliable”? What is required to create computer programs
that work “efficiently” on not one but many different “real machines”? These are the
questions that continue to challenge software engineers.
The IEEE [IEE93] has developed a more comprehensive definition when it states:
Software Engineering: (1) The application of a systematic, disciplined, quantifiable approach
to the development, operation, and maintenance of software; that is, the application of
engineering to software. (2) The study of approaches as in (1).
2.1.1 Process, Methods, and Tools
Software engineering is a layered technology. Referring to Figure 2.1, any engineer-
ing approach (including software engineering) must rest on an organizational com-
mitment to quality. Total quality management and similar philosophies foster a
continuous process improvement culture, and this culture ultimately leads to the
development of increasingly more mature approaches to software engineering. The
bedrock that supports software engineering is a quality focus.
The foundation for software engineering is the process layer. Software engineer-
ing process is the glue that holds the technology layers together and enables rational
and timely development of computer software. Process defines a framework for a set
of key process areas (KPAs) [PAU93] that must be established for effective delivery of
software engineering technology. The key process areas form the basis for manage-
ment control of software projects and establish the context in which technical meth-
ods are applied, work products (models, documents, data, reports, forms, etc.) are
produced, milestones are established, quality is ensured, and change is properly man-
aged.
Software engineering methods provide the technical how-to's for building soft-
ware. Methods encompass a broad array of tasks that include requirements analy-
sis, design, program construction, testing, and support. Software engineering methods
rely on a set of basic principles that govern each area of the technology and include
modeling activities and other descriptive techniques.
Software engineering tools provide automated or semi-automated support for the
process and the methods. When tools are integrated so that information created by
one tool can be used by another, a system for the support of software development,
called computer-aided software engineering, is established. CASE combines software,
hardware, and a software engineering database (a repository containing important
information about analysis, design, program construction, and testing) to create a
software engineering environment analogous to CAD/CAE (computer-aided
design/engineering) for hardware.
bedrock that supports software engineering is a quality focus.
The foundation for software engineering is the process layer. Software engineer-
ing process is the glue that holds the technology layers together and enables rational
and timely development of computer software. Process defines a framework for a set
of key process areas (KPAs) [PAU93] that must be established for effective delivery of
software engineering technology. The key process areas form the basis for manage-
ment control of software projects and establish the context in which technical meth-
ods are applied, work products (models, documents, data, reports, forms, etc.) are
produced, milestones are established, quality is ensured, and change is properly man-
aged.
Software engineering methods provide the technical how-to's for building soft-
ware. Methods encompass a broad array of tasks that include requirements analy-
sis, design, program construction, testing, and support. Software engineering methods
rely on a set of basic principles that govern each area of the technology and include
modeling activities and other descriptive techniques.
Software engineering tools provide automated or semi-automated support for the
process and the methods. When tools are integrated so that information created by
one tool can be used by another, a system for the support of software development,
called computer-aided software engineering, is established. CASE combines software,
hardware, and a software engineering database (a repository containing important
information about analysis, design, program construction, and testing) to create a
software engineering environment analogous to CAD/CAE (computer-aided
design/engineering) for hardware.
2.1.2 A Generic View of Software Engineering
Engineering is the analysis, design, construction, verification, and management of
technical (or social) entities. Regardless of the entity to be engineered, the following
questions must be asked and answered:
• What is the problem to be solved?
• What characteristics of the entity are used to solve the problem?
technical (or social) entities. Regardless of the entity to be engineered, the following
questions must be asked and answered:
• What is the problem to be solved?
• What characteristics of the entity are used to solve the problem?
• How will the entity (and the solution) be realized?
• How will the entity be constructed?
• What approach will be used to uncover errors that were made in the design
and construction of the entity?
• How will the entity be supported over the long term, when corrections, adap-
tations, and enhancements are requested by users of the entity.
Throughout this book, we focus on a single entity—computer software. To engineer
software adequately, a software engineering process must be defined. In this section,
the generic characteristics of the software process are considered. Later in this chap-
ter, specific process models are addressed.
The work associated with software engineering can be categorized into three
generic phases, regardless of application area, project size, or complexity. Each phase
addresses one or more of the questions noted previously.
The definition phase focuses on what. That is, during definition, the software engi-
neer attempts to identify what information is to be processed, what function and per-
formance are desired, what system behavior can be expected, what interfaces are to
be established, what design constraints exist, and what validation criteria are required
to define a successful system. The key requirements of the system and the software
are identified. Although the methods applied during the definition phase will vary
depending on the software engineering paradigm (or combination of paradigms) that
is applied, three major tasks will occur in some form: system or information engi-
neering (Chapter 10), software project planning (Chapters 3, 5, 6, and 7), and require-
ments analysis (Chapters 11, 12, and 21).
The development phase focuses on how. That is, during development a software
engineer attempts to define how data are to be structured, how function is to be imple-
mented within a software architecture, how procedural details are to be implemented,
how interfaces are to be characterized, how the design will be translated into a pro-
gramming language (or nonprocedural language), and how testing will be performed.
The methods applied during the development phase will vary, but three specific tech-
nical tasks should always occur: software design (Chapters 13–16, and 22), code gen-
eration, and software testing (Chapters 17, 18, and 23).
• How will the entity be constructed?
• What approach will be used to uncover errors that were made in the design
and construction of the entity?
• How will the entity be supported over the long term, when corrections, adap-
tations, and enhancements are requested by users of the entity.
Throughout this book, we focus on a single entity—computer software. To engineer
software adequately, a software engineering process must be defined. In this section,
the generic characteristics of the software process are considered. Later in this chap-
ter, specific process models are addressed.
The work associated with software engineering can be categorized into three
generic phases, regardless of application area, project size, or complexity. Each phase
addresses one or more of the questions noted previously.
The definition phase focuses on what. That is, during definition, the software engi-
neer attempts to identify what information is to be processed, what function and per-
formance are desired, what system behavior can be expected, what interfaces are to
be established, what design constraints exist, and what validation criteria are required
to define a successful system. The key requirements of the system and the software
are identified. Although the methods applied during the definition phase will vary
depending on the software engineering paradigm (or combination of paradigms) that
is applied, three major tasks will occur in some form: system or information engi-
neering (Chapter 10), software project planning (Chapters 3, 5, 6, and 7), and require-
ments analysis (Chapters 11, 12, and 21).
The development phase focuses on how. That is, during development a software
engineer attempts to define how data are to be structured, how function is to be imple-
mented within a software architecture, how procedural details are to be implemented,
how interfaces are to be characterized, how the design will be translated into a pro-
gramming language (or nonprocedural language), and how testing will be performed.
The methods applied during the development phase will vary, but three specific tech-
nical tasks should always occur: software design (Chapters 13–16, and 22), code gen-
eration, and software testing (Chapters 17, 18, and 23).
The support phase focuses on change associated with error correction, adaptations
required as the software's environment evolves, and changes due to enhancements
brought about by changing customer requirements. The support phase reapplies the
steps of the definition and development phases but does so in the context of existing
software. Four types of change are encountered during the support phase:
Correction. Even with the best quality assurance activities, it is likely that the
customer will uncover defects in the software. Corrective maintenance changes
the software to correct defects.
Adaptation. Over time, the original environment (e.g., CPU, operating system,
business rules, external product characteristics) for which the software was
required as the software's environment evolves, and changes due to enhancements
brought about by changing customer requirements. The support phase reapplies the
steps of the definition and development phases but does so in the context of existing
software. Four types of change are encountered during the support phase:
Correction. Even with the best quality assurance activities, it is likely that the
customer will uncover defects in the software. Corrective maintenance changes
the software to correct defects.
Adaptation. Over time, the original environment (e.g., CPU, operating system,
business rules, external product characteristics) for which the software was
developed is likely to change. Adaptive maintenance results in modification to
the software to accommodate changes to its external environment.
Enhancement. As software is used, the customer/user will recognize addi-
tional functions that will provide benefit. Perfective maintenance extends the
software beyond its original functional requirements.
Prevention. Computer software deteriorates due to change, and because of
this, preventive maintenance, often called software reengineering, must be con-
ducted to enable the software to serve the needs of its end users. In essence,
preventive maintenance makes changes to computer programs so that they can
be more easily corrected, adapted, and enhanced.
In addition to these support activities, the users of software require continuing sup-
port. In-house technical assistants, telephone-help desks, and application-specific
Web sites are often implemented as part of the support phase.
Today, a growing population of legacy programs1 is forcing many companies to
pursue software reengineering strategies (Chapter 30). In a global sense, software
reengineering is often considered as part of business process reengineering.
The phases and related steps described in our generic view of software engineer-
ing are complemented by a number of umbrella activities. Typical activities in this cat-
egory include:
• Software project tracking and control
• Formal technical reviews
• Software quality assurance
• Software configuration management
• Document preparation and production
• Reusability management
• Measurement
• Risk management
Umbrella activities are applied throughout the software process and are discussed in
Parts Two and Five of this book.
the software to accommodate changes to its external environment.
Enhancement. As software is used, the customer/user will recognize addi-
tional functions that will provide benefit. Perfective maintenance extends the
software beyond its original functional requirements.
Prevention. Computer software deteriorates due to change, and because of
this, preventive maintenance, often called software reengineering, must be con-
ducted to enable the software to serve the needs of its end users. In essence,
preventive maintenance makes changes to computer programs so that they can
be more easily corrected, adapted, and enhanced.
In addition to these support activities, the users of software require continuing sup-
port. In-house technical assistants, telephone-help desks, and application-specific
Web sites are often implemented as part of the support phase.
Today, a growing population of legacy programs1 is forcing many companies to
pursue software reengineering strategies (Chapter 30). In a global sense, software
reengineering is often considered as part of business process reengineering.
The phases and related steps described in our generic view of software engineer-
ing are complemented by a number of umbrella activities. Typical activities in this cat-
egory include:
• Software project tracking and control
• Formal technical reviews
• Software quality assurance
• Software configuration management
• Document preparation and production
• Reusability management
• Measurement
• Risk management
Umbrella activities are applied throughout the software process and are discussed in
Parts Two and Five of this book.
SOFTWARE
In 1970, less than 1 percent of the public could have intelligently described what
"computer software" meant. Today, most professionals and many members of the
public at large feel that they understand software. But do they?
A textbook description of software might take the following form: Software is (1)
instructions (computer programs) that when executed provide desired function and per-
formance, (2) data structures that enable the programs to adequately manipulate infor-
mation, and (3) documents that describe the operation and use of the programs. There
is no question that other, more complete definitions could be offered. But we need
more than a formal definition.
1.2.1 Software Characteristics
To gain an understanding of software (and ultimately an understanding of software
engineering), it is important to examine the characteristics of software that make it
different from other things that human beings build. When hardware is built, the
human creative process (analysis, design, construction, testing) is ultimately trans-
lated into a physical form. If we build a new computer, our initial sketches, formal
design drawings, and breadboarded prototype evolve into a physical product (chips,
circuit boards, power supplies, etc.).
Software is a logical rather than a physical system element. Therefore, software
has characteristics that are considerably different than those of hardware:
1. Software is developed or engineered, it is not manufactured in the classical
sense.
Although some similarities exist between software development and hardware man-
ufacture, the two activities are fundamentally different. In both activities, high qual-
"computer software" meant. Today, most professionals and many members of the
public at large feel that they understand software. But do they?
A textbook description of software might take the following form: Software is (1)
instructions (computer programs) that when executed provide desired function and per-
formance, (2) data structures that enable the programs to adequately manipulate infor-
mation, and (3) documents that describe the operation and use of the programs. There
is no question that other, more complete definitions could be offered. But we need
more than a formal definition.
1.2.1 Software Characteristics
To gain an understanding of software (and ultimately an understanding of software
engineering), it is important to examine the characteristics of software that make it
different from other things that human beings build. When hardware is built, the
human creative process (analysis, design, construction, testing) is ultimately trans-
lated into a physical form. If we build a new computer, our initial sketches, formal
design drawings, and breadboarded prototype evolve into a physical product (chips,
circuit boards, power supplies, etc.).
Software is a logical rather than a physical system element. Therefore, software
has characteristics that are considerably different than those of hardware:
1. Software is developed or engineered, it is not manufactured in the classical
sense.
Although some similarities exist between software development and hardware man-
ufacture, the two activities are fundamentally different. In both activities, high qual-
ity is achieved through good design, but the manufacturing phase for hardware can
introduce quality problems that are nonexistent (or easily corrected) for software.
Both activities are dependent on people, but the relationship between people applied
and work accomplished is entirely different (see Chapter 7). Both activities require
the construction of a "product" but the approaches are different.
Software costs are concentrated in engineering. This means that software proj-
ects cannot be managed as if they were manufacturing projects.
2. Software doesn't "wear out."
Figure 1.1 depicts failure rate as a function of time for hardware. The relationship,
often called the "bathtub curve," indicates that hardware exhibits relatively high fail-
ure rates early in its life (these failures are often attributable to design or manufac-
turing defects); defects are corrected and the failure rate drops to a steady-state level
(ideally, quite low) for some period of time. As time passes, however, the failure rate
rises again as hardware components suffer from the cumulative affects of dust, vibra-
tion, abuse, temperature extremes, and many other environmental maladies. Stated
simply, the hardware begins to wear out.
Software is not susceptible to the environmental maladies that cause hardware to
wear out. In theory, therefore, the failure rate curve for software should take the form of
the “idealized curve” shown in Figure 1.2. Undiscovered defects will cause high failure
rates early in the life of a program. However, these are corrected (ideally, without intro-
ducing other errors) and the curve flattens as shown.The idealized curve is a gross over-
simplification of actual failure models (see Chapter 8 for more information) for software.
However, the implication is clear—software doesn't wear out. But it does deteriorate!
This seeming contradiction can best be explained by considering the “actual curve”
shown in Figure 1.2. During its life, software will undergo change (maintenance). As
introduce quality problems that are nonexistent (or easily corrected) for software.
Both activities are dependent on people, but the relationship between people applied
and work accomplished is entirely different (see Chapter 7). Both activities require
the construction of a "product" but the approaches are different.
Software costs are concentrated in engineering. This means that software proj-
ects cannot be managed as if they were manufacturing projects.
2. Software doesn't "wear out."
Figure 1.1 depicts failure rate as a function of time for hardware. The relationship,
often called the "bathtub curve," indicates that hardware exhibits relatively high fail-
ure rates early in its life (these failures are often attributable to design or manufac-
turing defects); defects are corrected and the failure rate drops to a steady-state level
(ideally, quite low) for some period of time. As time passes, however, the failure rate
rises again as hardware components suffer from the cumulative affects of dust, vibra-
tion, abuse, temperature extremes, and many other environmental maladies. Stated
simply, the hardware begins to wear out.
Software is not susceptible to the environmental maladies that cause hardware to
wear out. In theory, therefore, the failure rate curve for software should take the form of
the “idealized curve” shown in Figure 1.2. Undiscovered defects will cause high failure
rates early in the life of a program. However, these are corrected (ideally, without intro-
ducing other errors) and the curve flattens as shown.The idealized curve is a gross over-
simplification of actual failure models (see Chapter 8 for more information) for software.
However, the implication is clear—software doesn't wear out. But it does deteriorate!
This seeming contradiction can best be explained by considering the “actual curve”
shown in Figure 1.2. During its life, software will undergo change (maintenance). As
changes are made, it is likely that some new defects will be introduced, causing the
failure rate curve to spike as shown in Figure 1.2. Before the curve can return to the
original steady-state failure rate, another change is requested, causing the curve to
spike again. Slowly, the minimum failure rate level begins to rise—the software is
deteriorating due to change.
Another aspect of wear illustrates the difference between hardware and software.
When a hardware component wears out, it is replaced by a spare part. There are no
software spare parts. Every software failure indicates an error in design or in the
process through which design was translated into machine executable code. There-
fore, software maintenance involves considerably more complexity than hardware
maintenance.
3. Although the industry is moving toward component-based assembly, most
software continues to be custom built.
Consider the manner in which the control hardware for a computer-based product
is designed and built. The design engineer draws a simple schematic of the digital
circuitry, does some fundamental analysis to assure that proper function will be
achieved, and then goes to the shelf where catalogs of digital components exist. Each
integrated circuit (called an IC or a chip) has a part number, a defined and validated
function, a well-defined interface, and a standard set of integration guidelines. After
each component is selected, it can be ordered off the shelf.
As an engineering discipline evolves, a collection of standard design components
is created. Standard screws and off-the-shelf integrated circuits are only two of thou-
sands of standard components that are used by mechanical and electrical engineers
as they design new systems. The reusable components have been created so that the
engineer can concentrate on the truly innovative elements of a design, that is, the
failure rate curve to spike as shown in Figure 1.2. Before the curve can return to the
original steady-state failure rate, another change is requested, causing the curve to
spike again. Slowly, the minimum failure rate level begins to rise—the software is
deteriorating due to change.
Another aspect of wear illustrates the difference between hardware and software.
When a hardware component wears out, it is replaced by a spare part. There are no
software spare parts. Every software failure indicates an error in design or in the
process through which design was translated into machine executable code. There-
fore, software maintenance involves considerably more complexity than hardware
maintenance.
3. Although the industry is moving toward component-based assembly, most
software continues to be custom built.
Consider the manner in which the control hardware for a computer-based product
is designed and built. The design engineer draws a simple schematic of the digital
circuitry, does some fundamental analysis to assure that proper function will be
achieved, and then goes to the shelf where catalogs of digital components exist. Each
integrated circuit (called an IC or a chip) has a part number, a defined and validated
function, a well-defined interface, and a standard set of integration guidelines. After
each component is selected, it can be ordered off the shelf.
As an engineering discipline evolves, a collection of standard design components
is created. Standard screws and off-the-shelf integrated circuits are only two of thou-
sands of standard components that are used by mechanical and electrical engineers
as they design new systems. The reusable components have been created so that the
engineer can concentrate on the truly innovative elements of a design, that is, the
parts of the design that represent something new. In the hardware world, component
reuse is a natural part of the engineering process. In the software world, it is some-
thing that has only begun to be achieved on a broad scale.
A software component should be designed and implemented so that it can be
reused in many different programs. In the 1960s, we built scientific subroutine libraries
that were reusable in a broad array of engineering and scientific applications. These
subroutine libraries reused well-defined algorithms in an effective manner but had a
limited domain of application. Today, we have extended our view of reuse to encom-
pass not only algorithms but also data structure. Modern reusable components encap-
sulate both data and the processing applied to the data, enabling the software engineer
to create new applications from reusable parts. For example, today's graphical user
interfaces are built using reusable components that enable the creation of graphics
windows, pull-down menus, and a wide variety of interaction mechanisms. The data
structure and processing detail required to build the interface are contained with a
library of reusable components for interface construction.
1.2.2 Software Applications
Software may be applied in any situation for which a prespecified set of procedural
steps (i.e., an algorithm) has been defined (notable exceptions to this rule are expert
system software and neural network software). Information content and determinacy
are important factors in determining the nature of a software application. Content
refers to the meaning and form of incoming and outgoing information. For example,
many business applications use highly structured input data (a database) and pro-
duce formatted “reports.” Software that controls an automated machine (e.g., a
numerical control) accepts discrete data items with limited structure and produces
individual machine commands in rapid succession.
Information determinacy refers to the predictability of the order and timing of infor-
mation. An engineering analysis program accepts data that have a predefined order,
executes the analysis algorithm(s) without interruption, and produces resultant data
in report or graphical format. Such applications are determinate. A multiuser oper-
ating system, on the other hand, accepts inputs that have varied content and arbi-
trary timing, executes algorithms that can be interrupted by external conditions, and
produces output that varies as a function of environment and time. Applications with
these characteristics are indeterminate.
It is somewhat difficult to develop meaningful generic categories for software appli-
cations. As software complexity grows, neat compartmentalization disappears. The
following software areas indicate the breadth of potential applications:
System software. System software is a collection of programs written to service
other programs. Some system software (e.g., compilers, editors, and file manage-
ment utilities) process complex, but determinate, information structures. Other sys-
tems applications (e.g., operating system components, drivers, telecommunications
reuse is a natural part of the engineering process. In the software world, it is some-
thing that has only begun to be achieved on a broad scale.
A software component should be designed and implemented so that it can be
reused in many different programs. In the 1960s, we built scientific subroutine libraries
that were reusable in a broad array of engineering and scientific applications. These
subroutine libraries reused well-defined algorithms in an effective manner but had a
limited domain of application. Today, we have extended our view of reuse to encom-
pass not only algorithms but also data structure. Modern reusable components encap-
sulate both data and the processing applied to the data, enabling the software engineer
to create new applications from reusable parts. For example, today's graphical user
interfaces are built using reusable components that enable the creation of graphics
windows, pull-down menus, and a wide variety of interaction mechanisms. The data
structure and processing detail required to build the interface are contained with a
library of reusable components for interface construction.
1.2.2 Software Applications
Software may be applied in any situation for which a prespecified set of procedural
steps (i.e., an algorithm) has been defined (notable exceptions to this rule are expert
system software and neural network software). Information content and determinacy
are important factors in determining the nature of a software application. Content
refers to the meaning and form of incoming and outgoing information. For example,
many business applications use highly structured input data (a database) and pro-
duce formatted “reports.” Software that controls an automated machine (e.g., a
numerical control) accepts discrete data items with limited structure and produces
individual machine commands in rapid succession.
Information determinacy refers to the predictability of the order and timing of infor-
mation. An engineering analysis program accepts data that have a predefined order,
executes the analysis algorithm(s) without interruption, and produces resultant data
in report or graphical format. Such applications are determinate. A multiuser oper-
ating system, on the other hand, accepts inputs that have varied content and arbi-
trary timing, executes algorithms that can be interrupted by external conditions, and
produces output that varies as a function of environment and time. Applications with
these characteristics are indeterminate.
It is somewhat difficult to develop meaningful generic categories for software appli-
cations. As software complexity grows, neat compartmentalization disappears. The
following software areas indicate the breadth of potential applications:
System software. System software is a collection of programs written to service
other programs. Some system software (e.g., compilers, editors, and file manage-
ment utilities) process complex, but determinate, information structures. Other sys-
tems applications (e.g., operating system components, drivers, telecommunications
processors) process largely indeterminate data. In either case, the system software
area is characterized by heavy interaction with computer hardware; heavy usage by
multiple users; concurrent operation that requires scheduling, resource sharing, and
sophisticated process management; complex data structures; and multiple external
interfaces.
Real-time software. Software that monitors/analyzes/controls real-world events
as they occur is called real time. Elements of real-time software include a data gath-
ering component that collects and formats information from an external environ-
ment, an analysis component that transforms information as required by the
application, a control/output component that responds to the external environment,
and a monitoring component that coordinates all other components so that real-time
response (typically ranging from 1 millisecond to 1 second) can be maintained.
Business software. Business information processing is the largest single software
application area. Discrete "systems" (e.g., payroll, accounts receivable/payable, inven-
tory) have evolved into management information system (MIS) software that accesses
one or more large databases containing business information. Applications in this
area restructure existing data in a way that facilitates business operations or man-
agement decision making. In addition to conventional data processing application,
business software applications also encompass interactive computing (e.g., point-
of-sale transaction processing).
Engineering and scientific software. Engineering and scientific software have
been characterized by "number crunching" algorithms. Applications range from astron-
omy to volcanology, from automotive stress analysis to space shuttle orbital dynam-
ics, and from molecular biology to automated manufacturing. However, modern
applications within the engineering/scientific area are moving away from conven-
tional numerical algorithms. Computer-aided design, system simulation, and other
interactive applications have begun to take on real-time and even system software
characteristics.
Embedded software. Intelligent products have become commonplace in nearly
every consumer and industrial market. Embedded software resides in read-only mem-
ory and is used to control products and systems for the consumer and industrial mar-
kets. Embedded software can perform very limited and esoteric functions (e.g., keypad
control for a microwave oven) or provide significant function and control capability
(e.g., digital functions in an automobile such as fuel control, dashboard displays, and
braking systems).
Personal computer software. The personal computer software market has bur-
geoned over the past two decades. Word processing, spreadsheets, computer graph-
ics, multimedia, entertainment, database management, personal and business financial
applications, external network, and database access are only a few of hundreds of
applications.
Web-based software. The Web pages retrieved by a browser are software that
incorporates executable instructions (e.g., CGI, HTML, Perl, or Java), and data (e.g.,
area is characterized by heavy interaction with computer hardware; heavy usage by
multiple users; concurrent operation that requires scheduling, resource sharing, and
sophisticated process management; complex data structures; and multiple external
interfaces.
Real-time software. Software that monitors/analyzes/controls real-world events
as they occur is called real time. Elements of real-time software include a data gath-
ering component that collects and formats information from an external environ-
ment, an analysis component that transforms information as required by the
application, a control/output component that responds to the external environment,
and a monitoring component that coordinates all other components so that real-time
response (typically ranging from 1 millisecond to 1 second) can be maintained.
Business software. Business information processing is the largest single software
application area. Discrete "systems" (e.g., payroll, accounts receivable/payable, inven-
tory) have evolved into management information system (MIS) software that accesses
one or more large databases containing business information. Applications in this
area restructure existing data in a way that facilitates business operations or man-
agement decision making. In addition to conventional data processing application,
business software applications also encompass interactive computing (e.g., point-
of-sale transaction processing).
Engineering and scientific software. Engineering and scientific software have
been characterized by "number crunching" algorithms. Applications range from astron-
omy to volcanology, from automotive stress analysis to space shuttle orbital dynam-
ics, and from molecular biology to automated manufacturing. However, modern
applications within the engineering/scientific area are moving away from conven-
tional numerical algorithms. Computer-aided design, system simulation, and other
interactive applications have begun to take on real-time and even system software
characteristics.
Embedded software. Intelligent products have become commonplace in nearly
every consumer and industrial market. Embedded software resides in read-only mem-
ory and is used to control products and systems for the consumer and industrial mar-
kets. Embedded software can perform very limited and esoteric functions (e.g., keypad
control for a microwave oven) or provide significant function and control capability
(e.g., digital functions in an automobile such as fuel control, dashboard displays, and
braking systems).
Personal computer software. The personal computer software market has bur-
geoned over the past two decades. Word processing, spreadsheets, computer graph-
ics, multimedia, entertainment, database management, personal and business financial
applications, external network, and database access are only a few of hundreds of
applications.
Web-based software. The Web pages retrieved by a browser are software that
incorporates executable instructions (e.g., CGI, HTML, Perl, or Java), and data (e.g.,
hypertext and a variety of visual and audio formats). In essence, the network becomes
a massive computer providing an almost unlimited software resource that can be
accessed by anyone with a modem.
Artificial intelligence software. Artificial intelligence (AI) software makes use
of nonnumerical algorithms to solve complex problems that are not amenable to
computation or straightforward analysis. Expert systems, also called knowledge-
based systems, pattern recognition (image and voice), artificial neural networks,
theorem proving, and game playing are representative of applications within this
category.
a massive computer providing an almost unlimited software resource that can be
accessed by anyone with a modem.
Artificial intelligence software. Artificial intelligence (AI) software makes use
of nonnumerical algorithms to solve complex problems that are not amenable to
computation or straightforward analysis. Expert systems, also called knowledge-
based systems, pattern recognition (image and voice), artificial neural networks,
theorem proving, and game playing are representative of applications within this
category.
THE EVOLVING ROLE OF SOFTWARE
Today, software takes on a dual role. It is a product and, at the same time, the vehi-
cle for delivering a product. As a product, it delivers the computing potential embod-
ied by computer hardware or, more broadly, a network of computers that are accessible
by local hardware. Whether it resides within a cellular phone or operates inside a
mainframe computer, software is an information transformer—producing, manag-
ing, acquiring, modifying, displaying, or transmitting information that can be as sim-
ple as a single bit or as complex as a multimedia presentation. As the vehicle used
to deliver the product, software acts as the basis for the control of the computer (oper-
ating systems), the communication of information (networks), and the creation and
control of other programs (software tools and environments).
Software delivers the most important product of our time—information. Software
transforms personal data (e.g., an individual’s financial transactions) so that the data
can be more useful in a local context; it manages business information to enhance
competitiveness; it provides a gateway to worldwide information networks (e.g., Inter-
net) and provides the means for acquiring information in all of its forms.
The role of computer software has undergone significant change over a time span
of little more than 50 years. Dramatic improvements in hardware performance, pro-
found changes in computing architectures, vast increases in memory and storage
capacity, and a wide variety of exotic input and output options have all precipitated
more sophisticated and complex computer-based systems. Sophistication and com-
plexity can produce dazzling results when a system succeeds, but they can also pose
huge problems for those who must build complex systems.
Popular books published during the 1970s and 1980s provide useful historical
insight into the changing perception of computers and software and their impact on
our culture. Osborne [OSB79] characterized a "new industrial revolution." Toffler
[TOF80] called the advent of microelectronics part of "the third wave of change" in
human history, and Naisbitt [NAI82] predicted a transformation from an industrial
society to an "information society." Feigenbaum and McCorduck [FEI83] suggested
that information and knowledge (controlled by computers) would be the focal point
for power in the twenty-first century, and Stoll [STO89] argued that the "electronic
community" created by networks and software was the key to knowledge interchange
throughout the world.
As the 1990s began, Toffler [TOF90] described a "power shift" in which old power
structures (governmental, educational, industrial, economic, and military) disinte-
grate as computers and software lead to a "democratization of knowledge." Yourdon
[YOU92] worried that U.S. companies might loose their competitive edge in software-
related businesses and predicted “the decline and fall of the American programmer.”
Hammer and Champy [HAM93] argued that information technologies were to play a
pivotal role in the “reengineering of the corporation.” During the mid-1990s, the per-
vasiveness of computers and software spawned a rash of books by “neo-Luddites”
(e.g., Resisting the Virtual Life, edited by James Brook and Iain Boal and The Future
Does Not Compute by Stephen Talbot). These authors demonized the computer, empha-
sizing legitimate concerns but ignoring the profound benefits that have already been
realized. [LEV95]
During the later 1990s, Yourdon [YOU96] re-evaluated the prospects for the
software professional and suggested the “the rise and resurrection” of the Ameri-
can programmer. As the Internet grew in importance, his change of heart proved
to be correct. As the twentieth century closed, the focus shifted once more, this
time to the impact of the Y2K “time bomb” (e.g., [YOU98b], [DEJ98], [KAR99]).
Although the predictions of the Y2K doomsayers were incorrect, their popular
writings drove home the pervasiveness of software in our lives. Today, “ubiquitous
computing” [NOR98] has spawned a generation of information appliances that
have broadband connectivity to the Web to provide “a blanket of connectedness
over our homes, offices and motorways” [LEV99]. Software’s role continues to
expand.
The lone programmer of an earlier era has been replaced by a team of software
specialists, each focusing on one part of the technology required to deliver a com-
plex application. And yet, the same questions asked of the lone programmer are being
asked when modern computer-based systems are built:
• Why does it take so long to get software finished?
• Why are development costs so high?
• Why can't we find all the errors before we give the software to customers?
• Why do we continue to have difficulty in measuring progress as software is
being developed?
These, and many other questions,1 are a manifestation of the concern about soft-
ware and the manner in which it is developed—a concern that has lead to the adop-
tion of software engineering practice.
cle for delivering a product. As a product, it delivers the computing potential embod-
ied by computer hardware or, more broadly, a network of computers that are accessible
by local hardware. Whether it resides within a cellular phone or operates inside a
mainframe computer, software is an information transformer—producing, manag-
ing, acquiring, modifying, displaying, or transmitting information that can be as sim-
ple as a single bit or as complex as a multimedia presentation. As the vehicle used
to deliver the product, software acts as the basis for the control of the computer (oper-
ating systems), the communication of information (networks), and the creation and
control of other programs (software tools and environments).
Software delivers the most important product of our time—information. Software
transforms personal data (e.g., an individual’s financial transactions) so that the data
can be more useful in a local context; it manages business information to enhance
competitiveness; it provides a gateway to worldwide information networks (e.g., Inter-
net) and provides the means for acquiring information in all of its forms.
The role of computer software has undergone significant change over a time span
of little more than 50 years. Dramatic improvements in hardware performance, pro-
found changes in computing architectures, vast increases in memory and storage
capacity, and a wide variety of exotic input and output options have all precipitated
more sophisticated and complex computer-based systems. Sophistication and com-
plexity can produce dazzling results when a system succeeds, but they can also pose
huge problems for those who must build complex systems.
Popular books published during the 1970s and 1980s provide useful historical
insight into the changing perception of computers and software and their impact on
our culture. Osborne [OSB79] characterized a "new industrial revolution." Toffler
[TOF80] called the advent of microelectronics part of "the third wave of change" in
human history, and Naisbitt [NAI82] predicted a transformation from an industrial
society to an "information society." Feigenbaum and McCorduck [FEI83] suggested
that information and knowledge (controlled by computers) would be the focal point
for power in the twenty-first century, and Stoll [STO89] argued that the "electronic
community" created by networks and software was the key to knowledge interchange
throughout the world.
As the 1990s began, Toffler [TOF90] described a "power shift" in which old power
structures (governmental, educational, industrial, economic, and military) disinte-
grate as computers and software lead to a "democratization of knowledge." Yourdon
[YOU92] worried that U.S. companies might loose their competitive edge in software-
related businesses and predicted “the decline and fall of the American programmer.”
Hammer and Champy [HAM93] argued that information technologies were to play a
pivotal role in the “reengineering of the corporation.” During the mid-1990s, the per-
vasiveness of computers and software spawned a rash of books by “neo-Luddites”
(e.g., Resisting the Virtual Life, edited by James Brook and Iain Boal and The Future
Does Not Compute by Stephen Talbot). These authors demonized the computer, empha-
sizing legitimate concerns but ignoring the profound benefits that have already been
realized. [LEV95]
During the later 1990s, Yourdon [YOU96] re-evaluated the prospects for the
software professional and suggested the “the rise and resurrection” of the Ameri-
can programmer. As the Internet grew in importance, his change of heart proved
to be correct. As the twentieth century closed, the focus shifted once more, this
time to the impact of the Y2K “time bomb” (e.g., [YOU98b], [DEJ98], [KAR99]).
Although the predictions of the Y2K doomsayers were incorrect, their popular
writings drove home the pervasiveness of software in our lives. Today, “ubiquitous
computing” [NOR98] has spawned a generation of information appliances that
have broadband connectivity to the Web to provide “a blanket of connectedness
over our homes, offices and motorways” [LEV99]. Software’s role continues to
expand.
The lone programmer of an earlier era has been replaced by a team of software
specialists, each focusing on one part of the technology required to deliver a com-
plex application. And yet, the same questions asked of the lone programmer are being
asked when modern computer-based systems are built:
• Why does it take so long to get software finished?
• Why are development costs so high?
• Why can't we find all the errors before we give the software to customers?
• Why do we continue to have difficulty in measuring progress as software is
being developed?
These, and many other questions,1 are a manifestation of the concern about soft-
ware and the manner in which it is developed—a concern that has lead to the adop-
tion of software engineering practice.
THE PRODUCT
The warnings began more than a decade before the event, but no one paid
much attention. With less than two years to the deadline, the media
picked up the story. Then government officials voiced their concern, busi-
ness and industry leaders committed vast sums of money, and finally, dire warn-
ings of pending catastrophe penetrated the public’s consciousness. Software,
in the guise of the now-infamous Y2K bug, would fail and, as a result, stop the
world as we then knew it.
As we watched and wondered during the waning months of 1999, I couldn’t
help thinking of an unintentionally prophetic paragraph contained on the first
page of the fourth edition of this book. It stated:
Computer software has become a driving force. It is the engine that drives business
decision making. It serves as the basis for modern scientific investigation and engi-
neering problem solving. It is a key factor that differentiates modern products and
services. It is embedded in systems of all kinds: transportation, medical, telecom-
munications, military, industrial processes, entertainment, office products, . . . the
list is almost endless. Software is virtually inescapable in a modern world. And as
we move into the twenty-first century, it will become the driver for new advances in
everything from elementary education to genetic engineering.
In the five years since the fourth edition of this book was written, the role of soft-
ware as the “driving force” has become even more obvious. A software-driven Inter-
net has spawned its own $500 billion economy. In the euphoria created by the promise
of a new economic paradigm, Wall Street investors gave tiny “dot-com” companies
billion dollar valuations before these start-ups produced a dollar in sales. New
software-driven industries have arisen and old ones that have not adapted to the new
driving force are now threatened with extinction. The United States government has
litigated against the software’s industry’s largest company, just as it did in earlier eras
when it moved to stop monopolistic practices in the oil and steel industries.
Software’s impact on our society and culture continues to be profound. As its
importance grows, the software community continually attempts to develop tech-
nologies that will make it easier, faster, and less expensive to build high-quality com-
puter programs. Some of these technologies are targeted at a specific application
domain (e.g., Web-site design and implementation); others focus on a technology
domain (e.g., object-oriented systems); and still others are broad-based (e.g., oper-
ating systems such as LINUX). However, we have yet to develop a software technol-
ogy that does it all, and the likelihood of one arising in the future is small. And yet,
people bet their jobs, their comfort, their safety, their entertainment, their decisions,
and their very lives on computer software. It better be right.
This book presents a framework that can be used by those who build computer
software—people who must get it right. The technology encompasses a process, a
set of methods, and an array of tools that we call software engineering.
much attention. With less than two years to the deadline, the media
picked up the story. Then government officials voiced their concern, busi-
ness and industry leaders committed vast sums of money, and finally, dire warn-
ings of pending catastrophe penetrated the public’s consciousness. Software,
in the guise of the now-infamous Y2K bug, would fail and, as a result, stop the
world as we then knew it.
As we watched and wondered during the waning months of 1999, I couldn’t
help thinking of an unintentionally prophetic paragraph contained on the first
page of the fourth edition of this book. It stated:
Computer software has become a driving force. It is the engine that drives business
decision making. It serves as the basis for modern scientific investigation and engi-
neering problem solving. It is a key factor that differentiates modern products and
services. It is embedded in systems of all kinds: transportation, medical, telecom-
munications, military, industrial processes, entertainment, office products, . . . the
list is almost endless. Software is virtually inescapable in a modern world. And as
we move into the twenty-first century, it will become the driver for new advances in
everything from elementary education to genetic engineering.
In the five years since the fourth edition of this book was written, the role of soft-
ware as the “driving force” has become even more obvious. A software-driven Inter-
net has spawned its own $500 billion economy. In the euphoria created by the promise
of a new economic paradigm, Wall Street investors gave tiny “dot-com” companies
billion dollar valuations before these start-ups produced a dollar in sales. New
software-driven industries have arisen and old ones that have not adapted to the new
driving force are now threatened with extinction. The United States government has
litigated against the software’s industry’s largest company, just as it did in earlier eras
when it moved to stop monopolistic practices in the oil and steel industries.
Software’s impact on our society and culture continues to be profound. As its
importance grows, the software community continually attempts to develop tech-
nologies that will make it easier, faster, and less expensive to build high-quality com-
puter programs. Some of these technologies are targeted at a specific application
domain (e.g., Web-site design and implementation); others focus on a technology
domain (e.g., object-oriented systems); and still others are broad-based (e.g., oper-
ating systems such as LINUX). However, we have yet to develop a software technol-
ogy that does it all, and the likelihood of one arising in the future is small. And yet,
people bet their jobs, their comfort, their safety, their entertainment, their decisions,
and their very lives on computer software. It better be right.
This book presents a framework that can be used by those who build computer
software—people who must get it right. The technology encompasses a process, a
set of methods, and an array of tools that we call software engineering.
Subscribe to:
Posts (Atom)