S O F T WA R E P R O C E S S M O D E L S To solve actual problems in an industry setting, a software engineer or a team of engi-
2.3 S O F T WA R E P R O C E S S M O D E L S 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- “Too often, software
work follows the ods, and tools layers described in Section 2.1.1 and the generic phases discussed in first law of bicycling:
Section 2.1.2. This strategy is often referred to as a process model or a software engi- No matter where
neering paradigm. A process model for software engineering is chosen based on the you're going, it's
nature of the project and application, the methods and tools to be used, and the con- uphill and against
trols and deliverables that are required. In an intriguing paper on the nature of the the wind.”
author unknown
software process, L. B. S. Raccoon [RAC95] uses fractals as the basis for a discussion of the true nature of the software process.
CHAPTER 2
THE PROCESS
F I G U R E 2.3
(a) The phases
Problem
of a problem
definition
solving loop [RAC95]
(b) The phases within phases
Status
Technical
of the problem quo
development
solving loop [RAC95]
Solution integration
(a)
quo status
quo problem
quo status
definition problem
definiton problem
Status
development quo technical
status quo
integration solution
definiton problem
Status quo
development technical
integration solution
(b)
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
28 PA R T O N E THE PRODUCT AND THE PROCESS
even at the line of code level. Therefore, a fractal 4 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-
All stages of a ment, and solution integration—coexist simultaneously at some level of detail. Given software process—
the recursive nature of Figure 2.3b, the four stages discussed apply equally to the status quo, problem
definition, technical analysis of a complete application and to the generation of a small segment of code. development, and
Raccoon [RAC95] suggests a “Chaos model” that describes “software develop- solution integration—
ment [as] a continuum from the user to the developer to the technology.” As work coexist simultaneously
progresses toward a complete system, the stages are applied recursively to user needs at some level of detail. 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.
Parts
» The Concurrent Development Model
» SUMMARY Software engineering is a discipline that integrates process, methods, and tools for
» PEOPLE In a study published by the IEEE [CUR88], the engineering vice presidents of three
» THE PROCESS The generic phases that characterize the software process—definition, development,
» THE PROJECT In order to manage a successful software project, we must understand what can go
» METRICS IN THE PROCESS AND PROJECT DOMAINS
» Extended Function Point Metrics
» METRICS FOR SOFTWARE QUALITY
» INTEGRATING METRICS WITHIN THE SOFTWARE PROCESS
» METRICS FOR SMALL ORGANIZATIONS
» ESTABLISHING A SOFTWARE METRICS PROGRAM
» Obtaining Information Necessary for Scope
» An Example of LOC-Based Estimation
» QUALITY CONCEPTS 1 It has been said that no two snowflakes are alike. Certainly when we watch snow
» SUMMARY Software quality assurance is an umbrella activity that is applied at each step in the
» R diagram 1.4 <part-of> data model; data model <part-of> design specification;
» SYSTEM MODELING Every computer-based system can be modeled as an information transform using an
» Facilitated Application Specification Techniques
» Data Objects, Attributes, and Relationships
» Entity/Relationship Diagrams
» Hatley and Pirbhai Extensions
» Creating an Entity/Relationship Diagram
» SUMMARY Design is the technical kernel of software engineering. During design, progressive
» Data Modeling, Data Structures, Databases, and the Data Warehouse
» Data Design at the Component Level
» A Brief Taxonomy of Styles and Patterns
» Quantitative Guidance for Architectural Design
» Isolate the transform center by specifying incoming and outgoing
» SUMMARY Software architecture provides a holistic view of the system to be built. It depicts the
» The User Interface Design Process
» Defining Interface Objects and Actions
» D E S I G N E VA L U AT I O N
» Testing for Real-Time Systems
» Organizing for Software Testing
» Criteria for Completion of Testing
» The Transition to a Quantitative View
» The Attributes of Effective Software Metrics
» Architectural Design Metrics
» Component-Level Design Metrics
» SUMMARY Software metrics provide a quantitative way to assess the quality of internal product
» Encapsulation, Inheritance, and Polymorphism
» Identifying Classes and Objects
» The Common Process Framework for OO
» OO Project Metrics and Estimation
» Event Identification with Use-Cases
» SUMMARY Object-oriented analysis methods enable a software engineer to model a problem by
» Partitioning the Analysis Model
» Designing Algorithms and Data Structures
» Program Components and Interfaces
» SUMMARY Object-oriented design translates the OOA model of the real world into an
» Testing Surface Structure and Deep Structure
» Deficiencies of Less Formal Approaches 1
» What Makes Cleanroom Different?
» Design Refinement and Verification
» SUMMARY Cleanroom software engineering is a formal approach to software development that
» Structural Modeling and Structure Points
» Describing Reusable Components
» SUMMARY Component-based software engineering offers inherent benefits in software quality,
» Guidelines for Distributing Application Subsystems
» Middleware and Object Request Broker Architectures
» An Overview of a Design Approach
» Consider expert Web developer will create a complete design, but time and cost can be appropriate
» A Software Reengineering Process Model
» Reverse Engineering to Understand Data
» Forward Engineering for Client/Server Architectures
» SUMMARY Reengineering occurs at two different levels of abstraction. At the business level,
Show more