SOFTWARE MODELS-5

LINEAR SEQUENTIAL MODEL


Sometimes called the classic life cycle or the waterfall model, the linear sequential model
suggests a systematic, sequential approach5 to software development that begins at
the system level and progresses through analysis, design, coding, testing, and support.
Figure illustrates the linear sequential model for software engineering. Modeled
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 software.
This system view is essential when software must interact with other elements
such as hardware, people, and databases. System engineering and analysis encompass
requirements gathering at the system level with a small amount of top level 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 intensified
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, performance,
and interface. Requirements for both the system and the software are documented
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 representations,
and procedural (algorithmic) detail. The design process translates requirements
into a representation of the software that can be assessed for quality before coding
begins. Like requirements, the design is documented and becomes part of the software
configuration.
Code generation. The design must be translated into a machine-readable form.
The code generation step performs this task. If design is performed in a detailed manner,
code generation can be accomplished mechanistically.
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 customer
(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 operating
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 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
linear sequential model requires this and has difficulty accommodating the
natural uncertainty that exists at the beginning of many projects.
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 undetected
until the working program is reviewed, can be disastrous.
In an interesting analysis of actual projects Bradac, 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 blocking
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 definite
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.

Read more...

SOFTWARE MODELS-4

RAD MODEL



Rapid application development (RAD) is an incremental software development process
model that emphasizes an extremely short development cycle. The RAD model is a
“high-speed” adaptation of the linear sequential model in which rapid development
is achieved by using component-based construction. If requirements are well understood
and project scope is constrained, the RAD process enables a development team
to create a “fully functional system” within very short time periods.Used primarily for information systems applications, the RAD approach
encompasses the following phases.
Business modeling. The information flow among business functions is modeled in
a way that answers the following questions: What information drives the business
process? What information is generated? Who generates it? Where does the information
go? Who processes it?
Data modeling. The information flow defined as part of the business modeling phase
is refined into a set of data objects that are needed to support the business. The char-

acteristics (called attributes) of each object are identified and the relationships between
these objects defined.

Process modeling. The data objects defined in the data modeling phase are transformed
to achieve the information flow necessary to implement a business function.
Processing descriptions are created for adding, modifying, deleting, or retrieving a
data object.
Application generation. RAD assumes the use of fourth generation techniques
. Rather than creating software using conventional third generation
programming languages the RAD process works to reuse existing program components
(when possible) or create reusable components (when necessary). In all cases,
automated tools are used to facilitate construction of the software.
Testing and turnover. Since the RAD process emphasizes reuse, many of the program
components have already been tested. This reduces overall testing time. However,
new components must be tested and all interfaces must be fully exercised.The RAD process model is illustrated in Figure. Obviously, the time constraints
imposed on a RAD project demand “scalable scope” . If a business application
can be modularized in a way that enables each major function to be completed
in less than three months (using the approach described previously), it is a candidate
for RAD. Each major function can be addressed by a separate RAD team and then
integrated to form a whole.
Like all process models, the RAD approach has drawbacks :
• For large but scalable projects, RAD requires sufficient human resources to
create the right number of RAD teams.
• RAD requires developers and customers who are committed to the rapid-fire
activities necessary to get a system complete in a much abbreviated time
frame. If commitment is lacking from either constituency, RAD projects will
fail.
• Not all types of applications are appropriate for RAD. If a system cannot be
properly modularized, building the components necessary for RAD will be
problematic. If high performance is an issue and performance is to be
achieved through tuning the interfaces to system components, the RAD
approach may not work.
• RAD is not appropriate when technical risks are high. This occurs when a new
application makes heavy use of new technology or when the new software
requires a high degree of interoperability with existing computer programs.

Read more...

SOFTWARE MODELS-3

PROTOTYPING MODEL



The prototyping paradigm begins with requirements gathering. Developer
and customer meet and define the overall objectives for the software, identify
whatever requirements are known, and outline areas where further definition is
mandatory. A "quick design" then occurs. The quick design focuses on a representation
of those aspects of the software that will be visible to the customer/user (e.g.,
input approaches and output formats). The quick design leads to the construction of a prototype. The prototype is evaluated by the customer/user and used to refinerequirements for the software to be developed. Iteration occurs as the prototype is
tuned to satisfy the needs of the customer, while at the same time enabling the developer
to better understand what needs to be done.
Ideally, the prototype serves as a mechanism for identifying software requirements.
If a working prototype is built, the developer attempts to use existing program fragments
or applies tools (e.g., report generators, window managers) that enable working
programs to be generated quickly.
In most projects, the first system built is barely usable. It may be too slow, too big, awkward
in use or all three. There is no alternative but to start again, smarting but smarter, and build
a redesigned version in which these problems are solved . . . When a new system concept
or new technology is used, one has to build a system to throw away, for even the best planning
is not so omniscient as to get it right the first time. The management question, therefore,
is not whether to build a pilot system and throw it away. You will do that. The only
question is whether to plan in advance to build a throwaway, or to promise to deliver the
throwaway to customers . . .

The prototype can serve as "the first system." The one that Brooks recommends
we throw away. But this may be an idealized view. It is true that both customers and
developers like the prototyping paradigm. Users get a feel for the actual system and developers get to build something immediately. Yet, prototyping can also be problematic
for the following reasons:
1. The customer sees what appears to be a working version of the software,
unaware that the prototype is held together “with chewing gum and baling
wire,” unaware that in the rush to get it working no one has considered overall
software quality or long-term maintainability. When informed that the
product must be rebuilt so that high levels of quality can be maintained, the
customer cries foul and demands that "a few fixes" be applied to make the
prototype a working product. Too often, software development management
relents.
2. The developer often makes implementation compromises in order to get a
prototype working quickly. An inappropriate operating system or programming
language may be used simply because it is available and known; an
inefficient algorithm may be implemented simply to demonstrate capability.
After a time, the developer may become familiar with these choices and forget
all the reasons why they were inappropriate. The less-than-ideal choice
has now become an integral part of the system.
Although problems can occur, prototyping can be an effective paradigm for software
engineering. The key is to define the rules of the game at the beginning; that is,
the customer and developer must both agree that the prototype is built to serve as a
mechanism for defining requirements. It is then discarded (at least in part) and the
actual software is engineered with an eye toward quality and maintainability.

Read more...