Systems Analysis, Prototyping and Iteration

Systems Analysis This is a process used in the design

of new systems. Systems analysis follows stages of investigationinvestigation, designdesign and implementationimplementation.

Each stage should involve close consultation with potential users, in the various functional areas of the organisation, to ensure that their information and operational requirements are met.

The design stage should produce a system specification, which should detail all necessary materials and procedures needed to fulfill the specification.

The specification should detail all the necessary clerical procedures, hardware requirements and the inputs, processing and outputs required of the computer software.

After implementation of a system, it will require continual monitoring and probably, occasional modification, when the operational or information requirements of users change. This maintenance task is the responsibility of the systems analyst.

SDM Waterfall Model

Feasibility The feasibility study determines whether a

particular development project should go ahead. If the project is to proceed then a project plan and budget estimate for the other stages of development will be produced.

Requirements analysis The requirements for the new or modified

system are gathered at this stage. They should be recorded so that at the end of the project the software can be tested to ensure it fulfills the requirements.

Design specification Design focuses on:

high level design, e.g. what programs are needed, what are their inputs and outputs, what are their interactions with other software or the operating system.

low level design, e.g. how will the program work, what models or algorithms will be used, what libraries are required.

data design, e.g. for input and output, data structures in the software. The level of detail in the design may be a matter of personal choice or

may be specified by particular development procedures. Having a detailed design will make generating the code easier but will make changing things difficult whereas a more broad brush design will leave more work in the implementation phase but allows room for the details to come out as the development progresses. Above all the design should be documented including reasons for making particular choices if a number of options were available. This makes it much easier for new developers to join a project and helps when new features are required.

Coding In this phase the designs are translated into code.

Programming tools such as compilers and quality assurance tools are used to generate good quality source code and the software application. Testing of small self-contained parts (modules) of the overall application may take place depending on the modularity of the code.

Testing The overall system is tested to ensure that it works on

the intended platform(s), giving correct results or showing the required behaviour defined in the requirements document. The use of debuggers and profiling tools will be useful at this stage to identify errors in the code and get the best possible performance from the code. Optimum performance is especially important in scientific computing applications.

Maintenance Once the system is delivered to users it will

inevitably need maintenance. There may be bugs caused by unexpected input values (add them to a test suite) or by unexpected (inappropriate) use of the software (tighten up the documentation). In addition users will want more or different functionality and will definitely want it to run faster or address bigger problems! The software development process should be able to accommodate changes at this stage through a well thought out design and any changes should have their own requirements, design, coding and testing stages.

In the waterfall model, it is possible to rework earlier stages in the light of experience gained at a later stage. Each stage is signed off and the next stage is proceeded with. However the end user is rarely involved in the development stage, even though they may well be involved in signing off. It is therefore critical that the analysts and the programmers understand the end-users’ requirements. This can be quite difficult with the waterfall model.

The waterfall model has disadvantages, which can be overcome using Prototyping, in which a model of the system is developed in partnership with the end-user. The features are worked out with the end user using a prototype, and the end user can have a considerable input into the development of a project.

Benefits are:

Misunderstandings are detected at early stages

The user will notice any missing functions, incomplete or inconsistent requirements.

Can be built quickly to demonstrate systems

It can be used for training before the system is finished

Benefits are:

Misunderstandings are detected at early stages

The user will notice any missing functions, incomplete or inconsistent requirements.

Can be built quickly to demonstrate systems

It can be used for training before the system is finished

Drawbacks are: Project management can be

uncoordinated or even sloppy. Meetings with end users can

become time consuming. The final result could be

completely different to what was requested in the first place.

Different Methods of Prototypes

Piloting – Test the feasibility of the design proposal

Modelling – building to develop an understanding of the user’s requirements

Throw-away prototyping – Pilot and modelling are throw away types – once they achieve their purpose the real system is built.

Evolutionary prototyping – each prototype built is a step closer to solution.