Software development - Coggle Diagram
Rapid Application Development - iterative approach to software development.
Iteration - when part of the project is available, the customer is allowed to evaluate and confirm that it is meeting their requirements. The project moves forward to develop more features and the cycle is repeated.
Developing prototypes rather than extensive 'requirements documentation' up-front.
Prototype - model that represents some features of the overall project.There are several kinds of prototypes that the RAD approach can make use of:
- Pilot prototype - used to determine how feasible a design approach is; to test a new technology or a software tool. Is not intended to be developed further. Guides the planning decisions of how the project is to be carried out.
- Modeling prototype - created to test whether it fits the requirements of the customer. Prototype model is demonstrated and discussed with the customer, both parties agree with what is required. The modeling prototype can be of two types.
- Throwaway - once the prototype has been used for discussion or evaluation, the code is discarded. There is no carry-over to further prototypes.
- Evolutionary - prototype code is retained and used to develop a more detailed or refined prototype for the next iteration. The prototype is the actual release code as the project develops.
Iterative process but uses a step-by-step process of getting to the final product. Makes a heavy emphasis on the risks and uncertainties involved at each stage.
Methodologies that follow the Rapid Application Development model: 'spiral methodology'.
- A quadrant is drawn which consists of 'Plan', 'Analyse Risk', 'Engineering'' and 'Evaluation'. The order of progress is clockwise from 'Plan'. The project starts with a first draft of the requirements, which includes an outline plan of the project. Once the first draft of the requirements has been completed, the project moves onto the next stage, risk analysis.
- Risk analysis tries to minimise the chance of the project failing. Might be considered whether any new, untried technology is going to be used and what impact and risks might arise as a result. The risk analysis will consider alternative solutions. Outcome of the risk analysis stage is an initial prototype - not code, but a functional view of the what the software needs to be.
- Next phase is 'Engineering': where the coding happens. Code is tested to prove it works as expected.
- Process moves onto evaluation. Customer evaluates the project. Customer will assess whether the software
- meets their initial requirements
- is within budget
- is meeting their expectations in terms of delivery time
- Requirements (drawn up during the first planning phase) are updated to include any adjustments required to complete the project.
- Process is repeated as many times as required to deliver the completed project.
Adaptive approach to development as it considers that no two projects are alike.
Agile - group of methods that take the same viewpoint. Include: 'Rational Unified Process', 'Extreme Programming', 'Adaptive Software Development' and others.
Combines a sequential and iterative approach.
First iteration of development is intended to deliver a smaller set of features of the project. Short time compared to the overall project.
Reviewed with the client, adjustments made, and next iteration begins. Iterations follow until the project is complete.The 'Agile Manifesto' declares the following:
- Individuals and interactions - Self-organisation and discipline are vital. Working together as a pair is encouraged.
- Working software - Demonstration to the client of a simplified version of the software is considered superior to writing lots of documentation.
- Customer collaboration - Client cannot define their requirements at the start of a project and continuous interaction with the customer is encouraged to develop robust requirements as the project matures.
- Responding to change - Focused on reacting to change and on continuous development.
Form of agile programming - XP method.
Extreme programming is a 'code-first' idea. There is almost constant iteration whilst the code is developed.First Iteration
Take a small part of the overall project and outline a plan for how to implement that feature. Plan includes details on how the feature will be tested and the requirements for it to pass that test.
Code for that feature is written, it is done as a pair - one programmer, who will write the code, explains to the other what their code will do and how it works. Second programmer critiques the approach and spots any issues. After a while, they swap roles. Intensive and stressful process. Programmers swap pairs during the project to code different parts of the software, each programmer tends to have a good idea of how the code works.
Pre-written 'unit test' confirms that the code works as intended. Code moves to a customer acceptance test, where the customer agrees that this feature now works.Further iterations
Customer and project team go back and update the plan for the project in a meeting called the 'planning game'. In the planning game meeting the plan is updated in two stages.
Final delivery date is not known ahead of time. Waterfall method has a timescale and a set of milestones to meet.
- Stage 1: Release Planning - confirms which features of the project are working as intended. Customer determines the next set of requirement the software needs to include in the form of a 'user story' - describes the features needed from the user's point of view. Team commit themselves to some of the requirements for the next iteration.
- Stage 2: Iteration planning - customer is not involved with this part. Team determines how the requirement will be split into specific tasks and who will code those tasks along with a commitment to the time scale for completion.
Project is split into stages, each stage having a specific purpose. End of each stage = milestone.
Method is sequential so it looks like a cascade or waterfall.
'Pure' waterfall method - no iteration - once a stage is passed it is not re-visited.
Most projects involve a variation of the pure waterfall method as they do go back to an earlier stage if something changes - the 'modified waterfall method'.
A late change to a project can have a massive impact on delivery date and costs.For example, if the project had progressed to the 'install' stage and a change was requested, according to the pure waterfall model you would not be able to go back through the stages to make that change. You would have to go to the beginning and start over at 'Define Requirements' stage.
- Define Requirements: Describe the overall purpose of the project and define what each stakeholder wants out of it.
- Analysis: Assess the costs, time, manpower and resources needed for the project.
- Design: How the software is structured and created. Different modules required are identified
- Implement: Carry out the coding.
- Test: Plan how the software will be tested, then carry out tests to confirm that the software works as intended.
- Install: Roll out the software to the users.
- Maintain: Fix any bugs that were not picked up during testing and keep the software up to date.
The Spiral Method (example of RAD):
- Good for managing large projects in terms of project time and manpower.
- Suited to companies that have enough staff to do all the things required. Business analysts - requirements documentation, software teams - coding, quality assurance people - test planning.
- Good for well-understood projects that are relatively low risk in terms of delivery.
- Good when customer requirements are stable and well defined from the beginning.
- Good for projects that are funded and audited by the funding body in terms of progress and effectiveness because of the high level of documentation.
- Good for managing projects of international scope with multiple teams across the world responsible for different parts of the project.
The Agile Method (e.g. extreme programming):
- Good for large projects in terms of project time and manpower.
- Good for when customer requirements are not stable or even well defined at the beginning.
- Includes significant risk analysis effort, which is an important factor for medium to high risk projects in terms of delivery.
- Good when the company has a commitment from the customer to be involved all through the project.
- Good for creating a new company product from scratch.
- Good for handling complex requirements that are difficult to 'uncouple' from one another.
- Good for long term projects that are to be affected by the companies' future priorities, Early code will have functionality should the project be curtailed.
- Good for small to medium sized projects that are handled by one tight-knit team.
- The emphasis is on delivering working code rather than extensive documentation.
- Good for projects that are high risk in terms of delivery because customer requirements are not stable or even well defined at the beginning.
- Good when the company has a commitment from the customer for their staff to be involved all through the project.
- Good for companies whose coders are used to high levels of collaboration with their colleagues because of the paired programming technique.
- A good method to increase staff skills at the same time as delivering a project due to the collaboration levels needed.
- Good when staff work in the same place (co-located) i.e. not being dispersed or working from home.
Software development methods offer:
- A way of capturing what the system needs to do
- Ways of breaking the system into manageable chunks
- Ways of keeping track of changes
- Ways of allocating staff
- Ways of finding and correcting errors (debugging)
- Ways of planning and carrying out tests