System Development Strategies

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


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


3/16


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


4/16


0ea!ibi#it+ St*$+


5/16


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


6/16


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


7/16


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/16


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*


9/16


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


10/16


$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


11/16


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


12/16


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


13/16


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


14/16


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.


15/16


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


16/16


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

System Development Strategies

Documents

Transcript of System Development Strategies