Date post: | 04-Jun-2018 |
Category: |
Documents |
Upload: | kenneth-rono |
View: | 219 times |
Download: | 0 times |
of 16
8/13/2019 System Development Strategies
1/16
CHAPTER 2: INTRODUCTION TO SYSTEMS
DEVELOPMENT STRATEGIES
Chapter Objectie!
At the end of this chapter, you would have learnt:
systems development life cycle;
SDLC weaknesses;
structured systems development;
prototyping;
evolutionary information systems development.
E!!e"tia# Rea$i"%! &'r thi! Chapter
Analysis Design of !nformation Systems "#nd $dition%, &ames A. Senn "'()(%, *c+raw-ill.
Chapter ', page #/ 0#1
An !ntroduction to SSAD* 2ersion 0, Caroline Ashworth Laurence Slater "'((3%, *c+raw-ill.Chapter ', page ' ')1
Systems Analysis and Design, +ary 4. Shelly, 5homas &. Cashman, &udy Adamski &oseph &.
Adamski "'(('%, 4oyd 6raser. Chapter ', page '# '71
2 - 1
8/13/2019 System Development Strategies
2/16
CHAPTER 2: INTRODUCTION TO SYSTEMS DEVELOPMENT STRATEGIES
2() I"tr'$*cti'"
According to 89esters ungle, it wille a difficult task. A strategy, when use appropriately, can direct a system development towards
success.
Learning strategy is like learning history, we can enhance our wisdom through learning the e@periencesof our computer ancestors. 4y e@amining these e@periences, we can enefit the sources of their
successes and avoid the causes of their failures. !n this way, we will e more effective in managingsystems development.
$ach tool serves different purposes. 6or e@amples, a hammer is used to nail, an a@e is used to chop
logs, and a chisel is used to trim wood. Similarly, a strategy which matches its usage with the systemscharacteristics will increase the efficiency of a system development. 5hat is to say, the overall
productivity will improve.
-owever, a system analyst should e forewarned that these strategies have strengths and limitations.Doctors who follow closely to medical te@tooks in their practice risk giving the wrong treatment.
+enerals who copy military strategies wholesale are likely to lose their armies. 5his is not to say it is
useless to study strategies, ut that one must study well and apply them appropriately to reap highestpossile results.
2(2 S+!te,! Dee#'p,e"t Li&e C+c#e
5he !+!te,! $ee#'p,e"t #i&e c+c#e -SDLC. is a classical and systematic approach employed ysystems analysts to develop an information systems. Although analysts opine differently on the numer
of phases in the SDLC, we will in here divide the SDLC into si@ phases as shown in 6igure #.':
2(2() Pre#i,i"ar+ I"e!ti%ati'"
5his is the first activity prior to an initiation of a system development. nly a limited time is usuallygiven to perform this phase. 5he main o>ectives of this phase are to ensure the system to e developed
aligns with organisationBs goals and it is achievale y considering current technology, organisationBscommitment, assigned udget and availale resources. 5hree suactivities are asically involved:
reuest clarification, feasiility study, and reuest approval.
2 - 2
8/13/2019 System Development Strategies
3/16
CHAPTER 2: INTRODUCTION TO SYSTEMS DEVELOPMENT STRATEGIES
Figure 2.1: System Development Life Cycle
Re/*e!t C#ari&icati'"
*anagement or an end user may reuest systems development. 5here are many reasons that trigger offa reuest for system development. As an analyst, you should identify clearly the nature and scope of
such reuest.
2 - 3
=hase #
euirement Determination
=hase 3
Systems Design
9orking System $valuation
eport
=hase 0Systems Development
=hase /Systems !mplementation
And $valuation
=hase 7
System 5esting
=hase '
=reliminary !nvestigation
=reliminary !nvestigation
eport
System Specifications
5ested Software
=rocedure manualsSoftware
System euirements
Document
System euest PHASE OUTPUT
perational !nformation
System
8/13/2019 System Development Strategies
4/16
CHAPTER 2: INTRODUCTION TO SYSTEMS DEVELOPMENT STRATEGIES
0ea!ibi#it+ St*$+
8/13/2019 System Development Strategies
5/16
CHAPTER 2: INTRODUCTION TO SYSTEMS DEVELOPMENT STRATEGIES
5he end product you create for this life cycle is the system reuirements document, which documents
all end user and management reuirements, all alternative plans and their costs, and yourrecommendations to management. After you present your results from this phase to management,
management decides on the est alternatives. !f the selected choice involves the use of softwarepackage, then your company must purchase the package, and you would continue on to either phase
four, systems development "if package modifications are needed%, or phase five, systemsimplementation and evaluation "if the package can e used as is%. !f managements of alternatives is for
inhouse developed software, then you enter the third phase, systems design. 6inally, managementmight decide to terminate development. *anagement might choose to terminate development at any
point of the SDLC due to high costs, changing priorities, or failure to meet o>ectives.
2(2(1 S+!te,! De!i%"
5he purpose of the system design phase is to determine how to construct the information system to est
satisfy the document reuirements. Gou must design all reuired information system outputs, files,inputs, application software programs, and manual procedures. Also you must design the internal ande@ternal controls, which are computerased and manual steps that guarantee the information system
will e reliale, accurate, and secure.
5he design is documented in the system design specification and presented to management and the endusers for their review and approval. *anagement and end user involvement is critical so that there is no
misunderstanding aout what the information system is to do, how it will do it, and what it will cost.After all systems design steps have een completed and if the development is not terminated, you then
enter the ne@t phase, systems development.
2(2( S+!te,! Dee#'p,e"t
Systems development is the phase during which the information system is actually constructed:applications programs are written, tested, and documented; operational documentation and procedures
are completed; and end user and management review and approval is otained. 5he end product of thisphase is a functioning and documented information system.
F $nd of notes e@tracted?modified from: System Analysis and Design, +ary 4. Shelly,5homas &. Cashman, &udy Adamski &oseph &. Adamski "'(('%.
2(2(3 S+!te,! Te!ti"%
ne of the main o>ectives of this phase is to ensure that the information system uilt and procedure
manuals documented comply to the specifications outlined in System euirements Document. !naddition, the information system developed is reliale and accurate, and the users are ale to operate
the new system in foreseen ways. 5est data are usually prepared for this phase. Gou, however, shouldnote that a system that undergoes and passes the testing phase does not assure the system to e free of
faults. !t simply means the system has survived and proaly even tolerated the e@pected faults.
2 - 5
8/13/2019 System Development Strategies
6/16
CHAPTER 2: INTRODUCTION TO SYSTEMS DEVELOPMENT STRATEGIES
2(2(4 S+!te,! I,p#e,e"tati'" a"$ Ea#*ati'"
5he final activity for an analyst, and with much satisfaction, is to see his?her information system
designed goes into action. After the management has reviewed and approved all the phases results, thenew or revised system will e implemented. During this phase, appropriate training programme should
e provided. 5he conversion from the old system into the new system could e carried out in one of thefollowing methods:
=arallel
4oth old and new systems will run in parallel until the users can manage the new
system.
Direct cutover
An immediate replacement of the old system with the new system. =ilot
5he new system is tested in one site first. 5he rest of the sites will e installed upon
satisfactory results.
=hasein
!ndividual susystems are upgraded to new system in specific time frames.
9ith the new system implemented and running, a review should e performed to measure whether thenew system has achieved the intended purposes. An effective evaluation will identify the new systems
strengths and limitations. 5he evaluation report may include organisational impact, users and
management assessment, and development performance.
2(1 SDLC 5ea6"e!!e!
Analysts could seldom fully understand each others work. ne analysts might choose to descrie the
system using $nglish, another might choose to use flowcharts to represent the system, and anothermight choose comination of codes and $nglish to represent the system. 5he prolems posed are not
simply roke down of communication leading to difficult coordination, ut it also discourages futureenhancement.
!n a typical systems development life cycle, an analyst often document the system after the system hadeen uilt. !n other words, the documentation would usually reflect only those completed tasks thatwere rememered. Details, of sometimes even great importance, would e overlooked and not
documented. 5herefore, it is not surprising many analysts opt to leave out the documentation as theyperceive documentation as e@tra urdens.
9hen an analyst is assigned a comple@ system, he?she immediately falls ack to his?her intuition and
inspiration to comprehend the prolems. SDLC in no way provides a clue as how one may approach a
reasonale comple@ system. !n short, systems development in SDLC remains much an art.
2 - 6
8/13/2019 System Development Strategies
7/16
CHAPTER 2: INTRODUCTION TO SYSTEMS DEVELOPMENT STRATEGIES
2( Str*ct*re$ S+!te,! Dee#'p,e"t
Structured systems development asically comprises structured analysis, structured design, structuredcoding, and structured testing phases. Gou may view it as an enhancement on top of the classical
SDLC. !ts main focuses are:
=artition the system into smaller and more manageale components.
epresent the system in a graphical model, emphasising the information processing aspects.
6or this su>ect, we will however pay more attention to structured analysis "more detailed discussion
will e covered in chapter /%. !n structured analysis, it consists of four main components:
+raphic symols
!cons and conventions for identifying and descriing the components of a system and the
relationships among these components. Data dictionary
Descriptions of all data used in the system. Can e manual or automated "may e
included in a larger pro>ect dictionary that also contains descriptions of processes
making up the system%.
=rocedure and process description
6ormal statements using techniues and languages that enale analysts to descrie
important activities that make up the system.
ules
Standards for descriing and documenting the system correctly and completely.
4y far, Enited Hingdom is the country that has een very active and supportive in this approach. !n
fact, the EH government has adopted it as a standard in all their computer pro>ects development. 4elowis a rief coverage of the methodology.
2 - 7
8/13/2019 System Development Strategies
8/16
CHAPTER 2: INTRODUCTION TO SYSTEMS DEVELOPMENT STRATEGIES
2(() SSADM Ver!i'"
F 5he following notes, from here onwards, are e@tracted?modified from: An !ntroduction
to SSAD* 2ersion 0, Caroline Ashworth Laurence Slater"'((3%.
5he Structured Systems Analysis and Design *ethod "SSAD*% has een in use since '()' and hasgained a standing as the most widely used method for systems analysis and design in the Enited
Hingdom. !ts development has een controlled to ensure that the method has kept in step with estpractice on pro>ects, as well as taking into account developments in information systems technology. !t
has een used successfully on pro>ects of all siIes in a variety of environments, and although its rootsare in EH government and departmental computer pro>ects, it has een adopted y a growing numer
of pulic and private sector organisations worldwide.
SSAD* is used in the development of systems ut it does not cover the whole system lifecycle. !ts
starting point is assumed to e after the completion of a strategy or scooping study and an initialsetting up of the pro>ect and its end point is the production of a detailed physical design of the system.!ts coverage of the stages of the development lifecycle are represented in 6igure #.#.
SSAD* is often used in con>unction with other methods such as strategic planning, structured
programming, and structured testing methods in order to cover the complete lifecycle. !n addition, apro>ect management method is generally applied to control and monitor the whole development
lifecycle. 5hus, SSAD* is not a complete pro>ect method even in the part of the lifecycle it covers.
Figure 2.2: SSADM and the System Development Life Cycle
2 - 8
euirements
identification
Strategy
=reliminary
investigation
Design
Development
5esting
!mplementation
*aintenance
and review
Coverage of
SSAD*
8/13/2019 System Development Strategies
9/16
CHAPTER 2: INTRODUCTION TO SYSTEMS DEVELOPMENT STRATEGIES
Str*ct*re '& SSADM
5he structure of SSAD* version 0 is ased on the concept of modules. $ach module has a defined
purpose and a set of products that are detailed in the =roduct 4reakdown Structure. 5here is no e@plicitdependency etween modules even though, in practice, they will e performed in a defined seuence.
5he modules of SSAD* version 0 are shown in 6igure #.3. 5his shows that there are no direct linksetween modules ut that products from one module are used as an input to the ne@t module.
Figure 2.: !vervie" of Modules and #roducts
Tab#e 2()
M'$*#e Sta%e
6easiility J 6easiilityeuirements Analysis ' !nvestigation of Current $nvironment
# 4usiness System ptions
euirements Specification 3 Definition of euirementsLogical System Specification 0 5echnical System ptions
7 Logical Design=hysical / =hysical Design
5he reason for defining modules independently of one another is to make the method tailorale to
specific pro>ect needs. Some types of pro>ect may not need to use all of the modules or may find itpreferale to replace whole modules with alternative procedures more suited to their environment. 5he
discrete nature of SSAD* modules with clearly defined o>ectives and products makes this possile.Also a pro>ect can choose to undertake, say, only the euirements Analysis *odule to ascertain the
possile reuirements for a system without necessarily undertaking the further modules.
2 - 9
euirementsSpecification
*odule
Logical SystemSpecification
*odule
euirementsAnalysis
*odule
6easi:ilityStudy
*odule
=hysicalDesign
*odule
=hysical System
Specification
6easi:ility
eport
Analysis of
euirements
euirements
Specification
Logical System
Specification
8/13/2019 System Development Strategies
10/16
CHAPTER 2: INTRODUCTION TO SYSTEMS DEVELOPMENT STRATEGIES
$ach module encompasses either one or two stages, as shown in 5ale #.'. $ach stage is then roken
down into a numer of constituent steps. 5he steps within each stage and
their interdependency are detailed elow.
5he complete set of modules, stages, and steps, together with their descriptions, is called the structural
model.
2 - 10
=repare for the
6easi:ilityStudy
Define the
=ro:lem
Select
6easi:ilityptions
Assem:le
6easi:ilityeport
Pha!e ): 0ea!ibi#it+ St*$+ M'$*#e
Derive logical
view of
Current
Services
!nvestigate
Current
=rocessing
!nvestigate
and Define
euirements
$sta:lish
Analysis
6ramework
Assem:le
!nvestigation
esults
!nvestigate
Current Data
Select
4usiness
System ptions
Define
4usiness
System ptions
Pha!e 2: Re/*ire,e"t! A"a#+!i! M'$*#e
8/13/2019 System Development Strategies
11/16
CHAPTER 2: INTRODUCTION TO SYSTEMS DEVELOPMENT STRATEGIES
0ea!ibi#it+ St*$+ M'$*#e
5he reuirements for the new system are analysed y first studying the current environment to gain an
understanding of the usiness constraints and organisation within which the system will e reuired tooperate.
Re/*ire,e"t! A"a#+!i! M'$*#e
5his understanding of the environment is used, together with the statement of
reuirements given y users, to uild an outline picture of the new system efore specifying anythingin detail.
2 - 11
DefineeuiredSystem
=rocessing
Developeuired
Data *odel
DevelopSpecification
=rototypes
DeriveSystems
6unctions
Develop=rocessing
Specification
ConfirmSystem
:>ectives
$nhanceeuired
Data *odel
Assem:leeuirements
Specification
Pha!e 1: Re/*ire,e"t! Speci&icati'" M'$*#e
Select5echnical
System ptions
Define Eser
Dialogues
Define Epdate
=rocesses
Define5echnical
System ption
Define $nuiry
=rocesses
Assem:le
Logical Design
Pha!e 2: L'%ica# S+!te, Speci&icati'" M'$*#e
8/13/2019 System Development Strategies
12/16
CHAPTER 2: INTRODUCTION TO SYSTEMS DEVELOPMENT STRATEGIES
Re/*ire,e"t! Speci&icati'" M'$*#e
5he outline description of the new system is used as a asis for a detailed e@amination of the
reuirements, which involves modelling various different aspects of the system. 5hese models arecrosschecked with one another and some of the functions may e prototyped to gain a clear picture of
what is needed.
L'%ica# S+!te, Speci&icati'" M'$*#e
A detailed logical design of the processing and dialogue aspects of the system are then developed, inparallel with the final selection of the implementation platform for the system.
Ph+!ica# De!i%" M'$*#e
5he complete logical specification for the system is finally converted into a design that is specific to
the hardware?software configuration chosen for the system.F $nd of notes e@tracted?modified from: An !ntroduction to SSAD* 2ersion 0, Caroline
Ashworth Laurence Slater"'((3%.
2 - 12
Create 6unctionComponent
!mplementation
*ap
=repare for=hysical
Design
Complete6unction
Specification
Create =hysical
Data Design
ptimiIe=hysical Data
Design
Consolidate=rocess Data
!nterface
Assem:le
=hysical Design
Pha!e 3: Ph+!ica# De!i%" M'$*#e
8/13/2019 System Development Strategies
13/16
CHAPTER 2: INTRODUCTION TO SYSTEMS DEVELOPMENT STRATEGIES
2((1 Str*ct*re$ S+!te,! Dee#'p,e"t 5ea6"e!!e!
!n structured systems development, more time is spent analysing and designing the system, resulting in
additional upfront design costs. Some analysts argue that this additional cost will result a etter andmore accurate system eing uilt. -owever, the effectiveness is douted y some analysts as the whole
methodology is strongly ased on data flow analysis. !n other words, little or no consideration fororganisationBs culture and politics. !n addition, the cost of employing the rigorous and comple@
structured system development may outweigh the enefits of getting a simple system up and workingfast using simpler method.
As we can see from the previous discussion, structured analysis comprises a set of new tools with a list
of guidelines. 5his will mean analysts and programmers who have not practised the new approach will
need retraining programmes.
!n addition, structured systems development relies on accurate communication etween the analystsand the users. 5he users must e ale to relate specifically their duties and operations carried out. Agraphic representation of the description is then modelled. 5he model, however, is still much a logical
one. 5hat is to say, the model is an astract one.
Figure 2.$: #rototyping and the System Development Life Cycle
2 - 13
!dentify initialreuirement and
:uild a prototype
eview the
prototype
Systems
Design
Systems
Development
Systems
5esting
Systems!mplementation
and $valuation
efine the
reuirements
evise the
prototype
Dispose
prototype
Coverage of
=rototyping
System euest
8/13/2019 System Development Strategies
14/16
CHAPTER 2: INTRODUCTION TO SYSTEMS DEVELOPMENT STRATEGIES
2(3 Pr't't+pi"%
5he success of an information system depends strongly on the uality of the system analysis. !n spite ofall the availale structured methods and techniues for reuirements definition, it is clearly difficult to
discover e@actly what the user needs and desires in a system. Classical systems development often donot appeal to the user as it takes considerale time efore a working system is presented. As for the
structured method, it does not make enough allowance for the learning process in which a user mayecome knowledgeale on the limitations and the strengths of information technology. 5here is a clear
need for new and more effective approaches for reuirements definition prototyping is one of these.=rototyping did not gain popularity until the recent availaility of software tools, like screen generators
and CAS$.
2(3() Oerie7
!n prototyping, reuirements are identified together with users following a prototype is uickly
assemled. 5he users will then try the working model and feedack any corrections and?or
modifications.
8/13/2019 System Development Strategies
15/16
CHAPTER 2: INTRODUCTION TO SYSTEMS DEVELOPMENT STRATEGIES
2(4 E'#*ti'"ar+ I"&'r,ati'" S+!te,! Dee#'p,e"t
$volutionary information systems development is similar to the prototyping approach, e@cept that thereis never a completed version. An iterative revision of the system, even after implementation, is alwayse@pected. ne may view this development as a prototype that is kept evolving and is maintained to
cater for the latest systems needs. Some analysts thus argue that the evolutionary approach addressesthe prolem of dealing with change, an aspect which many other approaches do not address.
2 - 15
8/13/2019 System Development Strategies
16/16
CHAPTER 2: INTRODUCTION TO SYSTEMS DEVELOPMENT STRATEGIES
Reie7 8*e!ti'"!
'. Descrie Systems Development Life Cycle.
#. 4riefly discuss SSAD*.
3. Contrast the two approaches: Systems development life cycle and =rototyping.
0. List the weaknesses for each of the following development approach:
a. SDLC
. SSAD*
c. =rototyping
7. 4riefly descrie $volutionary !nformation Systems Development.
0*rther Rea$i"%
SSAD* 2ersion 0: A Esers +uide, *alcolm $va "'((#%, *c+raw-ill.
2 - 16