THE LINEAR SEQUENTIAL MODEL Sometimes called the classic life cycle or the waterfall model, the linear sequential model
2.4 THE LINEAR SEQUENTIAL MODEL Sometimes called the classic life cycle or the waterfall model, the linear sequential model
suggests a systematic, sequential approach 5 to software development that begins at the system level and progresses through analysis, design, coding, testing, and sup- port. Figure 2.4 illustrates the linear sequential model for software engineering. Mod- eled after a conventional engineering cycle, the linear sequential model encompasses the following activities:
System/information engineering and modeling. Because software is always part of a larger system (or business), work begins by establishing requirements for all system elements and then allocating some subset of these requirements to soft- ware. This system view is essential when software must interact with other elements such as hardware, people, and databases. System engineering and analysis encom- pass requirements gathering at the system level with a small amount of top level
4 Fractals were originally proposed for geometric representations. A pattern is defined and then applied recursively at successively smaller scales; patterns fall inside patterns. 5 Although the original waterfall model proposed by Winston Royce [ROY70] made provision for “feedback loops,” the vast majority of organizations that apply this process model treat it as if it were strictly linear.
CHAPTER 2
THE PROCESS
F I G U R E 2.4
The linear sequential model
System/information
design and analysis. Information engineering encompasses requirements gathering at the strategic business level and at the business area level. Software requirements analysis. The requirements gathering process is intensi- fied and focused specifically on software. To understand the nature of the program(s) to be built, the software engineer ("analyst") must understand the information domain (described in Chapter 11) for the software, as well as required function, behavior, per- formance, and interface. Requirements for both the system and the software are doc- umented and reviewed with the customer. Design. Software design is actually a multistep process that focuses on four distinct attributes of a program: data structure, software architecture, interface representa- tions, and procedural (algorithmic) detail. The design process translates requirements into a representation of the software that can be assessed for quality before coding
Although the linear begins. Like requirements, the design is documented and becomes part of the soft- model is often derided ware configuration.
as “old fashioned,” it Code generation. The design must be translated into a machine-readable form. remains a reasonable
The code generation step performs this task. If design is performed in a detailed man- approach when
ner, code generation can be accomplished mechanistically. requirements are well
understood. Testing. Once code has been generated, program testing begins. The testing process focuses on the logical internals of the software, ensuring that all statements have been tested, and on the functional externals; that is, conducting tests to uncover errors and ensure that defined input will produce actual results that agree with required results. Support. Software will undoubtedly undergo change after it is delivered to the cus- tomer (a possible exception is embedded software). Change will occur because errors have been encountered, because the software must be adapted to accommodate changes in its external environment (e.g., a change required because of a new oper- ating system or peripheral device), or because the customer requires functional or performance enhancements. Software support/maintenance reapplies each of the preceding phases to an existing program rather than a new one.
30 PA R T O N E THE PRODUCT AND THE PROCESS
The linear sequential model is the oldest and the most widely used paradigm for software engineering. However, criticism of the paradigm has caused even active supporters to question its efficacy [HAN95]. Among the problems that are sometimes encountered when the linear sequential model is applied are:
1. Real projects rarely follow the sequential flow that the model proposes. Although the linear model can accommodate iteration, it does so indirectly. As a result, changes can cause confusion as the project team proceeds.
? 2. It is often difficult for the customer to state all requirements explicitly. The
Why does
the linear
linear sequential model requires this and has difficulty accommodating the
model sometimes
natural uncertainty that exists at the beginning of many projects.
fail?
3. The customer must have patience. A working version of the program(s) will not be available until late in the project time-span. A major blunder, if unde- tected until the working program is reviewed, can be disastrous.
In an interesting analysis of actual projects Bradac [BRA94], found that the linear nature of the classic life cycle leads to “blocking states” in which some project team members must wait for other members of the team to complete dependent tasks. In fact, the time spent waiting can exceed the time spent on productive work! The block- ing state tends to be more prevalent at the beginning and end of a linear sequential process.
Each of these problems is real. However, the classic life cycle paradigm has a def- inite and important place in software engineering work. It provides a template into which methods for analysis, design, coding, testing, and support can be placed. The classic life cycle remains a widely used procedural model for software engineering. While it does have weaknesses, it is significantly better than a haphazard approach to software development.
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