1.2.3 Flashcards
Waterfall cycle
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.
Agile methodologies
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).
Extreme 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).
Spiral model
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
Rapid application development
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.
Testing
- 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.
- Black box testing
- 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.
