Software development models_rendi_saputra_infosys_USR

SOFTWARE DEVELOPMENT MODELS
OLEH:
Rendi Saputra
PROGRAM STUDI S1 SISTEM INFORMASI
FAKULTAS SAINS DAN TEKNOLOGI
UNIVERSITAS SULTAN SYARIF KASIM RIAU

SOFTWARE DEVELOPMENT
MODELS
The life cycle model that is adopted for a
project will have a big impact on the testing that
is
carried out. Testing does not exist in isolation;
test
activities are highly related to software
development
activities.

V-model
Before discussing the V-model, we will
look at the model which came before it.
The waterfall model was one of the
earliest models to be designed. It has a
natural timeline where tasks are
executed in a sequential fashion. We
start at the top of the waterfall with a
feasibility study and flow down through
the various project tasks finishing with
implementation into the live
environment.

Next...
Although variants of the V-model exist, a common type of V-model uses four
test levels. The four test levels used, each with their own objectives, are:
 component testing: searches for defects in and verifies the functioning of
software components (e.g. modules, programs, objects, classes etc.) that are
separately testable;
 integration testing: tests interfaces between components, interactions to
different parts of a system such as an operating system, file system and
hard ware or interfaces between systems;
 system testing: concerned with the behavior of the whole system/product
as defined by the scope of a development project or product. The main
focus of system testing is verification against specified requirements;
 acceptance testing: validation testing with respect to user needs, require
ments, and business processes conducted to determine whether or not to
accept the system.

Next...
Note that the types of work products
mentioned in Figure 2.2 on the left
side of the V-model are just an illustration.
In practice they come under
many different names. References for
generic work products include the
Capability Maturity Model Integration
(CMMi) or the 'Software life cycle
processes' from ISO/IEC 12207.

Iterative Life Cycles
Not all life cycles are sequential. There are also iterative or incremental
life cycles where, instead of one large development time line from
Beginning to end, we cycle through a number of smaller self-contained
life cycle phases for the same project. As with the V model, there are
many variants of iterative life cycles.

Next...
A common feature of iterative approaches is that
the
delivery is divided into increments or builds with each
increment adding new functionality. The initial increment
will contain the infrastructure required to support the
initial
build functionality. The increment produced by an
iteration
may be tested at several levels as part of its
development.
Subsequent increments will need testing for the new
functionality, regression testing of the existing
functionality,
and integration testing of both new and existing parts.

Next...
Rapid Application Development
Rapid Application Development (RAD) is
formally a parallel development of
functions and subsequent integration.

Next..
The RAD development process encourages
active
Customer feedback. The customer gets early visibility of
the
product, can provide feedback on the design and can
decide, based on the existing functionality, whether to
proceed with The development, what functionality to
include
in the next delivery cycle or even to halt the project if it is
not
Delivering the expected value. An early business-
focused
solution in the market place gives an early return on

Next...
Agile development
 Extreme Programming (XP) is currently one of the most well-known agile development
life cycle models. (See [Agile] for ideas behind this approach.) The methodology claims to be
more human friendly than traditional development methods. Some characteristics of XP are:
 It promotes the generation of business stories to define the functionality.
 It demands an on-site customer for continual feedback and to define and
carry out functional acceptance testing .
 It promotes pair programming and shared code ownership amongst the
developers.
 It states that component test scripts shall be written before the code is
written and that those tests should be automated.
 It states that integration and testing of the code shall happen several times
a day.
 It states that we always implement the simplest solution to meet today's
problems.

Testing Within A Life Cycle
Model
 In summary, whichever life cycle model is being
used, there are several characteristics of good
testing:
 for every development activity there is a
corresponding testing activity;
 each test level has test objectives specific to
that level;
 the analysis and design of tests for a given test
level should begin during the corresponding
development Activity.

Bibliography
Graham et.al. (2011). ISTQB-Fondation of
Software Testing. London: Cengage Learning
EMEA.

LINK
 http://sif.uin-suska.ac.id/
 http://fst.uin-suska.ac.id/
 http://www.uin-suska.ac.id/

Software development models_rendi_saputra_infosys_USR

More Related Content

What's hot (20)

Similar to Software development models_rendi_saputra_infosys_USR (20)

Recently uploaded (20)

Software development models_rendi_saputra_infosys_USR