SYSTEM DEVELOPMENT METHODS

1
53901 SYSTEM DEVELOPMENT METHODS Session
4 Teddy So tkkso_at_graduate.hku.hk
2
Revision
3
Strength of SSADM SSADM builds each step on the
work that was prescribed in the previous step
with no deviation from the model. Because of the
rigid structure of the methodology, SSADM is
praised for its control over projects and its
ability to develop better quality systems.
4
Weakness of SSADM However, it requires a
significant investment in training and learning
curves. Moreover, it does not cover the
construction, testing and implementation of
software.
5
Basic Principles of SSADM SSADM is a data-driven
method that there is a basic assumption when
employing this methodology. It assumes that a
system has an underlying and generic data
structure which changes very little over time,
although processing requirements may change.
This underlying data structure is modeled from
an early stage. The representation of this data
structure is checked against the processing and
reporting requirements and finally built into
the architecture of a system.
6
Critique of SSADM

• The purpose of structured methodologies seems to
  have been
• to formalize the requirements elicitation process
  to reduce the
• chances of misunderstanding the requirements
• to introduce best practice techniques to the
  analysis and design
• process.
• SSADM (Structured Systems Analysis and Design
  Method) is a
• typical example of a structured methodology.
• It can reduce the chances of initial requirements
  being
• misunderstood and of the systems functionality
  straying from the
• requirements through the use of inadequate
  analysis and design
• techniques.

7
Critique of SSADM
However, SSADM assumes that the requirements (in
the form of an agreed requirements
specification) will not change during the
development of a project. Following each step
of SSADM rigorously can be time consuming and
there may be a considerable delay between
inception and delivery (which is typically the
first time the users see a working system).
The longer the development time the more chance
of the system meeting the requirements
specification but not satisfying the business
requirements at the time of delivery.
8
(No Transcript)
9
(No Transcript)
10
(No Transcript)
11
(No Transcript)
12
(No Transcript)
13
(No Transcript)
14
(No Transcript)
15
(No Transcript)
16
(No Transcript)
17
(No Transcript)
18
(No Transcript)
19
(No Transcript)
20
Problems faced by Structured Methods Different
modeling techniques are presented and discussed
in previous sections. They are used to offer a
diversity of views of a system. Data flow
diagram shows the flow or movement of data in a
system. Entity-Relationship model reveals the
relationships between data. Entity life history
illustrates how data is changed through time.
Although they show different aspects of a
system from different angles, they have one
thing in common. WHAT IS IT?
21
Different techniques develop different models
just models that are not working system, no
matter how much care, time and effort have been
put in the models.
22
Most development methods follow some variation of
the system development life cycle. Two major
problems of developing systems are the length
of time for systems development from initial
conception to eventual delivery which can be
several years the fact that systems are often
delivered which fail to solve the problems for
which they were originally developed, largely
because of fundamental errors in the
specification of system requirements in the first
place.
23
Different estimates have been made as to
completion times for systems development.
Flaatten et al. (1989) estimated development
time to be about 18 months on average About
three years (Business Week, 1988) About five
years (Taylor Standish, 1982) If you were the
user, what would you feel?
24
Any excitement on the part of users about a new
system quickly turns to disappointment due to
the long delay before system delivery. Given
this time-span for development, backlogs, both
visible as well as invisible, are inevitable.
The visible backlog refers to the systems which
have been formally requested and are scheduled
for eventual development. However, many users,
despairing at the size of the visible backlog,
do not request system that they may need, thus
giving rise to an invisible backlog which is
much larger than the visible one.
25
As a result, a more rapid delivery of systems is
needed. Can structured method meets this need?
26
The linear sequential phased approach of the
traditional waterfall system development life
cycle which assumes that each individual phase
can be satisfactorily completed before the next
one begins, does not facilitate the rapid
development of systems. All the phases in the
system development life cycle should be
completed in sequence as later phases depend on
the successful completion of earlier phases.
27
However, this requires perfect foresight
(Henson Hughes, 1991). For example, problems
which may arise during the physical design will
have to be foreseen during the earlier logical
design phase. Yet, perfect foresight is not
facilitated by the system and development life
cycle in which phases are carried out more in
the context of imperfect predecessors (Taylor
Standish, 1982).
28
Because we live in an imperfect world, each of
these (system development life cycle) activities
usually takes place in the context of imperfect
predecessors. That is, we live in a world where
requirements are never likely to be complete or
accurate, design are never likely to be correct,
and implementation are never likely to satisfy
the requirements and reflect the design
intentions perfectly. (Taylor Standish,
1982).
29
Another major problem with the classical system
development life cycle approach is that it rests
on the a priori assumption that a complete and
detailed understanding of the requirements of
the problem situation can be achieved and that
these requirements can be specified completely
in advance, frozen, and a system designed and
implemented based on these frozen
specifications.
30
However, it has been well established that users
cannot specify their requirements completely in
advance. Brooks (1987) has argued that the
hardest part of systems development is
determining the specifications of what to
develop, and concludes that the assumption that
requirements can be specified in advance is
fundamentally wrong. Parnas and Clements
(1986) have also argued similarly, pointing out
that users typically do not know their complete
set of requirements, and that there is
inevitable backtracking as development take
place.
31
It is the case that problems are dynamic and
change as they are being solved. Davis et al.
(1988) has describe user needs as a moving
target which are constantly evolving, and it
is therefore inappropriate to try freeze
requirements in the specification phase. This
attempt to finalize requirements before any
development takes place does not occur in other
disciplines.
32
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. It is
evidenced by a well-known psychological
phenomenon that recognition is a far easier
process than recall.
33
Prototyping
34
Alavi (1984) has proposed an expansive definition
of prototyping which emphasizes its wider role
in system construction A prototype is an early
version of the system that exhibits the
essential features of the later operational
system. Some prototypes may evolve into the
actual production systems whereas others are
used only for experimentation and may eventually
be replaced by the production system.
35
Prototyping emphasizes a quick response to
loosely specified needs, rather than the precise
initial specification of requirements of the
conventional system development life cycle
approach. It is fundamentally about an
iterative process of demonstration, review,
refinement and expansion. As this process is
central, the verb prototyping is more relevant
and widely used than the noun prototype.
36
Prototyping is based on the concept of working
model. It provides chances to both system
developer and clients to see and experiment with
parts of a system in a computer at a relatively
early stage in the development process. There
are many meaning in the term prototyping and
they will be discussed below.
37
Screen Layout It is the most basic prototype
which consists of non-functioning mock-up sample
screen and report layouts. Clients will know
exactly what will appear on the screen as well
as what will a report look like.
38
Disposable Prototype With the help of the
fourth-generation languages, a model of a system
(or part of a system) can be developed very
quickly and amended after discussion with
clients. This disposable prototype simulates the
functionalities of the proposed system that
clients can see what the system will do.
However, it is not supported by detailed
structure design. Disposable prototype is very
helpful in capturing clients requirements, and
designing and refining the user interface.
However, it is not designed to be developed as
the final system. System developer should be
reminded that eventually it should be put aside
and he should make sure this is done when time
comes.
39
The Evolutionary Prototype It is often referred
as Rapid Application Development (RAD). Unlike
disposable prototype, the aim of RAD is to
develop the final system. It implies that the
system built by this method should be more
quickly than those traditional methods and with
lower cost. In order to achieve these goals,
extensive and detailed analysis of the problem
has to be conducted before the prototyping
begins. As a matter of fact, this prototyping
model will not be attempted without the help of
a CASE tool and a fourth-generation language.
40
Benefits of Prototyping Prototyping provides a
number of benefits in the development process.
Among the benefits cited are the following In
terms of requirements specification, prototyping
is widely recognized as facilitating the
specification of system requirements with
greater precision, thus allowing for validation
before continuing with later development stages.
Each successive prototype forms a closer
approximation of the requirements.
41
In traditional development approaches, users play
a somewhat passive role, whereas prototyping
helps to increase user participation and
commitment, which should lead to increased user
acceptance of the system. Researchers have also
suggested that prototyping elicits an unusual
sense of excitement and anticipation among
users (Berrisford Wetherbe, 1979). They
participate more freely and developers achieve
better communication and establish greater
connection with users. This is also facilitated
by the fact that prototyping reduces the
adversarial nature of the specification sign-off.
42
Prototyping is real and hands-on, rather than a
review of an abstract specification. This helps
to deepen the insight and learning process for
both developers and users. In this manner, new
requirements come to light thus ensuring a more
complete specification of requirements. It also
ensures that any proposed design is evaluated in
a realistic context, a fundamental principle of
good design according to Alexander (1964).
System quality should be improved, in that
requirements are more complete and users are
satisfied and are less likely to request
immediate modifications to systems when they are
delivered.
43
As system functioning can be demonstrated very
quickly, system appear to be developed more
quickly. However, there is real substance to
such a claim, given that many design errors may
be eliminated in the first place. The clients
continuous involvement in the system throughout
its development means that little, if any,
training is needed on how to use it when it is
finally delivered. This applies equally to any
members of staff who have been involved in the
development process. In this way considerable
savings can be made on staff training costs.
44
Weaknesses of Prototyping On the other hand,
researchers have also identified a number of
weaknesses in the prototyping approach,
including Managing a prototyping development
project may be more difficult than a project
undertaken with a conventional development
approach, since the later has the built in
comfort factors of clearly prescribed phases
with milestones and specific deliverables.
45
Prototyping could potentially lead to a waste of
considerable time and money, in that if the
prototype is untimely or inappropriate, the
development team may have expended considerable
resources and may have made any real progress in
developing a system. Rapid prototyping may
result in failure to develop an overall systems
plan which can lead to problems with system
integration. When following a prototyping
approach, the original business problem may not
be thoroughly studied and too little time may be
devoted to generating and evaluating alternative
solutions. The temptation may be to begin with
the requirements the users want most and develop
the systems out from that corner which can
lead to poorly structured systems.
46
Prototyping may be oversold and rapid delivery of
prototype systems may create unrealistic
expectations among users as to the time-scale
for developing fully-functional production
systems. Prototyping may be difficult to apply
on large systems development projects where it
is not clear how the system should be divided
for the purpose of prototyping. Prototyping
requires a significant commitment on the part of
users and it may be difficult to maintain user
enthusiasm beyond the initial specification of
high-priority requirements. The client must be
available to help define and, if necessary,
endlessly redefine models of the emerging
system, screen and report layouts, and the
various functions that system is to perform.
This can be very time-consuming and disruptive
to the clients business.
47
Prototyping is essentially an iterative process.
System developer has to realize that it will not
be right first, or even fifth round. This
constant revising and redefining is often
difficult to accept for a more traditional
software developer who has been used to using a
methodology. Many developers understandably feel
protective about code that may have taken a lot
of time and effort to write and may now have to
be scrapped.
48
(No Transcript)
49
The traditional job definitions no longer apply
in prototyping. The system life cycle demanded
the participation of system analysts, system
designers and programmers all of whom were
specialists in their own particular area, but
who needed to know a little about what the
others were doing. A developer who is
prototyping all or part of a system needs to be
adept at capturing requirements and designing
programs and must be able to program in at least
one high-level language. The traditional analyst
programmer split no longer applies, and a
developer who cannot follow a system through
from the initial idea to the final
implementation will be of little use in
prototyping a system.
50
Prototyping may require the acquisition of
expensive, unfamiliar software. Effective
prototyping demands not only people who have
been trained in a new way but also more powerful
software tools than the traditional
methodologies. Prototyping needs speedy
implementation and flexibility of software
produced. For this, fourth-generation languages
are essential, and for systems of any size CASE
tools will also be needed.
51
Whereas communication with the client is much
easier using prototyping, the amount of
communication needed between different software
developers working on a project can be much more
difficult. If a system is split up into different
areas for separate development of prototypes, it
is essential that these separate parts can all
eventually be integrated into one single,
cohesive system. This involves a large
overhead of communication between developers
prototyping the separate parts. With a large and
complex system, there can come a point where it
needs to be split into so many separate parts
that the communication overhead makes
prototyping impractical as a development method.
The nature of prototyping means that it is
really a one- or two-man job. It will always be
useful in developing certain parts of systems,
such as the user interface, but it has not yet
been proven as a suitable method for developing
large and complex systems as a whole.
52
Conclusion Although prototyping does have
drawbacks, both for the developer and the
client, there is no doubt that with the right
people, in the right circumstances, it is a fast
and effective way of developing high-quality
systems, and can encourage a friendly,
productive relationship between the software
developer and the client. In cases where it is
not appropriate to use prototyping as the main
development approach, it is still useful for the
developer to prototype those areas of the
system, such as the user interface, where client
involvement is essential.
53
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.