CHAPTER 2: INTRODUCTION TO SYSTEMS DEVELOPMENT STRATEGIES
Chapter Objecti e!
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 .Chapter ', page ' , ')1 Laurence Slater "'((3%, *c+raw,-ill. &oseph &.
Systems Analysis and Design, +ary 4. Shelly, 5homas &. Cashman, &udy Adamski Adamski "'(('%, 4oyd 6raser. .Chapter ', page '# , '71
2-1
CHAPTER 2: INTRODUCTION TO SYSTEMS DEVELOPMENT STRATEGIES
2()
I"tr'$*cti'"
According to 89e:ster;s <inth <ew Collegiate Dictionary8, strategy is defined as the art of devising or employing plans or stratagems toward a goal. !n information systems development, there are three main strategies: Systems Development Life Cycle Structured Systems Development =rototyping
5he :enefits of these strategies are a num:er. A strategy is like that of a compass which can guide you through a >ungle. 9ithout a compass, although one may still find his?her way out of the >ungle, it will :e 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@periences of 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 managing systems 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 system;s characteristics 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@t:ooks 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 highest possi:le results.
2(2
S+!te,! De e#'p,e"t Li&e C+c#e
5he !+!te,! $e e#'p,e"t #i&e c+c#e -SDLC. is a classical and systematic approach employed :y systems analysts to develop an information systems. Although analysts opine differently on the num:er 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. Anly a limited time is usually given 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 achieva:le :y considering current technology, organisationBs commitment, assigned :udget and availa:le resources. 5hree su:,activities are :asically involved: reCuest clarification, feasi:ility study, and reCuest approval.
2-2
CHAPTER 2: INTRODUCTION TO SYSTEMS DEVELOPMENT STRATEGIES
System DeCuest
PHASE OUTPUT
=hase ' =reliminary !nvestigation
=reliminary !nvestigation Deport
=hase # DeCuirement Determination
System DeCuirements Document
=hase 3 Systems Design
System Specifications
=hase 0 Systems Development
=rocedure manuals Software
=hase 7 System 5esting
5ested Software
=hase / Systems !mplementation And $valuation
9orking System $valuation Deport
Aperational !nformation System
Figure 2.1: System Development Life Cycle Re/*e!t C#ari&icati'" *anagement or an end user may reCuest systems development. 5here are many reasons that trigger off a reCuest for system development. As an analyst, you should identify clearly the nature and scope of such reCuest.
2-3
CHAPTER 2: INTRODUCTION TO SYSTEMS DEVELOPMENT STRATEGIES
0ea!ibi#it+ St*$+ <e@t, the reCuest should :e e@amined for feasi:ility in terms of: 5echnical feasi:ility $@amine whether the new system can :e delivered with current technology.
$conomic feasi:ility
9eigh the availa:ility of resources "e.g. the :udget and time% and the cost to :e incurred against the potential :enefits of the new system. Aperational feasi:ility Determine the acceptance level of the new system if it is to :e implemented.
5his feasi:ility study may :e performed :y a system analyst, or a manager, or a committee. !t is advisa:le that these people understand certain aspects of the :usiness organisation, familiar with systems development techniCues, and have e@perienced in pro>ect management. Re/*e!t Appr' a# After careful feasi:ility study, a preliminary investigation report specifying the scope, perceived pro:lems and opportunities, and recommended actions should :e compiled and su:mitted for approval. !f the pro:lem and solution approved are minor, then simply proceed to systems development phase. 5he ma>ority would recommend further detailed analysis. Esually, the management are in,charged of the approval. <ot all reCuests are approved, sometimes re>ected. 5hose that are approved, each of its :udget, priority, schedule and resources are estimated, and add to any pro>ect list. F 5he following notes, from here onwards, are e@tracted?modified from: System Analysis and Design, +ary 4. Shelly, 5homas &. Cashman, &udy Adamski &oseph &. Adamski "'(('%.
2(2(2
Re/*ire,e"t! Deter,i"ati'"
5his is the heart of a system development. 5he purpose of the reCuirements determination phase is to learn e@actly what takes place in the current system, to determine and fully document in detail what should take place, and to make recommendations to management on the alternative solutions and their costs. 5hrough the process of fact,finding or reCuirements determination, you first define all the functions performed :y the current information system. At the same time, you determine what modifications are needed :y the organisation in the improved version of the information system. After you have o:tained the facts, you then analyse and evaluate them in a systematic fashion in order to develop alternative plans to resolve the pro:lems found in the current information system. 5his process is called reCuirements analysis; other names sometimes used for this process are systems definition and general design.
2-4
CHAPTER 2: INTRODUCTION TO SYSTEMS DEVELOPMENT STRATEGIES
5he end product you create for this life cycle is the system reCuirements document, which documents all end user and management reCuirements, all alternative plans and their costs, and your recommendations 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 software package, 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, systems implementation and evaluation "if the package can :e used as is%. !f management;s of alternatives is for in,house developed software, then you enter the third phase, systems design. 6inally, management might 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 reCuirements. Gou must design all reCuired information system outputs, files, inputs, application software programs, and manual procedures. Also you must design the internal and e@ternal controls, which are computer,:ased and manual steps that guarantee the information system will :e relia:le, accurate, and secure. 5he design is documented in the system design specification and presented to management and the end users for their review and approval. *anagement and end user involvement is critical so that there is no misunderstanding a:out 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(2
S+!te,! De e#'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 o:tained. 5he end product of this phase 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"%
Ane 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 DeCuirements Document. !n addition, the information system developed is relia:le and accurate, and the users are a:le to operate the new system in foreseen ways. 5est data are usually prepared for this phase. Gou, however, should note 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 pro:a:ly even tolerated the e@pected faults.
2-5
CHAPTER 2: INTRODUCTION TO SYSTEMS DEVELOPMENT STRATEGIES
2(2(4
S+!te,! I,p#e,e"tati'" a"$ E a#*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, the new 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 the following 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 upon
5he new system is tested in one site first. 5he rest of the sites will :e installed satisfactory results. =hase,in !ndividual su:systems are upgraded to new system in specific time frames.
9ith the new system implemented and running, a review should :e performed to measure whether the new system has achieved the intended purposes. An effective evaluation will identify the new system;s 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 other;s work. Ane analysts might choose to descri:e the system using $nglish, another might choose to use flowcharts to represent the system, and another might choose com:ination of codes and $nglish to represent the system. 5he pro:lems posed are not simply :roke down of communication leading to difficult coordination, :ut it also discourages future enhancement. !n a typical systems development life cycle, an analyst often document the system after the system had :een :uilt. !n other words, the documentation would usually reflect only those completed tasks that were remem:ered. 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 they perceive 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 pro:lems. SDLC in no way provides a clue as how one may approach a reasona:le comple@ system. !n short, systems development in SDLC remains much an art.
2-6
CHAPTER 2: INTRODUCTION TO SYSTEMS DEVELOPMENT STRATEGIES
2(2
Str*ct*re$ S+!te,! De e#'p,e"t
Structured systems development :asically comprises structured analysis, structured design, structured coding, 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 managea:le components. Depresent 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 sym:ols
!cons and conventions for identifying and descri:ing 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 descri:e
6ormal statements using techniCues and languages that ena:le analysts to important activities that make up the system. Dules Standards for descri:ing 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. 4elow is a :rief coverage of the methodology.
2-7
CHAPTER 2: INTRODUCTION TO SYSTEMS DEVELOPMENT STRATEGIES
2(2()
SSADM Ver!i'" 2
!ntroduction
F 5he following notes, from here onwards, are e@tracted?modified from: An to SSAD* 2ersion 0, Caroline Ashworth Laurence Slater"'((3%.
5he Structured Systems Analysis and Design *ethod "SSAD*% has :een in use since '()' and has gained 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 ;:est practice; 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 roots are in EH government and departmental computer pro>ects, it has :een adopted :y a growing num:er of pu:lic 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 initial ;setting 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, a pro>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.
Strategy
=reliminary investigation
*aintenance and review
DeCuirements identification
!mplementation
Coverage of SSAD*
Design
5esting
Development
Figure 2.2: SSADM and the System Development Life Cycle
2-8
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@plicit dependency :etween modules even though, in practice, they will :e performed in a defined seCuence. 5he modules of SSAD* version 0 are shown in 6igure #.3. 5his shows that there are no direct links :etween modules :ut that products from one module are used as an input to the ne@t module.
6easi:ility Study *odule
6easi:ility Deport
DeCuirements Analysis *odule
Analysis of DeCuirements
DeCuirements Specification *odule
DeCuirements Specification
Logical System Specification *odule
Logical System Specification
=hysical Design *odule
=hysical System Specification
Figure 2. : !vervie" of Modules and #roducts
Tab#e 2() M'$*#e 6easi:ility DeCuirements Analysis DeCuirements Specification Logical System Specification =hysical
Sta%e J ' # 3 0 7 /
6easi:ility !nvestigation of Current $nvironment 4usiness System Aptions Definition of DeCuirements 5echnical System Aptions Logical Design =hysical Design
5he reason for defining modules independently of one another is to make the method tailora:le to specific pro>ect needs. Some types of pro>ect may not need to use all of the modules or may find it prefera:le 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 possi:le. Also a pro>ect can choose to undertake, say, only the DeCuirements Analysis *odule to ascertain the possi:le reCuirements for a system without necessarily undertaking the further modules.
2-9
CHAPTER 2: INTRODUCTION TO SYSTEMS DEVELOPMENT STRATEGIES
$ach module encompasses either one or two stages, as shown in 5a:le #.'. $ach stage is then :roken down into a num:er of constituent steps. 5he steps within each stage and
=repare for the 6easi:ility Study
Define the =ro:lem
Select 6easi:ility Aptions
Assem:le 6easi:ility Deport
Pha!e ): 0ea!ibi#it+ St*$+ M'$*#e
their interdependency are detailed :elow. 5he complete set of modules, stages, and steps, together with their descriptions, is called the structural model.
!nvestigate and Define DeCuirements
$sta:lish Analysis 6ramework
!nvestigate Current =rocessing
Derive logical view of Current Services
Assem:le !nvestigation Desults
!nvestigate Current Data
Define 4usiness System Aptions
Select 4usiness System Aptions
Pha!e 2: Re/*ire,e"t! A"a#+!i! M'$*#e
2 - 10
CHAPTER 2: INTRODUCTION TO SYSTEMS DEVELOPMENT STRATEGIES
0ea!ibi#it+ St*$+ M'$*#e
Develop DeCuired Data *odel
Develop Specification =rototypes
Derive Systems 6unctions Define DeCuired System =rocessing $nhance DeCuired Data *odel
Develop =rocessing Specification
Confirm System A:>ectives
Assem:le DeCuirements Specification
Pha!e 1: Re/*ire,e"t! Speci&icati'" M'$*#e
5he reCuirements 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 reCuired to operate. Re/*ire,e"t! A"a#+!i! M'$*#e 5his understanding of the environment is used, together with the statement of reCuirements given :y users, to :uild an outline picture of the new system :efore specifying anything in detail.
Define Eser Dialogues
Define Epdate =rocesses
Define $nCuiry =rocesses
Assem:le Logical Design
Define 5echnical System Aption
Select 5echnical System Aptions
Pha!e 2: L'%ica# S+!te, Speci&icati'" M'$*#e
2 - 11
CHAPTER 2: INTRODUCTION TO SYSTEMS DEVELOPMENT STRATEGIES
Re/*ire,e"t! Speci&icati'" M'$*#e
Create 6unction Component !mplementation *ap
=repare for =hysical Design
Complete 6unction Specification
Create =hysical Data Design
AptimiIe =hysical Data Design
Consolidate =rocess Data !nterface
Assem:le =hysical Design
Pha!e 3: Ph+!ica# De!i%" M'$*#e
5he outline description of the new system is used as a :asis for a detailed e@amination of the reCuirements, which involves modelling various different aspects of the system. 5hese models are cross,checked 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, in parallel 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
CHAPTER 2: INTRODUCTION TO SYSTEMS DEVELOPMENT STRATEGIES
2(2(1
Str*ct*re$ S+!te,! De e#'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 and more accurate system :eing :uilt. -owever, the effectiveness is dou:ted :y some analysts as the whole methodology is strongly :ased on data flow analysis. !n other words, little or no consideration for organisationBs 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 working fast 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 analysts and the users. 5he users must :e a:le to relate specifically their duties and operations carried out. A graphic representation of the description is then modelled. 5he model, however, is still much a logical one. 5hat is to say, the model is an a:stract one.
System DeCuest Coverage of =rototyping Devise the prototype Deview the prototype Dispose prototype Define the reCuirements Systems Design
!dentify initial reCuirement and :uild a prototype
Systems Development
Systems 5esting
Systems !mplementation and $valuation
Figure 2.$: #rototyping and the System Development Life Cycle
2 - 13
CHAPTER 2: INTRODUCTION TO SYSTEMS DEVELOPMENT STRATEGIES
2(3
Pr't't+pi"%
5he success of an information system depends strongly on the Cuality of the system analysis. !n spite of all the availa:le structured methods and techniCues for reCuirements definition, it is clearly difficult to discover e@actly what the user needs and desires in a system. Classical systems development often do not appeal to the user as it takes considera:le 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 may :ecome knowledgea:le on the limitations and the strengths of information technology. 5here is a clear need for new and more effective approaches for reCuirements definition , prototyping is one of these. =rototyping did not gain popularity until the recent availa:ility of software tools, like screen generators and CAS$.
2(3()
O er ie7
!n prototyping, reCuirements are identified together with users following a prototype is Cuickly assem:led. 5he users will then try the working model and feed:ack any corrections and?or modifications. <ecessary amendments and improvements will :e made. 5he users will then test the refined model and the whole process will repeat until the prototype is :een accepted "as shown in figure #.0%. =rototyping can therefore :e seen as a much improved form of systems investigation and analysis, as well as an aid to design. Esers will get to try out a working model, rather than an a:stract understanding of what the systems would :e. As for the analysts, they can :etter encourage the users; participation as well improve their communication :etween the users. 9e will e@amine this approach in greater depth in Chapter 0.
2(3(2
Li,itati'"! '& Pr't't+pi"%
=rototyping is used only as a development tool, as a learning vehicle. =rototype lacks features, like efficiency and incomplete functions, which are essential in an operational system. -owever users may perceive the prototype as the final system. 9hen the final system is delivered, any difference in performance or presentation may upset users. Aften due to time constraints, a prototype is intended to :e constructed Cuickly. As some analysts would prefer to la:el such prototype as 8Cuick and dirty8. !n other words, the prototype may have the following undesira:le characteristics: !nefficient performance =oor documentation !ncomplete features
2 - 14
CHAPTER 2: INTRODUCTION TO SYSTEMS DEVELOPMENT STRATEGIES
2(4
E '#*ti'"ar+ I"&'r,ati'" S+!te,! De e#'p,e"t
$volutionary information systems development is similar to the prototyping approach, e@cept that there is never a ;completed; version. An iterative revision of the system, even after implementation, is always e@pected. Ane 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 addresses the pro:lem of dealing with change, an aspect which many other approaches do not address.
2 - 15
CHAPTER 2: INTRODUCTION TO SYSTEMS DEVELOPMENT STRATEGIES
Re ie7 8*e!ti'"!
'. #. 3. 0. Descri:e Systems Development Life Cycle. 4riefly discuss SSAD*. Contrast the two approaches: Systems development life cycle and =rototyping. List the weaknesses for each of the following development approach: a. :. c. 7. SDLC SSAD* =rototyping
4riefly descri:e $volutionary !nformation Systems Development.
0*rther Rea$i"%
SSAD* 2ersion 0: A Eser;s +uide, *alcolm $va "'((#%, *c+raw,-ill.
2 - 16
