1.2.3

Stages of a project were carried out sequentially. This meant that the entirety of each stage had to be completed, formally documented, discussed, agreed, and signed off before the next stage could begin- WC. Requires a lot of investment in the early stages, when developers must carry out analysis and write detailed descriptions of the requirements. Once the requirements are agreed, they are ‘fixed’. In the waterfall approach to systems development, each of the stages leads to the next. In order, the stages are as follows: analysis, design, development, testing, implementation, and maintenance. Benefits If the user requirements are clearly understood and well specified, the waterfall lifecycle methodology can be suitable. However, for innovative and complicated projects where not much is known at the beginning, this approach is unlikely to be successful. Despite its disadvantages, the approach is well structured and well understood. Having clearly defined stages makes the project easier to plan, and there are clear lines of responsibility. Large projects can be split into a set of smaller subprojects and each can be approached using its own ‘waterfall’. Criticism Criticised for its rigidity, the large volumes of documentation that it requires, and the lack of user involvement. The client is involved in signing off on the analysis and evaluation, but has little input during the design and build stages of the project. Heavily dependent on an accurate specification of the requirements. Often the client is not able to fully articulate what is wrong with the system that they are using, or what they really want. They may not really understand the capabilities of technology, or the risks of being ‘early adopters’. Also, sometimes the development process takes so long that the original requirements no longer reflect what is needed. The testing phase is scheduled towards the end of the development cycle, which means that if defects are found, there may not be sufficient time to address them. Finally, the stakeholders do not have a chance to review the end product until after the release.

Advocates building prototypes, testing, and incorporating feedback as soon as possible. Once a prototype is built, it is reviewed to see what is good or bad about it. At the next stage, the prototype can be modified and new features can be added if required. focus on idea requirements will shift and change during development, dealt with by producing software in an iterative way. built in series of sprints (iterations), short time-boxed periods where team has focused goals to complete a set amount of work. Benefits empathises programming, so quality of end code is likely to be high. principals promote collaboration leading to a productive development team. Criticism The use of prototypes is often criticised for giving rise to scope creep. This is where the client continually adds to the requirements when each prototype is evaluated (as they think of new features or functionality). require team with close collaboration, not suitable if they’re geographically separated. can be costly (paired programming).

aims to produce very high-quality code and promote developers quality of life by encouraging them to adopt set common practices: simplicity, communication, feedback, courage, and respect. considered an agile framework that encourages small, iterative software releases. collective ownership, code standards, refactoring, paired programming. Benefits empathises programming, so quality of end code is likely to be high. principals promote collaboration leading to a productive development team. Criticism The use of prototypes is often criticised for giving rise to scope creep. This is where the client continually adds to the requirements when each prototype is evaluated (as they think of new features or functionality). require team with close collaboration, not suitable if they’re geographically separated. can be costly (paired programming).

Risk driven. More of a guide to development team and has a specific focus on identifying and managing risks. Uses the same steps as the waterfall method, but also uses project cycles, each culminating in a version of the software (a prototype) that is formally reviewed to inform the next cycle. This pattern is repeated until the final product is created. Each cycle is split into four stages: Determine objectives Identify and resolve risks Develop and test Plan (the next iteration) Benefits Emphasis on risk management makes it suitable for large-scale, high-risk projects. These might be projects where technologies are unproven or multiple organisations are involved. Criticism Project teams will need to include a risk management expert- add to the cost of the project. If risk analysis done badly- fail

Agile approach to software development based around prototyping. Involves producing successive prototypes of the software until the final version is produced and approved. Puts less emphasis on rigid planning and more emphasis on an adaptive process. A prototype is a version of the system, or part of the system, that lacks full functionality. (e.g. a prototype GUI may provide a mock-up of the screen layouts, but the buttons may not do anything. A prototype can be shown to the user, who can give feedback, and this can inform the development process. Users often find it much easier to provide constructive feedback on something that looks like the real thing, rather than on paper sketches or drawings. Prototypes are often used in addition to, or sometimes even in place of, formal design specifications. Benefits Well suited for developing software where the requirements are unclear,the requirements are not needed to be stated at the start so therefore its more flexible. It is good for smaller projects where there are smaller development teams that include users or their representatives. the requirements are not needed to be stated at the start so therefore its more flexible Criticism Encourages sloppiness — a ‘try-it-and-see’ approach — and ignores the importance of making sure that the overall system architecture is right. Also, projects can sometimes take far longer than anticipated where users make continuous requests for minor changes.

• Analysis Stakeholders​ state what they require from the finished product. This information is used to​ clearly define the problem​ and the ​system requirements​. Requirements may be defined by: • Analysing strengths and weaknesses with current way this problem is being solved • Considering types of data involved including inputs, outputs, stored data and amount of data • Design 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. - Development The design from the previous stage is used to split the project into ​individual, self-contained modules​, which are allocated to teams for programming. - Testing The program is tested against the test plan formed in the Design stage. There are various types of testing that can be carried out: • Alpha testing Alpha testing is ​carried out​ ​in-house​ by the software development teams within the company. Bugs are pinpointed and fixed. • Beta testing 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. • White box testing This is a form of testing ​carried out by software development teams​ in which the test plan is based on the ​internal structure of the program​. All of the ​possible routes through the program are tested. • Black box testing This is a form of testing where the software is tested​ without the testers being aware of the internal structure​ of the software and can be carried out both within the company and by end-users. The test plan traces through​ inputs and outputs within the software. • Implementation Once the testing stage has been used to make the appropriate changes to the software, it is ​installed onto the users’ systems​. • Evaluation After the implementation stage, the ​effectiveness of the software​ is evaluated against the system requirements​ defined at the analysis stage to evaluate its suitability in solving the problem. Different criteria are considered, including robustness, reliability, portability ​and ​maintainability​. • Maintenance 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 needed improvements.