SLR 6

Analysis, Design, Development, Testing, Implementation, Evaluation, Maintenance

Stakeholders​ state what their requirements which are used to​ define the problem​ and the​ system requirements. Requirements may be decided by: -Analysing strengths and weaknesses of current solution – Considering inputs, outputs, stored data and amount of data involved

The different aspects of the new system are designed, such as: - Inputs: ​ volume, methods, frequency —- Outputs: ​ volume, methods, frequency Security features: ​ level required, access levels Hardware set-up: ​ compatibility User interface: ​ menus, accessibility, navigation. A​ test plan ​ may also be designed at this stage.

The design from the previous stage is used to split the project into ​ individual, self-contained modules​, which are allocated to teams for programming.

Alpha testing is ​ carried out​ ​ in-house​ by the software development teams within the company. Bugs are pinpointed and fixed.

Beta testing is ​ carried out by end-users​ after alpha testing has been completed. ​ Feedback from users ​ is used to inform the next stage of development.

This is ​ carried out by software development teams​ in which the internal structure of the program​ is known. All of the ​ possible routes through the program​ are tested.

Software is tested​ without testers being aware of the internal structure​ of the software. The test plan traces through​ inputs and outputs ​ within the software.

Once the software has been tested and reviewed, it is​ installed onto the users’ systems​.

The ​ effectiveness of the software​ is evaluated against the system requirements​. Different criteria are considered, including ​ robustness, reliability, portability and maintainability​.

Any errors or improvements that could be made to the software are ​flagged up by the end-users​. Programmers will regularly send out​ software updates to​ fix any bugs, security issues​ or make any necessary improvements.

A method of analysis used by designers to evaluate the feasibility of a project. It considers technical, economic, legal and operational aspects of the project, as well as scheduling.

A collection of methodologies which aim to improve the flexibility of software development. They respond quickly to changes in user requirements. The problem is broken down into ​ sections which are developed in parallel.​ Different sections of software can be at ​ different stages of development​. A ​ working prototype​ is ​ delivered early on​ and prototypes are built upon and improved in an ​ iterative manner​ so that n​ew prototypes are delivered regularly​ throughout the course of the development cycle.

-Straightforward to manage. -Clear structure. -Clearly documented

-High cost due to two people working on one project. - Teamwork and good communication is essential. - End-user must be present throughout the duration of the project.

Large, risk-intensive projects with a high budget.

Projects where high usability is required and user requirements may not be clear from the outset or are continually changing. Suited to projects of a small to medium size with a relatively low budget and short time-frame.

A set of instructions used to solve a problem.

● Inputs must be clearly defined - what is valid and what is invalid? ● Must always produce a valid output for any defined input. ● Must be able to deal with invalid inputs. ● Must always reach a stopping condition. ● Must be well-documented for reference. ● Must be well-commented so modifications can easily be made.

• completed in sequence from start to finish • analysis stage includes feasibility study using TELOS • If a change needs to be made within a project being developed using the waterfall model, programmers must revisit all levels​ between the current stage and the stage at which a change needs to be made. • Users have little input​ as they are only involved at the very beginning and end of the waterfall lifecycle

• agile model • pair of programmers alongside a representative end-user • produces high quality code • hard to produce high quality documentation

• built on 4 key stages • focus of effectively managing risk-heavy projects • analysing system requirements • pinpointing and mitigating risks • development, testing and implementation • evaluating to inform the next iteration • the projects is terminated if found to be too risky • risk assessors are expensive • suited to very large-scale projects

• iterative methodology • partially functioning prototypes which are continually built-upon • user requirements are initially gathered using focus groups and used to develop and ‘incomplete’ version of the solution which is given to the user to trial • user feedback is used to generate the next, improved prototype • commonly used where user requirements are unclear at the start • additions to code may be inefficient

• Lack of flexibility • No risk analysis • Limited user involvement