System Analysis & Design

System Analysis & Design IGCSE ICT Mrs. Ghazaal

Analyse how systems work and how to improve them • May involve changing systems from manual or paper based systems to automated computer-controlled systems. • May involve suggesting ways to improve existing computer based systems

Systems Life Cycle

Analysis • Takes place when the current system is looked at in detail and the problems with it are identified. • The important aspect of this stage is collecting the information that allows the analysis to take place. • Interview • Observation • Questionnaires • Using existing documentation

Observation • Observation will enable the system analyst to see the process as a whole, first-hand unbiased information • This involves the systems analyst walking around the organisation or business, watching how things work with his/her own eyes. • From this, a data flow diagram can be produced that will enable the analyst to determine the inputs, outputs and processing which exist in the current system • Easier to see data flow and get a more accurate overview of whole system • The downside to observation is that often people won't work the way they normally do if they know they are being watched. They may start to work more efficiently than normal, which could lead to misleading statistics being collected by the analyst.

Questionnaires • Although it takes a lot of time to produce an effective one, once it is produced as many copies as you want can be given out, to a large number of people • Quicker to get every worker’s response and easier to collate (put together) responses • Disadvantages are: • That because they are impersonal and can be anonymous, workers might exaggerate their answers • the questions cannot be changed halfway through in response to a persons answers • sometimes the people filling in them in might not take them seriously

Interviews Method is used often, but because it takes time to complete an interview it is not possible to interview every worker, instead key personnel and representatives of the other workers are usually interviewed. • Advantages: • Flexible, further questions can be asked based on responses • Can detect body language • Disadvantages: • Time consuming, systems analyst must be flexible and work around busy schedules of workers • People can be dishonest and give answer they think are ‘correct’ whereas an anonymous questionnaire tends to be more accurate

Examination of Documents • The systems analyst needs to collect examples of the documents used to get an understanding of the type and quantity of data that flows through the business or organisation • Can see exact details of inputs and outputs • Analyst will be looking for answers to questions such as: How is the data collected? What data is collected? What happens to the data afterwards? • Disadvantages: • Documentation might be difficult to understand for someone outside the organisation • Documents might give the wrong impression (sometimes documents may say one thing but everyone does something else.)

Analysis • Having collected as much information about the present system as possible, the systems analyst now looks though it all to understand how the system works, and to try and identify problems that need to be fixed. If these problems can be fixed, the system will work more smoothly, be more efficient and, in the case of a business, be more profitable • As the analyst collects data and the problems, a list will be forming of things that will be necessary in the solution. This list is the requirements specification (also called terms of reference) and will include what the organisation wants the system to do, details about the storage requirements, and information about the desired hardware and software.

Review • You should be able to name the main stages of the systems life cycle • Describe the purpose and outcome of the analysis stage • Describe the four data collection methods and state advantages and disadvantages of each method

Design • Inputs to the system • Outputs from the system • Files and databases needed to store the data • Processing required to produce the outputs • Validation checks • Testing (creating, testing, improving)

POP QUIZ (15 min only) • Bilal owns a small company. He wishes to replace the existing computerised system with a new one. He has already made backups of the existing system. He has employed Adil, a systems analyst. Give 4 methods he could use and for each give a reason why it would be used. • Explain the difference between ‘backing storage’ and ‘creating backups’?

Designing System Inputs • 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 • Data capture is a phrase to describe the way in which data is collected, for example, on a questionnaire, by a touch screen or a voice recognition system. • The systems analyst will select a data capture method and data input method that best suits the requirements of the new system

Designing System Inputs • Will automatic data collection be used? • Example: sensor tells the system when someone enters a building, what the temperature of a process it, a barcode reader captures the data (the numeric code on the barcode) and inputs it to a computer in one go. • Are questionnaires going to be used for data capture? • Should they be designed so that the answer sheets can be read by a special OMR or OCR machine? • Is the data going to be input by someone using a keyboard and screen?

Designing On-Screen Forms for Data Input • A well-designed on-screen form can make this task easier and quicker • http://www.igcseict.info/theory/8/design/index.html • Detailed info on creating effective forms • Data fills the screen • Clearly defined input area for each field • Tick boxes/radio buttons to enter choices • Drop down menus to select data options • Appropriate spacing for each field • An easy to read font/font size • A sensible font colour/background colour • Easy to follow instructions for completing screen/help icon • No overlapping of items

Designing System Outputs • Analysts job is to produce a system that will do a particular thing, so the really important part is to decide what the organisation wants to happen in the end • If the client likes the output, they are likely to accept the whole situation • There are usually two types of output from a system that need to be designed: • On-screen reports (information displayed on the monitor) • Printed reports(hard-copy to be mailed, filed, etc.)

Designing System Processes • System flowcharts or pseudo code to describe the system are produced • The system analyst also needs to design the actual steps to be followed for processing the data (the algorithm), often utilizes a programmer to help with this phase • Algorithm- is a step-by-step procedure

Designing Data Storage • The analyst has to work out the content of the data tables that will be needed. This requires very careful consideration because the entire system depends on the database not only holding the necessary information but that it is held in the correct format • The designer also need to consider which backing storage device and media will be suitable to store the data: • How often will the data need to be accessed • How quickly the data needs to be accessed • How large will the data files be

Design Tasks System analyst will need to look in detail at many of the following tasks as part of the design stage – some of these you have already explored, some you will look into in later stages

Designing Data Storage • The systems analyst will decide on individual file structures and whether any programming is required. He will need to look at the following items of file structure: • Field names • Field types • Field lengths • Validation rules • Selection of key field

Validation Designers will have to be sure that they have designed appropriate validation routines that will test the data input to the system. There are 8 some commonly used validation checks, they will need to select the most appropriate data validation for the current system

Deciding Hardware & Software Requirements • Hardware • How many computers? • What type of network? • How many servers? • Any special input devices? (e.g. barcode readers) • Any special output devices? • Software • Is ready-made, off-the-shelf software available? • Is custom-written software required?

Reducing Errors when inputting data • Using direct data entry (bar code readers, OMR) reduces typing errors • Use of coding (NOT encoding which means encryption) • Use of M for male and Y for yes

Hardware Requirements • Final stage in design will be to choose specific hardware • A supplier will be chosen based on cost, reliability, and the after-sales support that can be offered • Volume of data will determine some of the choices

Software Requirements • Existing software might be sufficient, and only needs to be adapted to provide the solution to all the system requirements • Employ programmers to write software specific to their use

Development & Testing After designing the system, it must be • Created • Tested • Improved

Software Testing • Normal/Extreme/Abnormal • Live Data • data that is actually part of the customer's business / organisation; will be used because the outputs are already known • 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 (Iterative process)

Implementation Direct Changeover Parallel Running Phased Implementation Pilot Implementation

Direct Changeover • Direct changeover is stopping the old system and starting the new one immediately • Benefits of direct changeover are immediate • If new system fails there is no backup system • Least expensive method of implementation

Direct Changeover • The company literally switches off the old system and switches on the new one. This is probably the most straightforward method but is also probably the riskiest

Parallel Running • Parallel running is running the old and new system together • Parallel running is more expensive as two sets of workers have to be employed • Parallel running is slower to implement, but in case the new system fails, there is a backup system available • Training can be gradual

Parallel Running • Running the new system while the old system is still running for a set period of time; More popular method than the previous one. • Once the organisation is sure that the new system is working properly and that staff are ready to begin using it they will make the decision to completely change over. During a quiet period, perhaps during the night or on a weekend the data is fully transferred from the old system which is then shut down.

Phased Implementation • New system is implemented part by part • Still have most of system if things go wrong and there is no expense of running two systems together • No expense of paying two sets of workers • If latest phase fails only need to go back to that point (don’t need to undo everything) • Training can be gradual • You will lose some data if things go wrong • It is more expensive than direct changeover as each phase has to be evaluated before moving to next phase.

Phased Implementation • This is where the old system is still active but parts of the new system or modules are brought online • For example, perhaps just the data entry screens and the printing modules are made available but the ‘back end’ of the system remains the same. Once any problems are ironed out with the new modules then extra modules will be introduced. • Effectively the installation happens in small chunks.

Pilot Running • System is implemented in one department/branch/one office (at a time) • Still have most of system if things go wrong • No expense of running two systems together • Can train staff in one area only • Have to pay fewer workers than parallel implementation • More expensive than direct changeover as more workers are needed and it’s a slower method than direct changeover • Takes time to implement for whole company

Pilot Running • This is where the complete new system is installed and tested in a small number of departments or branches. They then use the system and report their feedback and any issues to the analyst. • Once the organisation is confident that the system is working as expected, it will be rolled out across the whole organisation. • This method is usually adopted by large organisations.

Testing Strategies (after Implementation) • Testing each module with normal/live data/user testing • To see how system behaves in an ordinary day to day situation • To make sure the system works as you would expect i.e. no error messages • To ensure that the system meets the needs of the user • Testing each module with abnormal and extreme data • To see how the system reacts in unusual circumstances • To make sure error messages appear when data is abnormal • Testing whole system • To ensure the whole system works when all modules are combined

Documentation • Technical Documentation – meant to help when the system needs further development or upgrading • So improvements can be made to system • To know how to repair system • To know how to maintain system • User Documentation – provided to help users operate the new system. Can take the form of a tutorial that helps users work their way through the system • Help users to learn/know how to use system • Help users to overcome problems

User Documentation • Helps the user actually use the system • If the documentation is effective the system analyst will not be contacted on a regular basis to show users how to do certain things

User Documentation components • How to load software/install/run software • How to save a file • How to search and sort • How to print • How to add/delete/edit records • Purpose of the system/program (only if not mentioned in technical documentation) • Input format or example (only if not mentioned in technical documentation) • Output format or example (only if not mentioned in technical documentation) • Hardware requirements (only if not mentioned in technical documentation) • Software requirements (only if not mentioned in technical documentation) • Sample runs (only if not mentioned in technical documentation) • Error messages; Error handling (systems must output error messages then user can look these up to find out what can be done about them) • Tutorials • Troubleshooting guide/Contact details/help line/FAQ

Technical Documentation components • Program listing • Programming language • Flowchart/algorithm • List of variables (things that can change) • File structure • Purpose of the system/program • Input format (example: if the input is price does it always need 2 decimal places) • Output format ( How should it be produced and what should it look like?) • Hardware requirements • Software requirements • Sample runs/test runs • Known bugs/possible errors • Validation rules

Evaluation Stages in the evaluation process: • Is the system reliable and robust? • Does the system do what it was intended to do? • Is the system easy to use? • Is the system efficient? At some point after the new information system has been operating as a normal business application it is time to review the project

Evaluation Activities • Comparison of the solution with the original requirements specification • Identification of any limitations to the system • Identification of any necessary improvements • Analysing/collecting users' responses to using the system • Comparison of test results of new system with old system results • Comparison of the performance of the new system with performance of the old.

Maintenance • This continual process of changes to the system is known as maintenance and will take place throughout the systems operational life cycle. There are 3 forms of maintenance: • 1) Error correction (corrective maintenance) – fixing software bugs • 2) Added functionality (adaptive maintenance) – adapting to changes in the organisation and it’s needs • 3) Performance improvement (perfective maintenance) – making the system faster or more efficient (can be software or hardware, etc.)

Complete Now on Paper: The system has been operating satisfactorily for three months since implementation. A user tries to do something differently that causes an error to be reported by the software. They submit a bug report to the system support staff who investigate the error and conclude that the user is trying to do something that the system wasn’t designed for. How will the support staff have reached this conclusion? What can they do about the error?

Answer: The support staff will have looked at the technical documentation (and possibly the original requirements specification) to check whether the system was designed to do the thing the user tried. The error can be answered in two ways depending on what the user was trying to do: IF it was not a useful thing then the bug will be closed. A log will be kept (a known error log) so that if any other users try the same thing, it is not re-investigated. IF it is a useful thing, then it will be added to the list of added functionality changes (enhancements) to be made to the system. The change will need to be developed and tested, and then implemented.

System Analysis & Design