Unit 7: Systems analysis and Design

Add Comments

Introduction of System Analysis & Design

What is the purpose of System Analysis & Design

This is the process of looking at an existing system and then design a new system that can carry out the same task better.
If the developer developed the project without a proper planning or designs, they are usually faults and errors. Thus, it's time consuming and a waste of money.
If the project is carried out with a proper planning (system analysis and design), the potential faults are minimised and depleted.

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Okay before we start, let's break this topic into sections.

What is the "System Analysis" Part?

This is where the existing system is observed (analysed) in details.
Improvements are suggested and considered.

What is the " Design" part?

This is where detailed plans are created for the new system.
Plans are carefully produced, with its full intended purpose. This also help to minimise faults and errors.
These are like " blueprints" for the system developers to follow, like an explorer has a map to guide their way.

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

The SIX stages of system analysis and design

Here is a life cycle for you:

Analysis - researches to help you decide
Design - "sketches" of ideas
Development & Testing - create the system and test it, unofficially
Implementation - put it out to the public/ real use if the system is ready
Documentation - reports of details of steps you have done, instructions and manuals
Evaluation - how effective the new system is, looking for improvements

**EPOS means Electronic point of sale

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Before I start the topics: You should be able to know the flow chart system...

a HOW TO "FLOWCHART"

Let's Start with Step 1:

Analysis

What is analysis?

This is where the current system is looked in detail, in order to indicate the changes that are needed to be done, so that the system is better.
It is aim to see whether it is possible to create a suitable system, that will work at a reasonable cost.

These points are what you should be able to get from this "analysis" stage:

Describe how the current system works
identifies the problems with the current system
Proposes solutions to resolve the problems
Outline the resources (i.e hardware, software and people) required for the proposed solutions
Produce a cost-benefit analysis

How is this data obtained?

Finiding out information about the current/ proposed system is known as "Fact Finding"
These are the 4 methods which are used to obtain this information

Questionaires
Inteviews
Observing people using the current system
Looking at the current system's Documentation

<NOTE TO THE EDITOR Image required: the table>

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Design

What is "Design"?

Once there's a list of requirements of what needed to be added/ removed, we will need a plan(design).
It will show how it will look and how it will work.
The design of the new system have a lot of thoughts put into them, since we have to reduce faults and errors. Otherwise, if the design in not done properly, more faults and errors will appear later.
The design must also concern about time and expense.

What is include in these "Designs"?

In details it will look like this:

Designing the System Inputs

To get data into a system is a two-part process:

Data must first be ‘captured’ (collected in a way that then makes it easy to input)
Data must be input into the computer

The systems analyst will select a data capture method and data input method that best suit the requirements of the new system.

Choosing the Best Data Capture and Data Input Methods for the System

Collecting data into a form that is ready for input to a computer system can be done in many ways...

Paper Forms-Form can be a simple ones with spaces for numbers and text to be written in. The data form this form would then be typed into the computer

Forms can also be machine-readable, such as OMR forms

Barcode Reader

Barcode readers capture the numeric code that the barcode represents.

Before we use the hardware to input the data we need to

Designing"On-Screen Forms for Data Input"

Much of the data that enters computer systems needs to typed in. A well-designed on-screen form can make this task easier and quicker.

On-screen forms should...

Have all of the necessary fields
Have obvious places for user input (boxes, use of colour, etc.)
Use appropriate controls (see below) for each field
Have text box controls that are the right size for the data
Have easy-to-understand instructions (if needed)
Make good use of the screen area available

Form Controls

On-screen forms can have a variety of controls :

Textbox
Used for normal text input

Buttons
Used to perform an action

Option / Radio Buttons
Used to select an option (only one can be picked)

Tick / Check Boxes
Used to select options (more than one can be ticked)

Drop-Down Menus
Used to select options from a list

As data is entered into the form, it needs to be checked for accuracy. Two techniques help us do this: validation and verification...

Verification

A method for checking data entry for transcription errors- where there is a mistake when entering the data. This is a check the accuracy of data entry. There are two methods of verification:

Visual Check- is the data that has been typed in the same as the written on the sheet of paper?
Double entry- the data is typed twiced; check to identify any differences.

Validation

Data validation is very important: the designers will have to be sure that they have designed appropriate validation routines that will test the data input to the system.It's a software that ensures that the data that has been entered can be used by the system.

There are 8 commonly used validation checks. The designers will need to select the most appropriate one.

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Developing & Testing

The purpose of testing

Is to prove that the system works.During the "test", problems may be found, and adenments/ improvements may need to be made.

Testing Strategies

You can't just dive in and start testing. There needs to be a thorough plan, which can be documented, so that all aspects of the system are properly tested.

There are 4 main strategies

1. Analysis of test results

2. Test parts of the system using extreme or abnormal data

3. Test parts of the system using normal or live data

4. Test the whole system. Everything.

Why and How

1. How : Analysis of test results can be done by comparing two systems in parallel (at the same time). You would expect both systems to produce the same results. If not, something is wrong.

1. Why : This kind of testing is usually used to check that the results of calculations are correct or as expected.

2. How : Testing using extreme or abnormal data. Using abnormal data means putting data into the system which should either produce an error or be rejected. Using extreme data means checking the boundaries of fields are set correctly.

2. Why : This kind of testing shows how the system reacts to unusual or unexpected data. It can also be used to check error messages work as expected.

3. How : Testing using normal or live data. Normal data is obviously data that should work in the system and live data is simply data that has been used before, so you know how it should work and what outcomes to expect.

3. Why : These tests check that the system works as expected under normal circumstances and, in the case of live data, it shows whether calculations produce the correct outcome.

4. How : Testing the whole system is, er, testing everything! This is because systems usually consist of many parts or modules and it is essential to check the system as a whole works as expected

4. Why : To make sure all modules work together, that each part of the system produces data that can be used by other parts of the system and they integrate well.

Types of Test Data

There are 4 different types of test data that you can use to test a system. These are:

1. Normal data

2. Live data

3. Extreme data

4. Abnormal data

Normal data

Exactly what you'd expect. This is test data that you would expect to work completely with the system. For example, you'd type names into a name field, dates into a date of birth field. Why bother? Believe it or not, there can be situations where bugs in the software produced means it simply refuses to work as expected!

Live data

Live data is data which has been taken from the old or existing system and it's known to be in the correct format. It's data that, when you put it into the system, you know exactly the outcome to expect. This is very useful for testing that calculations produce the right results.

Extreme data

This is data that should be acceptable, but is right at the edges of any boundaries. What does that mean? Imagine you have a field that accepts the numbers 1-10. Extreme data for this field would be 1 and 10. You could also test 0 and 11. You'd expect 1 and 10 to work fine and 0 and 11 to be rejected. Simple.

Abnormal data

Simply, data that is unacceptable or in the wrong format. For example, entering letters into a field that accepts only numbers.

How tests are carried out.

Finally, you need to know the general way that tests should be carried out. If ever you get asked how to test a system, this is it:

1. A test table is created which shows the test data to be used and the results expected

2. The data is then input into the system

3. The results of each test is recorded

4. The actual results are compared with each expected result

5. Any differences show the limitations of the system.

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Implementation

After a new computer system has been developed and tested, it has to be implemented before it can be used.

Even after testing, there can still be problems with a new computer system. These may have been caused by programming errors or analysis errors. The more critical the system, the more care needs to be taken to reduce the risks of system failure following the implementation of a new system:

Methods of Implementation

There are four methods you need to know:

1. Direct

2. Parallel

3. Phased

4. Pilot

Direct

This is the nuclear option. You put the new system in, turn off the old, cross your fingers and pray it works.

Picture

This is great if you want the cheap option, you've very little cash so you've no choice but to move straight to the new system. Why? Because all of the other methods of implementation require you to at least keep some of the old system running - this is bad if you're short of money because you're doing work twice, paying for two systems to run at once and your staff are not being as productive as they could be if they were focussed on one system.

In all other circumstances, direct implementation is probably a bad idea!

Why?

Because if the new system breaks, and they always do, you've nothing to fall back on - the old system is gone! This could mean you can't produce things, your workers have nothing to do and you lose a lot of money waiting for the system to be fixed before you can continue.

Parallel

A safe option, with some obvious issues. When a system is implemented in parallel, the following happens:

1. The old system stays online, and is still used as normal.

2. The new system is installed and is used by the workforce.

3. BOTH systems are used at the same time, doing the same things.

4. When the client/users are happy that the new system works without issues or errors, then the new system is turned off.

There are some very obvious advantages here. Primarily, should the new system break in any way, then productivity is not affected. This is because the old system is not only still running, but still has all of the latest information stored in it. If there is a problem during a parallel implementation then the organisation should be able to seamlessly continue using the old system until the new one is fixed.

The disadvantage of this method is that it is relatively expensive. To run two systems in parallel, usually requires more staff, or existing staff to do the same tasks twice so that data is entered on to both old and new systems. This can, quite expectedly, slow down productivity.

Phased

Phased implementation has many similarities to the parallel method. The old system keeps running, but is gradually replaced, bit by bit, by the new system. As each part of the new system is brought online, data is gradually moved to the new system.

The advantage to a phased implementation over the parallel method, is that work is not carried out twice. The parts of the new system that have been turned on will be used exclusively, and those parts of the old system will be switched off.

The disadvantage of this method is that users must know how to use two systems at once and tasks may not split efficiently between the two systems. Also, there may be situations where the new system requires data stored on the old system.

Pilot

Finally, there is the pilot method. This is effectively a combination of direct and parallel changeover, however it's only really suitable for large organisations.

This method has the advantage to large organisations that they can test the system in a "real world" situation which practically guarantees it will work relatively trouble free in all of their stores.

The problem with testing is often that, even with the most well prepared of test plans, you can't always reproduce every scenario that may occur in the real world. By running the system as a pilot, you expose it to real world users who are, honestly, excellent at breaking things and discovering weaknesses. This obviously means that the system is thoroughly tested and theoretically more reliable when it's rolled out throughout the organisation.

Disadvantages? This method of implementation can sometimes take a long, long time. If many limitations with the system are discovered, there can be a long period of redevelopment before it is ready for release.

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Documentation

There are two types of documentation that should be produced when creating a new system:
User documentation

User Documentation-The users are usually non-technical people, who don't need to know how the system works. They just need to know how to use it.

User documentation usually includes:

List of minimum hardware and software required to use the system
How to install the system
How to start / stop the system
How to use the features of the system
Error Handling/ FAQ
A troubleshooting guide

Technical documentation-The user documentation is intended to help the users of the system.

The technical documentation is intended to help the maintainers of the system (the people who need to keep the system running smoothly, fix problems, etc.)

The maintainers are usually technical people, who need to know exactly how the system works.

Technical documentation usually includes:

Details of the hardware and software required for the system
Details of data structures (data types, field names, etc.)
Details of expected inputs
Details of validation checks
Details of how data is processed
Diagrams showing how data moves through the system
Flowcharts describing how the system works

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Evaluation

Once the new system has been implemented and is in full use, the system should be evaluated (Basically, this means that we take a long, critical look at it).

The purpose of an evaluation

is to assess the system to see if it does what it was supposed to do, that it is working well, and that everyone is happy with it.

Compare the final solution with the design objectives set out in the analysis stage.
Test result from your solution may be given here or in the testing stage.
Have your solution tested in situation, doing the real task as set out in the analysis.
Document the opinions of other users testing and using your solution.
State the improvements made to the program as a result of testing.
State any enhancements and improvements that could be implemented.

Best ICT blog