SYSTEMS DEVELOPMENT METHODOLOGIES

Introduction
-This involves how an analyst (or analyst team) designs information systems - at the Requirements Analysis and
Design phases of the systems development life cycle.
The Traditional Life Cycle
-The diagram above shows the 'Traditional' systems development life cycle, highlighting the stages in which
modeling is typically used. The above diagram is itself a model.
-In the last thirty years a number of methodologies, incorporating a variety of techniques, have been developed
to mae the analysis and design stages more manageable. !lmost every methodology has at its heart at least one
modeling technique.
Methodologie
-In the initial "ro#ect $election phase, a ma#or decision is what system development life cycle ($%&') will be
used during the pro#ect. ! second ma#or decision is what methodology will be used - although often this
decision is made by default when an analyst or consultant team is chosen. There are many different
methodologies used in systems development.
(! methodology is a collection of) procedures, tools, and documentation aids which will help the systems
developers to implement a new information system. It is usually based on some philosophical view* otherwise it
is merely a method, lie a recipe+.
-'"hilosophical' in this conte,t can be understood as referring to the underlying attitudes and viewpoints, and the
different assumptions and emphasis to be found within the methodology. -or e,ample, some 'philosophies' on
which a methodology might be based)
$ystems are 'hard', structured, mechanistic.
$ystems are 'soft', unstructured, organic.
.ae as much use of computers as possible.
Include users in all phases.
%escribe problems in order to generate solution.
'oncentrate on solutions rather than problems.
/se prototypes wherever possible.
/se an evolutionary process* etc.
!hy ue a "ethodology0
To introduce structure into design and mae it more manageable
To mae the analysis and design process more accessible to non-e,perts
So"e "ethodologie
-!vison 1 -it2gerald (3443) describes a number of methodologies eg)
5ane and $arsons ($T6!%I$)
I7 (Information 7ngineering),
$$!%. ($tructured $ystems !nalysis and %esign .ethodology),
8$% (8acson $ystems %evelopment),
$$. ($oft $ystems .ethodology,
7T9I'$ etc.
Modeling
-'omputer systems are models of the real world - they abstract from the comple,ity of the real world.
-The analyst observes the comple,ity of the real world and constructs a model of (parts of) the target system in
her head. /sing systematic modeling techniques the target system can be modeled on paper, or, using a
'omputer !ided $oftware 7ngineering ('!$7) tool, in a computer pacage. $ome '!$7 tools (in theory) will
process the model to produce the required new system - at the press of a ey:
You a "odel
--or e,ample, you e,ist in model form in a number of systems. It has been estimated that every human being in
7ngland 'e,ists' - i.e.) has a virtual e,istence - in at least ;< database systems - and I would suggest this is a very
low estimate. ! number of the systems in which you 'e,ist' are within /=7. !s a student you must be in the
!dmissions, &ibrary, $tudent /nion, and -aculty systems.
->ther systems which will include a representation, or model, of you are 5overnment and ?aning $ystems, as
well as, perhaps, $upermaret and /tilities systems. >ne thing that all these systems have in common is that the
'you' which they model is an abstraction - usually your name and only those details which are relevant to the
particular system. 7vents which happen to you in the real world are (or should be) mirrored in the model, but
only those events which are seen to be relevant to that system. 9ow up-to-date a computeri2ed model is, is
dependant on the efficiency of the system's methods of data capture.
Assignments as Example
-!s a student you do assignments. !ssignments are modeled in the computer system solely by a record of the
mar or grade achieved for each assignment. =hen you get an assignment grade or mar, then the 'you' in the
-aculty system has a mar allocated (usually by a member of staff entering the mar via a terminal).
-or the assignment, the model of you in the system does not do anything other than receive a mar. $ometimes
the 'you' in the -aculty system gets the mar before the real-world 'you', sometimes vice-versa, and it is always
possible for the computer model of 'you' to have a different mar or grade:
!hat i a "odel#
-%ouglas T. 6oss (in .arca 34@@) suggests that a model answers questions* that the definition of a model is)
. models ! if . answers questions about !
!hy "odel#
-=e need to model comple, systems in the real world in order to understand them. -or e,ample) we create
computeri2ed models of the real world to manipulate large amounts of data and hence derive information which
can assist in decision maing. !nalysts will create diagrammatic models of a target or proposed system in order
to)
understand the system, and
communicate)
to demonstrate, or clarify, understanding of the e,isting system andAor to obtain feedbac from
usersAclients*
To describe unambiguously the proposed computer system to usersAclients and to the programming
team.
-.odeling techniques are e,tremely useful in tacling the comple,ity which is found when attempting to
analy2e and understand a system. .odels are also e,tremely useful communication tools* i.e.) comple, ideas
and concepts can be captured on paper and can be shown to users and clients for clarification and feedbac* or
for distribution to other professionals, team members, contractors etc. In this respect, the final models created in
the %esign and %evelopment phases of a system are essentially paper based prototypes .
Modeling Techni$ue
The three most important modeling techniques used in analy2ing and building information systems are)
Data Flow Diagramming (%-%s)
ogical Data !tructure modeling (&%$s) and
"ntity ife #istories (7&9s)
-Data Flow Diagrams (%-%s) model events and processes (i.e.
activities which transform data) within a system. %-%s e,amine how
data flows into, out of, and within the system. (Bote) 'data' can be
understood as any 'thing' (e.g.) raw materials, filed information, ideas,
etc.) which is processed within the system.

-ogical Data !tructures (&%$s) represent a system's information and
data in another way. &%$s map the underlying data structures as entity
types, entity attributes, and the relationships between the entities.

"ntity ife #istories (7&9s) describe the changes which happen to
'things' (entities) within the system.

-These three techniques are common to many methodologies and are widely used in system analysis. Botation
and graphics style may vary across methodologies, but the underlying principles are generally the same.
In $$!%. ($tructured $ystems !nalysis and %esign .ethodology - which has for a number of years been
widely used in the /C) systems analysts and modelers use the above techniques to build up three, inter-related,
views of the target system, which are cross-checed for consistency.
Data %lo& Diagra" 'D%D(
-$$!%. uses different sets of %ata -low %iagram to describe the target system in different ways* e.g.)
=9!T the system does
9>= it does it
=9!T it should do
9>= it should do it
-!nother way of looing at it is that, in $$!%., %-%s are used to answer the following data-oriented
questions about a target system)

$hat processing is done% $hen% #ow% $here% &y whom%
$hat data is needed% &y whom% for what% $hen%
D%D Princi)le
-The general principle in %ata -low %iagramming is that a system can be decomposed into subsystems, and
subsystems can be decomposed into lower level subsystems, and so on. 7ach subsystem represents a process or
activity in which data is processed. !t the lowest level, processes can no longer be decomposed.
-7ach 'process' (, by 'process' we mean subsystem and activity) in a %-% has the characteristics of a system).
-8ust as a system must have input and output (if it is not dead), so a process must have input and output.
%ata enters the system from the environment* data flows between processes within the system* and data is
produced as output from the system.
*aic D%D Notation
In a %-%,
a process may be shown as a circle, an oval, or (typically) a rectangular bo,* and
data are shown as arrows coming to, or going from the edge of the process bo,.
'SS+DM( D%D Notation
$$!%. uses D diagramming notations in %-%s
'rocesses transform or manipulate data. 7ach bo, has a unique number
as identifier (top left) and a unique name (an imperative - eg) 'do this' -
statement in the main bo, area) The top line is used for the location of,
or the people responsible for, the process.
Data Flows depict dataAinformation flowing to or from a process. The
arrows used to represent the flows must either start andAor end at a
process bo,.
Data !tores are some location where data is held temporarily or
permanently.
"(ternal "ntities, also nown as '7,ternal sourceArecipients, are things
(eg) people, machines, organisations etc.) which contribute data or
information to the system or which receive dataAinformation from it.

D%D Le,el
The ')onte(t Diagram ' is an overall, simplified, view of the
target system, which contains only one process bo, and the
primary inputs and outputs.
The 'onte,t diagram above, and the one which follows, are a first attempt at describing part of a '9ome
'atalogue' sales system. In the modeling process it is liely that diagrams will be rewored and amended many
times - until all parties are satisfied with the resulting model. ! model can usefully be described as a co-
ordinated set of diagrams.
The *op or +st level %-%, describes
the whole of the target system.
The Top level%-% 'bounds' the
system -and shows the ma#or
processes which are included within
the system.
7ach "rocess bo, in the Top &evel diagram may itself be made up of a number of processes, and where this is
the case, the process bo, will be decomposed as a second level diagram.
!ny bo, in the second level decomposition may be decomposed to a third level. Eery comple, systems may
possibly require decomposition of some bo,es to further levels.
%ecomposition stops when a process bo, can be described with an "lementary Function Description using, for
e,ample, pseudocode.
7ach bo, in a diagram has an identification number (derived from the parent - the 'onte,t level is seen as bo,
<) in the top left corner.
Syte" analyi - an introduction
Co)yright. t/dre&ry0c"/u&e/ac/u1
Soft&are and Syte" De,elo)"ent Life-cycle
=hy learn about $ystems !nalysis and %esign0
9istorical perspective
The Traditional &ife 'ycle
Three types of process model
The waterfall model
7,ploratory programming
"rototyping
$oftware development using a D5&
"rototyping as analysis tool
6!%
-urther 6eading and ?ibliography
!hy learn a2out Syte" +nalyi and Deign#
you are likely, in your future career, to find yourself involved in systems development -
perhaps:
o as a worker whose job is being re-organised, or
o as part of a team involved in developing a new system or
o adapting an existing system; or
o with responsibility for specifying requirements for a new system.
the system development lifecycles are 'process' models - they outline recognised steps for
successfully completing complex tasks. You can use these steps as guidelines for
completing projects at work and at home. (eg: buying a personal computer system, or doing
a final year project!)
The Triangle
depicts the relationship between the Client (>wner of
the system), the Users (the eventual operators of the
system which is to be introduced) and the !pplication
%evelopment Team, headed by the Analyst .
7ach corner of the triangle represents possibly
conflicting points-of-view and different agendas in
respect of the development of a new system.
Theoretically (hopefully) the three parties will reach
some compromise where they all have an equal say in
the final system - shown by the lines meeting in the
centre of the triangle.
The Syte" +nalyt
investigates, analyses how information is used and the requirements of current system
#udges feasibility of computer system
designs new system* and specifies)
programs
hardware
data structures
procedures
9'I and training
is responsible for)
o documentation of the pro#ect and system,
o overseeing installation,
o testing and evaluation
!s the liaison between users and the programmer team, (s)he must have good communication sills - and
understand both the domain of the target organisation and the realm of the programmer team.
Hitorical )er)ecti,e
In the 34F<s)
o 'ostly mistaes in the development of large systems
o "roblems with maintenance of e,isting software
o %evelopments in hardware*
o usersAclients calling for)
(MORE MORE MORE software(
(Better software please.(
(Cheaper software please.(
(We want it yesterday(
(,s it any different now in the new millenium%)
led to awareness of a 'software crisis', and the need to control and co-ordinate the software development
process. (!nd the famous line) (,t can be made cheaply, it can be made quic-ly and it can be made to a high
standard - choose any two.()
The association of software production with the discipline of engineering resulted in use of engineering process
models, nown within the world of I.T as system development life-cycles. The traditional system development
life-cycle (taen from 6oyce, 34G<), is shown below, followed by a description of each stage.
The Traditional Life Cycle
"ro#ect $election
-easibility $tudy
!nalysis - 6equirements %efinition
$ystems and $oftware %esign
Implementation and /nit Testing
$ystem Testing
>peration and .aintenance

Pro3ect Selection 'Initial trategy(
Typically a small committee with responsibility for pro#ect budgets will decide in principle to go ahead with
some pro#ect. They will usually)
specify Ter" of 4eference - giving a brief outline of)
o what areas the system is to cover
o what will be included
o what will B>T be included
propose a %eai2ility Study, indicating)
o how long it will it tae to produce
o who will produce it
o a deadline (ie) the date by which it is e,pected)
%eai2ility Study
Pur)oe. To decide whether the proposed system is feasible
usually in terms of economics (since most things are now technically feasible)
To give estimates of)
development costs
development timescale
running costs
Method. >bservation* Interviews* "rofessional #udgement.

Deli,era2le) o -easibility 6eport to sponsor
o "ro#ect "lan
o 'osts and ?enefits
o the go-ahead, or otherwise.

+nalyi - 4e$uire"ent Definition
4e$uire"ent
+nalyi
gathers information about what the users want in the new system
- theoretically does not include items in current system - however, information on current
system liely to be obtained at the same time

Syte" +nalyi finds out what is done and why it is done
records it all
generates models (diagrams) showing who does what, when (physical model)
refines, adds more detail to requirements analysis
probably uncovers new requirements
generates new diagrams showing #ust what is done (logical model)
checs analysis with the user
Deli,era2le. o 6equirements 6eport
o 6evised "ro#ect "lan
o 6evised 'osts and ?enefits
Syte" and Soft&are Deign
Syte" )ecification states what the new system will do
generates logical diagrams for new system
defines processes at all levels (highest to lowest)
defines all data required
Syte" deign e.g. 9ow the new system will fulfil specification
=hich parts will be done by computer
=hich parts will be done manually
=hat si2eAtype of computer0
Betworing and comms0
Deli,era2le. o $ystemAsoftware $pecification
o %atabase %efinition
o Training .anuals
o 9ardware $pecifications (if relevant)
o 6evised "ro#ect "lan
o 6evised 'osts and ?enefits
I")le"entation and 5nit Teting
Syte" de,elo)"ent final definition of data structures
creation of data storage mechanisms
production of all programs
5nit teting development of test platformAprocedures (comprehensive test plan and test data)
test each hardware item, each software unit, each clerical procedure and user interface
test any (off the shelf( modules
Syte" Teting
o test all units woring together as system - distinct unitsAmodulesAsub-systems may wor
individually but may not wor together:
o requires users to oay ('sign off') system
O)eration and Maintenance
I")le"entation
'introduction
of yte"(
Phased - (a bit at a time(
Pilot - introduced first of all in one part of organi2ation
Parallel - in parallel with e,isting system
Direct - (big bang( - all at once
Maintenance fi,ing problems
adding enhancements
eeping system up-to-date.
The ongoing upgrading of the system
- of fi,es to correct bugs not caught at testing time
- of fi,es to adapt to a changing business environment
4e,ie&
'osts within budget0
?enefits achieved0
"erformance up to e,pectations0
6oom for improvements0
6ecommendations for the future0
Three ty)e of )roce "odel
The traditional life-cycle model (T&') has been used, and is still being used, as the basis of development
process models. $omerville suggests a number of general models (or development process paradigms). Three
models which are used (as opposed to being theoretically useful) are)
o The '=!T76-!&&' .odel
o 7H"&>6!T>6I "rogramming
o "6>T>TI"IB5.
!ll the system development lifecycle models fall within the same meta-paradigm* i.e. Definition -
De,elo)"ent - Maintenance
The &aterfall "odel
The waterfall model of the software development process is within the same paradigm as the traditional
life cycle description.
The development process is seen as being made up of a series of distinct phases, or stages, each of
which can be completed, and 'signed off'.
Typically the completion of a stage is mared by the submission of a set of defined deliverables
(outlined above in the description of the Traditional &ife 'ycle).
"rogress through the system is measurable and above all manageable.
Iteration &ithin the !aterfall "odel
! ma#or problem with software design is the need for iteration - typically required for, and a result of,
verification and validation (described in &oehm, 34@3, quoted by $omerville))
(erification) '!re we building the product right0'
alidation) '!re we building the right product0(
!sing these questions at the end of each development phase may result in a decision to repeat (iterate) the
phase and sometimes require a reworing of a previous phase.
Iteration can be included within the waterfall model, but tends to reduce the manageability of a pro#ect. To deal
with this, a strategy is used whereby a phase is 'fro2en' after a specified number of iterations.
E6)loratory )rogra""ing
$ome problems with e,ploratory programming)
Bo 'real' specification so no verification is possible.
.aintenance liely to be difficult 1 costly because of lac of documentation and multiplicity of changes
from initial proposal.
?ecause of many alterations, typically software developed in this way has an ill-defined structure .
Typically the e,ploratory approach requires highly silled practitioners.
9owever, some classes of system need this approach, particularly where the final system is proposed rather than
specified, eg) in the field of !rtificial Intelligence* or where there is a general idea that e,perimenting with a
computer programAsystem could be useful
Prototy)ing
! prototype is)
+. an original or model after which anything is formed/
0. the first thing or being of its -ind/
J. a pattern, e(emplar, or archetype ( (=ebsters ;<th '.)
"rototyping in systems development is the process of creating a 'cut-down' version, or part, of a system so that
users can)
get an idea of what the system will offer* and
provide feedbac on whether the system is what is required.
"rototyping helps to identify misunderstandings between 'users' and software developers* and may detect
missing (ie) not yet specified) user requirements.
+d,antage of )rototy)ing tage)
o identification of misunderstandings between 'users' and software developers*
o detection of missing user services
o identification of difficult-to-use or confusing user services
o requirements validation aid (discovering inconsistencies)
o early availability of a woring (limited) system
o may serve as basis for specification for a 'production quality' system
Poi2le 7danger7 of )rototy)e
'users' may not give up prototype.
prototype may become basis of implementation (but lacs safety-critical features)
may be used as basis for contract with sAw engineer(s) eg) 'build one lie this' - no legal standing.
non-functional requirements cannot be adequately e,pressed
omission of functions in prototype may mean prototype not used in same way as fully operational
system
!B% may encourage inadequate problem analysis
!or long"lifetime systems# prototypes sho$ld %e completely re"implemented
"rototyping is seen sometimes as representing 'unacceptably large proportion of system development costs.'
9owever, see $omerville on relative costs of corrective maintenance. -or e,ample) it (was estimated that one
1! Air Force system cost 234 per instruction to develop and 25444 per instruction to maintain over its lifetime(
(&oehm, +678) (It should be noted that systems typically contain thousands, if not many hundreds of thousands,
of instructions:)
8GLS
'urrently, D5&s are good tools for prototyping. The D5& process model is almost identical to the prototyping
model.
Soft&are de,elo)"ent uing a 8GL
"rototyping with D5&s can be very useful in the requirements analysis and definition stages of large pro#ects
which otherwise 'use' a traditional lifecycle process model.
Prototy)ing a analyi tool
+d,antage of uing a 8GL in )rototy)ing tage
o improved productivity in software engineering and (possible) reduction in costs*
o complete rewrites of prototype software possible allowing (possibly) a more e,ploratory
approach* and also
o (possibly)) 'user' programming*
o improved documentation*
o smaller development teams.
4+D
! new (in 344G) development strategy called 6apid !pplications %evelopment (6!%) is already being used.
6!% maes use of)
well organised and structured group meetings which must have representatives of the 'lient and /sers
(see TheTriangle at start of this document).
The user representatives must be authorised to mae decisions*
small teams using 'omputer !ided $oftware 7ngineering tools ('!$7). The team usually includes user
representatives (or wors with ready access to users.)
'timebo,es', generally measured in wees rather than months, within which the teams wor on and
complete prioriti2ed tass - using a combination of the e,ploratory and prototyping lifecycle models.
6!% has had some successes in producing high quality software - in much less time than, for e,ample, the
traditional lifecycle process.
%urther 4eading and *i2liogra)hy
! very good boo to loo at is ) &oftware &ystem De'elopment " a gentle introd$ction, by 'arol ?ritton and
8ill %oae, .c5raw-9ill, chapters 3, and ;.
!lso)
?irrell, B.%. 1 >uld, ..!, (34@F) A 'ractical #andboo- for !oftware Development, './.".
-airley, 6.7, (34@G) &oftware Engineering Concepts, .c5raw-9ill*
8ones, 5.=. (344<) &oftware Engineering, 8ohn =iley 1 $ons
"arin, !. (34@K) &ystems Analysis, 7dward !rnold
$omerville,I., (344<) &oftware Engineering ()rd ed*+, !ddison =esley
9uetion
3. In the F<'s, the phrase 'software crisis' was coined to describe the problems people were having with
computers and computing. =hat strategies were adopted to deal with the crisis and were they
successful0
;. /sing diagrams to illustrate your answer, describe three models of the system development life-cycle.
J. If you were advising a chief e,ecutive on how to go about developing and introducing a new
information system in a large organisation, what advice would you give on the type of system
development life-cycle she should propose0
D. =ho or what is a systems analyst and what does hisAher #ob entail0
K. In this lecture a diagram showing one of the three types of process model is different from the other
diagrams, in that a 'flowchart' technique is used. 9ow would the diagram loo if it were drawn using the
same methodology as the other diagrams0 =hy do you thin the 'flowchart' method was used for that
particular process model0