Evaluation

 

 

Once the new system has been implemented and is in full use, the system should be evaluated (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.

What Does an Evaluation Look For?

When the systems analyst evaluates the new system, the following questions will be asked:

Is the system efficient?

Does it operate quickly, smoothly and with minimal waste?

Is the system saving time, and resources?

Is the system easy to use?

Are all of the system's users able to use the system easily and effectively?

Can new staff understand and use the system with minimal training?

Is the system suitable for that particular business / organisation?

Does the system actually meet the needs of the business / organisation?

How is a System Evaluated?

The systems analyst will use a number of techniques to evaluate the system...

Check against the Requirements Specification

If you remember, earlier on in the Systems Analysis, the old system was analysed, and a checklist of targets was drawn up for the new system.

This list was called the Requirements Specification.

The systems analyst will use this document to check the new system. Going through the requirements one-by-one the analyst will check if they have been met.

 

Check the Users' Responses

It is essential to get feedback from the users of the system...

• Do they like it?
• Does it make their work easier?
• What, if anything, could be improved?

The systems analyst can get this feedback in the same way they collected information about the original system.

 

What Happens Next?

The outcome of the evaluation will be to identify any limitations or problems with the new system.

The system analyst will then need to begin the task of system analysis from the beginning, but this time analysing the new system, and then designing, testing and implementing improvements.

Thus the whole process repeats.

 

 

Documentation

Documentation

 

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

• User documentation
• Technical documentation

 

User Documentation

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

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
• Screenshots showing the system in typical use
• Example inputs and outputs
• Explanations of any error messages that might be shown
• A troubleshooting guide

 

Technical Documentation

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

 

 

Implementation



Testing and development

Testing and Development

 

 

 

 

 

 

 

 

Once the system has been created, it needs to be thoroughly tested.

A test plan is usually written whilst the system is being developed. The test plan will contain details of every single thing that needs to be tested.

For example:

• Does the system open and close properly?
• Can data be entered?
• Can data be saved?
• Can reports be printed?
• When you do something wrong, does an error message appear?
• Is invalid data rejected? E.g. if you are not allowed to enter an amount above £1,000 on the system then a value of 1,001 should not be accepted (i.e. does the validation work?)

Test plans are very detailed, and contain many tests. Each test is specified very precisely.

A typical test would contain:

• Details of what is being tested
• The test data to use
• What is expected to happen when the test is performed

 

Selecting Test Data

When choosing what data to use to test a system, you need to think about why we are testing the system: to see if it works, and to check it doesn't break.

To do this, we use three types of test data...

 

Normal Data Values

This is data that would normally be entered into the system.

The system should accept it, process it, and we can then check the results that are output to make sure they are correct.

Extreme Data Values

Extreme value are still normal data.

However, the values are chosen to be at the absolute limits of the normal range.

Extreme values are used in testing to make sure that all normal values will be accepted and processed correctly.

 Abnormal Data Values

This is data that should not normally be accepted by the system - the values are invalid.

The system should reject any abnormal values.

Abnormal values are used in testing to make sure that invalid data does not break the system.

When is the System Tested?

Testing is normally done in two stages:)

The first phase of testing is done by the designers and engineers who created the system, usually before the system is delivered to the customer.

The test data that is used in this first phase is similar to data that would be used by the actual customer.

The second phase of testing is done after the system has been delivered and installed with the customer.

The data used in the second phase is usually 'live' data - data that is actually part of the customer's business / organisation.

 

What Happens if the System Fails Some Tests?

The whole point of testing is to try and find areas that don't work as they should, or areas that can be improved.

If any failures are found, the systems analyst goes back and does some further research, analysis and design to fix these areas.

Teen magazine

 TEEN MAGAZINE

     The name of our team work magazine is “Teen Magazine “, actually, choosing the name and the colors are based on:

1-  Teenagers stuff is consumed mostly from the society.

2-  More fun and enthusiastic, mainly for those people who feel bored or lazy.

3-  Trying to solve some corrupted things in the teenagers’ lives.

4- Mixing of knowledge and being modern as well as coinciding the techno-century.

5- Neglect the sadness and awful news, nutshell, spreading the optimism.

6- Design and art touches the ideas, and captivate your thought.

Subtly, we have appeal the teenage to take care of them and the surrounding environment, by choosing the right food as well as recounting them about keeping the Earth clean without any imposes, as a result green colour is chosen.

Orange colour was the seminal color for fashion, since it is summer, cheering up the teenagers needed some power, leaving the phlegmatic feeling away.

Blue colour is the tranquility colour, as well as the social network color. Undoubtedly, we chose the social network page, as it is the thing that no teenager can abandon it.

We come to the cover page, which is yellow colour. Actually we face some confusion in choosing it or the red colour. But after encountering some funky teenagers, we found that they see it such an exciting colour, even if you are exhausted, be sure it will be erased.

Finally, we cringed when the magazine is finished, meditating about the reactions of the public about it. Fortunately, I can proclaim that we have succeeded in it.