Information System Development Life Cycle Models - High Level Models and Methodologies for Information Systems - page 28

continuing this downward ladder, there is a parallel structure that moves upward
from the coding stage, giving the model its distinct V shape. The upward ladder
describes each of the testing steps that follows coding, starting with unit testing and
ending with acceptance testing, the

final step before final release (Mathur and Malik

2010 ).
In that sense, the V-Model describes three successive layers of system devel-
opment that can be described as requirements (overall system), high-level design
(system architecture), and low-level design (software components). To each of
these layers, there is a corresponding layer of planning and testing. Planning is,
indeed, the axis that stands between the left and right ladders that compose the V, as
it is the mediating action set between design and testing (Munassar and Govardhan
2010 ).
The core objective of the V life cycle model is to illustrate the importance of the
relationship between development and testing tasks. Nonetheless, the success of a
project is also determined by its maintenance structure. To accommodate this
reality, Mathur and Malik ( 2010 ) proposed an expanded version of the V-Model,
called the advanced V-Model, that incorporates both testing and maintenance
activities into the life cycle. This adds a third structure, or

“ ”

branch, to the model

that re final product is

released, so that proper quality measurement, troubleshooting, and general main-
tenance can be ensured.
Since the V-Model addresses its errors shortly after they are identi

ects the introduction of testing mechanisms after the

ed, it
becomes less expensive to resolve them, which is perhaps the greatest advantage of
using this model, speci cally when compared to the classic waterfall model. Also,

because testing is fractioned throughout the process, all the parties of the devel-
opment are responsible for it. This also means that testing methods are adequate to
each of the stages. Furthermore, the fact that tests are performed since the beginning
of the process only increases its ef

ciency (Mathur and Malik 2010 ).
On the other hand, and much like the waterfall model, this model is very rigid
and there is little room for flexible adaptation, particularly because any alteration in

the requirements will render all existing documentation and testing obsolete. Since
it requires a great deal of resources, it is clearly optimized for large projects within
large organizations (Rahmany 2012 ).

2.6 Rapid Application Development

Originally conceptualized in the 1970s, the rapid application development model
was substantially developed and formalized by James Martin in the early 1990s. As
the name suggests, it is driven by the idea that existing life cycle models are simply
too rigid to permit a fast project development; therefore, there is need for a
framework that can account for fast delivery while still maintaining high-quality
standards. It is grounded on the principle that step-by-step structured life cycles
inevitably entail delays and errors, urging the need for an alternative methodology.