Sunteți pe pagina 1din 14

System Development

11.1 Introduction
11.1.1 Project Selection
A business organisation may have more than one reason for the introduction of
computers. Usually a particular area of the business is selected for computerisation.
Reasons why an organisation may computerise an area of business:
There is a large amount of data that requires repetitive processing.
There is a need for better access for up-to-date information.
Clerical costs could be reduced.
There may also be indirect benefits to customer service or cash flow.
or the pro!ect to be successful it must not be too comple".
11.1.3 The Systems Life Cycle
Commercial systems all share a commom life cycle pattern.
#usiness systems may need to change because of:
e"pansion
change of business activities
the economic situation
technological advances
or other factors
System Development
11.2 Anlysis
11.2.1 Pro!lem Definition
The first step is to write down the terms of reference.
The terms of reference may well include:
"!jectives - $hat the system should acheive.
%mproved customer service.
#etter management information.
Cope with larger volumes of business.
Constrints
&a"imum cost.
Avaliable equipment.
Any business area not to be changed.
Timescle - A special constraint.
#eports - $hat output is required.
Su$$ested Solutions - #y management.
11.2.2 %esi!ility Study
Technolo$icl %esi!ility
%s the hardware able to meet the demands put upon it'
Socil %esi!ility
$hat will be the effect on employees and customers if the new system is implemented'
&conomic %esi!ility
$ill the new system be cost effective'
11.2.3 %urther Anlysis
%ct #ecordin$ And Investi$tion
The analyst is interested in:
The procedures
The data
The future
(ews reports
)roblems
The following are ways of investigating e"isting procedures and the e"isting problems:
*bservation
Reading e"isting documentation
+uestionnaires
Tas, counting - by clerical staff
%nterviews
System Development
11.3 Desi$n
%n designing a new system all aspects of the design must be documented.
11.3.1 Systems Specifiction
This involves:
designing screen layouts and reports formats.
specifying file contents and organisation.
11.3.2 Prototypin$
This is an aid to better- faster- systems design.
%n a computing conte"t- prototyping involves building a simple model of software under
development.
This could involve using special software to quic,ly design input screens and validate
data input.
This gives the user a chance to e"perience the loo, and feel of the input process.
(ote that prototyping would also be used during analysis.
11.3.3 Computer Aided Soft're &n$ineerin$ (CAS&)
These are software tools that insist in the design or development of a system.
&*mples of CAS& soft're+
,rphics Tools - to draw structure diagrams- data flow diagrams- etc.
Interfce ,enertor - for rapid prototyping.
Project -n$ement Tools - schedule the steps in analysis- design- coding and
testing.
11.3.. Desi$n Choices
irstly decide upon:
Processin$ -ethod
The systems designer will need to chose between #atch )rocessing and *n-.ine
)rocessing. This decision will be dependant on:
how often the data changes.
the volume of data.
the cost of hardware.
how the data is collected.
Soft're Solution
%n general there will be many different solutions to a problem.
The following affect this choice:
Usability
)erformance
/uitability
&aintenance
/rd're Solution
This depends on many factors- for e"ample:
The software
0olume of data
(umber of users and their locations
)rocessing method
/ecurity considerations
System Development
11.. ,rphicl System #epresenttion
There are several various methods for representing computer systems.
11...1 Dt %lo' Di$rms
This type of representation is concerned with how data moves through a system not with
such details as what type of data storage is used.
/ource or destination of data e"ternal to the system.
An operation on data which transforms it.
Any stored data without reference to the physical method of
storage.
This represents the movement of data between any of the above.
Conventions
1. 2ata flows may not go directly to and from data stores and entities.
3. 2ata flows must be labelled to indicate what data is been transferred.
11...2 System %lo' Chrts
A systems flow chart shows an overview of the whole system. %n particular it represents:
Tas,s to be carried out.
The hardware devices.
The inputs- outputs and storage media.
The files.
%nput4*utput
5eyboard %nput
)rocess
&anual *peration
/ort
*ff )age Connector
*nline /torage
&agnetic Tape
2is, /torage
0isual 2isplay
$ritten or )rinted 2ocument
&*mple
2ata validation of mail order forms.
System Development
11.0 Development
11.0.1 Pro$rm Development
6ach program in the system must have a specification written for it which describes what
it will do 7and how it will do it8.
The program specification could be accompanied by:
)suedocode
lowcharts
Applictions ,enertor
These are software tools that generate complete systems. The user defines the input-
output- data- files and what the system needs to do. The applications generator then
produces the program code.
#eport ,enertor
A report generator will produce reports from information supplied by the user. The way
that they wor, is that the user supplies the headings- the fields to be printed- what order
they are in- the space to allow for each field and what totals are required.
CAS& Tools %or Development
The CA/6 software tools that aid the programmer in the development stage are:
A source code generator
A data dictionary tool
Applictions Pc1$es
)rograms may not need to be written for the new system. %f an 9off-the-shelf9 pac,age
may be suitable then it is the analyst:s !ob to evaluate the pac,age and ma,e sure that it
will meet the requirements.
11.0.2 &2uipment Ac2uisition
ollowing the hardware considerations in the design stage of the life cycle- sutiable
equipment needs to be acquired.
System Development
11.3 Testin$
11.3.1 Acceptnce Testin$
The tas,s the finished system must perform in order to be accepted 7by the user8 can be
used as the basis for different tests.
11.3.2 Pro$rm Testin$ Strte$ies
4ottom56p Testin$
The individual modules are tested in a stand-alone fashion. The individual modules are
combined and tested. inally- a system test is performed.
Top5Do'n Testin$
The whole system 7or at least a s,eleton of it8 is tested. %ndividual modules- yet to be
completed- are replaced by :stubs:. /tubs often display a message on screen to show that
the module has been called.
11.3.3 The Test Pln
A test plan should be developed which will go through as many paths as possible in the
system.
or each test the following points should be included:
the test:s purposes.
the test:s location.
a description of the test.
testing procedure.
Test data should test the program to its limits.
%t should include:
data in the e"tremes
invalid data
commonly entered data
11.3.. "!jectives "f Testin$
$e need to as,:
2oes the logic wor, properly'
- does it wor, as intended'
- any runtime errors'
%s all the logic present'
- any functions or sub-programs missing'
11.3.0 7hite And 4lc1 4o* Testin$
7hite 4o* Testin$ (or Lo$icl Testin$)
$e test the program by e"amining the code and trying to test each possible path in the
program at least once.
4lc1 4o* Testin$ (or %unctionl Testin$)
%n #lac, #o" we are not concerned with the program code. The progarm specification is
used as the basis for producing a set of test data that covers all the inputs- outputs and
program functions
11.3.3 "ther Types "f Testin$
Performnce Testin$
The system is tested to see if it can handle the volume of data anticipated in the user
environment.
#ecovery Testin$
;ere we need to ensure that the system can recover from various types of failure.
/uch tests can be performed by simulating hardware or power failures.
System Development
11.8 Implementtion
11.8.1 /rd're Instlltion
#efore the new system can come into operation hardware will probably have to be
installed. This may include:
(ew computers
(ew peripherals
(ew office layout and furniture
11.8.2 Stff Trinin$
)rior to the new system going live- all the staff involved in the system will need hands on
training.
Realistic data should be used in briefing.
11.8.3 Cretion "f -ster %iles
All the master files will have to be created before the system can be used.
Typically- there are two phases:
Phse 1
All the data that will not change can be typed in over a few days or wee,s.
Phse 2
2ata that is liable to change needs to be ,eyed in !ust before the changeover to the new
system.
11.8.. Conversion -ethods
. Direct Chn$eover
The organisation stops using the old system one day and starts using the new
system the ne"t.
Advnt$es
o ast
o 6fficient
o .ittle or no duplication of wor,
Disdvnt$es
o %f the new system fails then there will be serious disruption
!. Prllel Conversion
The old system is ,ept running alongside the new system for a few wee,s or
months.
Advnt$es
o The old system can be relied upon while any problems with the new
system are fi"ed
o Results from the new system can be chec,ed against the old system
Disdvnt$es
o There:s a heavy wor,load on staff
c. Phsed Conversion (Direct or Prllel)
This is used with larger system that can be bro,en down into several stages.
6ach part of the system can be implemented at different times.
d. Pilot Conversion
*nly a part of the organisation uses the new system at first.
System Development
11.9 -intennce
11.9.1 Post Implementtion #evie'
This is carried out several wee,s or months after the system has been implemented.
/mall changes may need to be made:
or e"ample:
Correct program errors
Amend clerical procedures
&odify screen and report formats
11.9.2 Perfective -intennce
;ere we are concerned with ta,ing an acceptable system and ma,ing it better.
11.9.3 Adptive -intennce
As the system requirements change- the system needs updating.
11.9.. Corrective -intennce
There may still be problems with our system that need to be corrected.
System Development
11.: System Documenttion
11.:.1 The Aims "f Documenttion
To assist system design
To ensure everyone understands how their aspect of the system should wor,
To help greatly in system maintenance
11.:.2 The Documenttion Contents
A system specifiction
System flo' chrts or dt flo' di$rms
Pro$rm descriptions
Structure di$rms; pro$rm flo' chrts nd pseudocode
%iles or dt!se descriptions
Lyouts for screen disply nd reports
Current pro$rm listin$s
Test dt 'ith e*pected results
Clericl procedures mnul
This describes the activities that clerical staff underta,e when preparing data for
input to the system.
%t will also detail what action should be ta,en if an error occurs.
"pertin$ instructions
This tells the computer operator how to run the program.
Dt preprtion instructions
This details how to enter data what format the data should be in.
11.:.3 Documentin$ A Soft're Pc1$e
This may include:
A user manual
A technical manual4operations manual
Tutorials

S-ar putea să vă placă și