2.2.2 Software Development

A process or series of processes used in software development.

• Series of stages - Followed in order - Can go back up the order - Then needs to follow back down in order. • Progress to the next step is not made until the previous step is completed. • Uses formal documented stages • Focuses on the end user at the start • Each stage in the life cycle feeds information to the next stage

• When the requirements are clear and unlikely to change • Very reliant on getting the definition of requirements correct at the start; changes are harder to add in at a later stage. However, this forces the definition to be well-understood.

• An iterative process designed to allow development to respond to changing user requirements. • Involves paired programming • The end user integral throughout XP • The focus is on good-quality code

• Use of prototypes • No formal analysis, or design stages so requirements do not need to be stated at the start (more flexible) • Feedback used to influence future stages • Reduced development time due to each subtask being given strict time limits. • The prototype is tested and feedback is obtained from users • The results of feedback and testing are used to inform the next prototype.

• Mostly used for large-scale projects, where risk is a factor. • Has more focus on risk management; projects may be modified or even dropped if the risk is too great. Prioritises riskiest elements first • Has four quadrants (determine objectives, identify and manage risk, develop and test, and plan the next iteration). • Relies on frequent client feedback to inform future development of prototypes. • Produces functional prototypes.

• Waterfall needs fixed requirements as it is hard to change - Agile can respond to changing requirements. • Waterfall used formal stages that are followed in order - Agile does not follow formal stages and will produce smaller incremental prototypes • Waterfall does not involve the user in the development stages - Agile relies heavily on user feedback and will get feedback on protypes throughout

• The internal structure/ design is known (to the tester) • Requires programming knowledge • Tests the algorithms to ensure they do what they were designed to. Does not test functionality

• The internal structure/ design is not known to the tester • Requires limited/no programming knowledge • Testing to make sure the program produces the expected outputs based on an input. • Does not look at the code, looks only at program specification

Internal testing by the programmers before showing to end user

Testing by third party/end users to ensure it meets requirements and is functional. Helps test usability.

Normal - Data that is correct, so should be accepted Extreme - The minimum/maximum values of the data that could be entered for example for teenagers 13 and 19. Invalid / Erroneous - Invalid– Correct data type, but values higher or lower than the expected range, for teenagers greater than 19. Erroneous – Incorrect data type that the program should not accept such as entering ‘Dave’ in an age field.