3.1 System Analysis

• Application • System

• Analysis • Design • Implementation • Evaluation • Maintenance

• Analysis • Design • Implementation • Evaluation • Maintenance

• Gathers information about what the current system does if there is one, and what the new system needs to do • Analysts may interview people who will use the software, use questionnaires to get information from large groups of people, observe how the current system works, look at existing documentation

• System spec, user requirements • Can define what the system will do, but not how it will do it • Is used to create the design and to evaluate the finished product

• A description of the data • Database design • Input screens • Output screens and reports • How the data will be porcess • How the software will be tested

• Coding and testing the software • Writing user and technical documentation • Installing the software for the user

• Carried out independently of the code used in the program. • It looks at the program specification and create a set of test data that covers all the inputs, outputs and program functions

Depends on the code logic and devised which test each path through code at least once

• Carried out by the software developer’s in-house team and by the user • It can reveal errors or omissions in the definition of the system requirements • The user may discover that the system does not do exactly what they wanted

• This is used when a a commercial software is being developed • Software is given to a number of potential users, who agree to use the software and report any faults

Acceptance testing evaluates the product against the specification document

• Corrective • Adaptive • Perfective

Bugs will usually be found when the software is put into action, no matter how thoroughly it was tested

Over time, user requirements will change and the software will have to be adapted to meet new needs

Even if the software works well, there may be ways of making it even better - faster, easier to use, more functionality

• Each stage is completed and documented before the next is begun • The customer doe snot see the end product until it is completed • Any changes the project has to be started again

• Simple to understand and use • Each stage is separate and self-contained with well defined outcomes and written documentation • This makes the project relatively straightforward to manage • The model works well for smaller projects where requirements are very well understood

• There is not much user involvement after the analysis stage, when the specification document is agreed • No working software is produced until late in the cycle • The user is presented with the finished product if it is not quite what was required, it is generally too late to make changes

• The requirements are very clear and fixed • There are no ambiguous requirements • The technology is well understood • The project is short

• Analysis • Design • Implement • Evaluate

Generates a more refined prototype until the software meets all the requirements

• Well-defined steps make the project easy to manage • Software is produced at an early stage so problems and issues can be identified early • The user gives feedback on each prototype and any required cjamges can be amde early in the process • ADded functionality can be made early in the process • The end result is more likely to be what the user wants

• Process of developing prototype, getting feedback and refining the prototypes is time-consuming so the finished product takes longer to develop • A system is more costly to develop because of the time involved • Not suitable for smaller projects