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.
.
No comments:
Post a Comment