SYSTEM DEVELOPMENT METHODS

1
53901 SYSTEM DEVELOPMENT METHODS Session
5 Teddy So tkkso_at_graduate.hku.hk
2
Revision
3
Rapid Application Development (RAD)
4
The term Rapid Application Development (RAD) was
introduced in the literature by James Martin in
his book Rapid Application Development in
1991. The rapid potential of RAD arises from the
synthesis of currently-available tools and
techniques, coupled with fundamentally different
management principles that serve to overcome
bureaucratic obstacles to faster development.
Thus, the mission of RAD is the simple but
powerful one of increasing development speed at
a reduced cost without sacrificing quality.
5
Fundamental Principles Underpinning RAD The
principles include active user
involvement small empowered teams frequent
delivery of products which focus primarily on
satisfaction of business functionality iterati
ve incremental development top-down
approach and the use of integrated CASE wherever
possible. These principles are complementary in
many respects, and as a whole are extremely
powerful.
6
Active User Involvement Indeed it is almost an
axiom that user involvement is necessary for
successful development. However, several
studies have found that user involvement is not
a simple issue, and the link between user
involvement and success is not a simple one.
The RAD approach recognizes that user
involvement is necessary for intellectual
reasons for example, to reduce costly
requirements elicitation problems, and for
political reasons users may reject systems
outright if they have not been sufficiently
involved in development. All relevant parties
are co-located thus leading to synchronization
in the communication process.
7
Small Empowered Teams Again, the concept of
development team is not new. Firstly,
communication channels increase exponentially in
relation to team size. Therefore, small team
size ensures that the potential for
communication distortion and conflict is kept to
a minimum. Secondly, the empowerment element
helps ensure that bureaucratic delays and
shirking of decision-making responsibility, so
inherently characteristic of the traditional
requirements signoff, are minimized. Teams are
empowered to make vital design decisions.
8
Finally, the team aspect serves to ensure that
all vital skills for successful development are
present. Successful development requires that
many varied roles be accommodated, e.g. project
manager, technical coordinator, developer,
tester, scribe, user, and executive sponsor.
The fulfillment of these roles is facilitated
by team composition, and their importance has
been acknowledged by Microsoft who organizes
their software development around various
development roles in a similar manner.
9
Frequent Delivery of Products As mentioned
before, traditional development projects can take
from 18 months to five years to complete. It is
increasingly problematic given the
rapidly-changing nature of todays competitive
market-place. RAD, by definition, seeks to
reduce development time-spans. Thus, shorter
time-boxes for development typically 90 days
are an important feature. These shorter
time-boxes make project management more
straightforward in that it is easier to focus on
necessary activities, and be more accurate as to
what can be achieved.
10
Iterative Incremental Development Another
fundamental principle of RAD is that systems
evolve incrementally and are never complete.
Rather, new requirements emerge which are then
built into the system. Thus, systems emerge
through iterative prototyping, with iteration
seen as useful and necessary, not as re-work
delaying development. It is recognized that
requirements specification is a learning process
which greatly benefits from the deeper insight
that both developers and users get from
realistic experience with an actual prototype
system. Users may not be able to specify in
advance exactly what they want in a system but
are able to recognize it when they see it
recognition is a far easier process than recall.
11
In traditional development, errors in
requirements which are not identified before
coding or implementation are extremely costly to
correct (Boehm, 1981 DeMarco, 1978). In fact,
it is now commonly accepted that since the
system produced by the traditional life-cycle
undergoes a significant maintenance phase, it
may be more properly viewed as a prototype
anyway.
12
(No Transcript)
13
Typically the planning phase is only performed
once at the initiation of the development
project. Analysis, design coding and
implementation are iterated in several chunks
or time-boxes. The maintenance activity grows
as more and more of the system is developed, as
indicated by the growing size of the maintenance
component in the above figure.
14
(No Transcript)
15
Top-Down Approach As mentioned before, the
philosophy of RAD accepts that requirements
cannot be completely specified in advance.
Products fits for business purpose are produced
according to an application of the Pareto
principle that is, approximately 80 of the
functionality may be delivered in 20 of the
time. Systems are then elaborated and finessed
as knowledge grows, from broad outline to
precise detail. Also, being a top-down approach
characterized by short time-boxing, all
decisions are assumed to be fairly quickly
reversible. This also contributes to developers
feeling more empowered to assume responsibility
and being less likely to shirk decision-making.
16
Integrated Computer Assisted Software Engineering
(I-CASE) If dramatic increases in development
productivity are to be achieved, it is vital
that the more routine and time-consuming aspects
of development be automated. These include code
generation and documentation. The automation of
these tasks may be achieved through the use of
I-CASE.
17

• Essential Aspects of RAD
• Rapid Application Development has four essential
  aspects
• methodology
• people
• management
• tools.

18
The DSDM RAD Method A RAD method which is of
special interest to us is the Dynamic Systems
Development Method (DSDM), produced by a
consortium of the same name. The primary reason
for our interest is because it is a method which
has been inductively derived from actual
development practice in a large number of
organizations.
19
(No Transcript)
20

• According to the documentation on the DSDM web
  site
• (www.dsdm.org), the method comprises the
  following five generic
• stages, which are tailored to the specific
  business and technical
• needs of the development context
• Feasibility
• Business study
• Functional model iteration
• Design and build iteration
• Implementation

21
(No Transcript)
22
Feasibility Study In this phase, the focus of
concern is whether the proposed development will
actually meet the business needs, whether the
DSDM method is even suitable for the project,
and an estimate of the development time-scale
and costs, and a rough project plan is produced.
This phase should occupy a few weeks at
most. Business Study This phase identifies the
scope of the overall project and provides a
sound business and technical basis for all future
work. High-level functional and non-functional
requirements are base-lined, a high-level model
of the business functionality and informational
requirements is produced, the system architecture
is outlined and the maintainability objectives
are agreed. Like the feasibility study, the
business study is a short phase, of no more than
a month.
23
The Feasibility and Business Studies are done
sequentially and set the ground rules for the
rest of the development. Therefore, they must
be completed before any work is carried out on a
given project.
24

• Functional Model Iteration
• In this phase, the focus is on refining the
  business aspects of the
• system, that is, building on the high-level
  functional and
• informational requirements.
• This phase consists of cycles of four activities
• Identify what is to be produced
• Agree how and when to do it
• Create the product
• Check that it has been produced correctly
• It is estimated that the bulk of development work
  is in the two
• iteration phases where prototypes are
  incrementally built towards
• the tested system.
• All prototypes in DSDM are intended to evolve
  into the final
• system and are therefore built to be robust
  enough for operational
• use and to satisfy any relevant non-functional
  requirements.

25
Design and Build Iteration During the Design and
Build Iteration, the focus is on ensuring that
the system is of sufficiently high standard to be
safely put into production. The major product
here is the tested system. The life-cycle does
not show testing as a distinct activity because
testing is happening throughout both the
functional model iteration and design and build
iteration. The tested system will satisfy all
the agreed requirements, that is the essential
requirements plus as many others as the time
available allows. This phase comprises the
same cycle of four activities as the previous
phases, Functional Model Iteration.
26
Implementation The implementation phase covers
the transfer from the development environment to
the operational environment. This includes
training all users and handing over the system to
them. The project review document is also
produced and summarizes what the project has
achieved. It reviews all the requirements, which
were identified during development and the
position of the system in relation to those
requirements.
27
Critique of DSDM and RAD RAD (Rapid Application
Development, Martin, 1991) approaches began to
be adopted in the late 80s and are based on a
number of fundamental premises, the most
important being the acceptance that business
processing requirements will inevitably change
during the development cycle of a system.
28

• In order to work with this fact of systems
  development life the
• RAD approach mandates
• the use of 4th Generation Tools (to enable quick
  delivery)
• an iterative model of systems development which
  allows backtracking in the light of changing
  requirements
• the use of evolutionary prototypes (SSADM adopts
  the adage that a picture is worth a thousand
  words, RAD goes a step further and advocates
  that a working model is worth a thousand
  pictures)
• a very high level of user involvement in the
  development process to aid in communications
  and to encourage feelings of commitment and
  ownership
• the empowerment of highly skilled,
  multi-disciplinary teams consisting of users,
  analysts and technical specialists.

29

• DSDM advocates that RAD is only suitable for
  certain kinds of
• applications, i.e. those which
• are interactive,
• with clear functionality at the user interface,
• have a clearly defined user group,
• are not computationally complex
• and have requirements which are not too detailed
  and fixed.
• DSDM advocates that RAD is not suitable for
  real-time or
• safety-critical applications or for applications
  where functional
• requirements have to be fully specified before
  any programs are
• written.

30

• What about the large class of information systems
  in between,
• i.e. those which have
• a mixture of interactive and non-interactive
  functionality,
• a core user group which is clear but an
  ill-defined group of other users,
• some elements of computationally complex
  functionality,
• a range of requirements, from the detailed and
  fixed to the unclear and variable.
• RAD depends on active user involvement in the
  development
• process. What happens if the right users are
  unavailable? It has
• been stated that the best users to be involved in
  RAD teams are
• those which business cant afford to lose!

31
C A S E
32
What is CASE? CASE stands for Computer Aided
Software Engineering. At the most general level
a CASE tool can be any piece of software that
assists in the development of a system. This can
include compliers, debuggers and any automated
design aid, such as a program that draws lines
and boxes on the screen. At the top end of the
range, the most sophisticated CASE tools include
complete sets of integrated programs which guide
the developer through the whole process of
building and managing a system. Many CASE tools
are specifically tied to a particular
methodology. Some of the best known include IEW
and IEF, which are CASE tools for James Martins
Information Engineering, and Automate, which
supports the SSADM methodology. Other tools,
such as Teamwork and Software Through Pictures
claim to be more general and to fit in with
different appropriate to system development.
33
CASE Tools and Structured Techniques CASE tools
automate the system development process,
including the modeling techniques. Using a CASE
tool a designer can quickly build up a data flow
diagram from boxes and other symbols provided on
the screen. Unlike human, the CASE tool
remembers all the details of every diagram that
it has drawn.
34
For example, a developer has drawn a context
diagram (level 0) by a particular CASE tool. If
he wants to explode the diagram and move down to
level 1, all the inputs and outputs from the
context diagram are recalled and automatically
produced on the screen so that they can be
incorporated into the new level 1 diagram. As
the developer draws the level 1 diagram, the
tools automatically checks that the work is
consistent with any previous diagrams. If the
developer wants to make a change to one of the
data flow diagrams later on, the CASE tool will
register the effects of the change and
automatically update the relevant diagrams. It
does not allow the developer to infringe the
balancing rules, for instance.
35
As well as checking consistency between different
levels of diagrams, the CASE tool can also
create links and provide cross-check between
different types of model, such as data flow and
entity-relationship diagrams The CASE tools
repository (a huge, automated data dictionary)
forms the basis for a whole network of
connections between all the different models of
the system. This sort of cross-checking, to
ensure consistency between all the models of the
system, is a major feature of all CASE tools and
can save the system developer many hours of
tedious and tiring work.
36
Sample Screen showing the ERD Graphically
37
(No Transcript)
38
Some of the more sophisticated tools use models
of the required logical system to generate code,
database files and menus automatically. Entities
in the data model become database file,
attributes become fields, process name in top
level data flow diagrams become top level menus
and lower level process names become lower level
menus. This means that a CASE tool can assist
and support the developer throughout the entire
development process.
39
CASE Tools and the Client There is no doubt that
CASE tools can be a great help to the system
developer, but how does this affect the client
and the quality of the final system? With live
diagram on the screen it is relatively easy to
try out ideas and to see the effect various
changes would have on the system on a whole.
Used in this way, with a close partnership
between the developer and client, CASE tools are
invaluable in prototyping, since they greatly
facilitate fast production of prototypes. CASE is
particularly useful in the rapid development of
evolutionary prototypes where the working model
is progressively refined to become the final
system. The most important issue is that the
clients fully understand everything they are
shown at each stage of the development process
and that they are entirely happy about the way
the system is progressing.
40
CASE Who Benefits? One of the principal claims
for CASE tools is that they increase the
productivity of the system development process.
This can imply two different things. Firstly
there are considerable savings made in time,
money, and effort by the system developer.
Secondly, the final system produced is of a
higher quality than a system developed without
automated tools.
41
There is little doubt that CASE tools can greatly
facilitate the work of the system developer in
many ways. System can be analyzed, designed and
implemented more quickly using automated tools.
Much of the tiresome side of the job, such as
detailed checking of diagrams and charts for
consistency and completeness, can be carried out
by the CASE tool. But how does this affect the
client? As long as the final system is of a
high quality, within the agreed budget, and
delivered according to the agreed schedule, does
the client really care how it has been built?
42
CASE is no guarantee of quality. What is beyond
doubt is that these tools do save time and money
in the system development process. The result of
this should be that such savings will not be
swallowed up by software development firms, in
buying and maintaining the CASE tool, but will
be passed on to clients in the form of
higher-quality systems which are delivered on
time and within budget.
43
Advantages of CASE Tools CASE tools offer a
faster, more efficient and less tedious way of
doing the job. Many of the system developers
most time-consuming tasks can be carried out by
the CASE tool repository, which can perform
endless cross-checking which would be too
time-consuming to do by hand. This leads to fast,
accurate detection of errors, omissions and
inconsistencies. Communication with the client
during the development process can be greatly
facilitated by using a CASE tool. CASE tools make
comprehensive use of graphics and allow diagrams
to be produced and altered with ease. This means
that, when errors are discovered or when the
client is not happy with a diagram, it is
relatively simple task to make the required
changes. CASE tools facilitate and encourage
reworking of models to ensure that the final
design is exactly what the client wants.
44
The production of full, consistent documentation
using a CASE tool is very much easier and more
accurate than documenting a system developed by
hand, since every item of data about the system
is held in the central repository of the CASE
tool. This is especially important on systems
that takes several man-years to develop, since
it is likely that many different people will be
working on the system during its lifetime. The
extensive documentation produced and the speed
of reworking mean that the system developed with
CASE are more easily maintainable than systems
developed by hand. For developers who use
prototypes as the basis of their work, all the
advantages of prototyping, such as rapid
development and improved communication with
clients, are enhanced by using a CASE tool to
build the prototypes.
45
On the management side, the advent of IPSE
(Integrated Project Support Environment) means
that the technical details of developing a
system can be totally integrated with the
management of the development project. Perhaps
the most important advantage of CASE tools for
the system developer is that using a CASE tool
can be fun. With automated aids, the developer
is free to concentrate on the creative side of
the work, sure in the knowledge that the boring,
repetitive tasks will be performed speedily and
accurately by the CASE tool.
46
Some Criticisms of CASE CASE tools are very
expensive and represent a major investment for a
software development company.
47
Since many of the tools are tied to a particular
methodology, this involves a strong commitment
to that methodology on the part of the company.
This commitment, together with the size f the
investment, means that a development company
will probably become fixed in a particular way
of developing systems, rather than moving ahead
to new techniques and approaches. A CASE tool
involves further expense for the company in terms
of time, effort and money since it needs to be
maintained in the same way as any other piece of
software. Moreover, there is a learning curve
associated with the tools and specialized
training is often needed. A software company
would have to take this into account when
considering whether it is worth investing in
CASE.
48
The CASE tool can support, but not replace, the
work of the system developer. Development of
software systems requires skills and talents,
such as creativity and good communication, that
cannot be performed by an automated tool. There
is a risk that a poor developer may be able to
blind the client with the science of the CASE
tool, but it is important to remember that there
is no substitute for good software systems
developers who know their jobs.
49
Reference Ashworth, C. and Goodland, M. (1998).
SSADM A Practical Approach. McGraw-Hill. Bentley
, C. and Rudman, B. (1995). SSADM Using SSADM
in a PRINCE Environment. Butterworth-Heinemann
Limited. Fitzgerald, B., Russo, N., and
Stolterman, E. (2002). Information System
Development Method in Action. McGraw-Hill.