Please enable JavaScript.
Coggle requires JavaScript to display documents.
Software development - Coggle Diagram
Software development
RAD
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.
Several kinds of prototypes that the RAD approach can make use of:
- Pilot prototype - determines 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 prototype has been used for discussion/evaluation, code is discarded. No carry-over to other 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.
-
Spiral
Iterative process. Step-by-step process of getting to the final product. Emphasis on the risks and uncertainties involved at each stage.
Methodology that follow the RAD model.
- Quadrant is drawn. Consists of 'Plan', 'Analyse Risk', 'Engineering'' and 'Evaluation'. Starts with a first draft of the requirements, 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. Considers whether new, untried technology is going to be used and what impact and risks might arise as a result. 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': coding happens. Code is tested to prove it works as expected.
- Moves onto evaluation. Customer evaluates project. Customer will assess whether software
- meets 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 adjustments required to complete the project.
- Process is repeated as many times as required to deliver the completed project.
-
Agile
Adaptive approach to development. Considers that no two projects are alike.
Agile - 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 intends 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 software is considered superior to writing lots of documentation.
- Customer collaboration - Client can't define requirements at the start 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.
-
XP
Form of agile programming - XP method.
Extreme programming is a 'code-first' idea. 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 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. They swap roles. Programmers swap pairs during the project to code different parts of software, each programmer has 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.
- 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 features needed from the user's POV. 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.
Final delivery date is not known ahead of time. Waterfall method has a timescale and a set of milestones to meet.
-
Waterfall
Split into stages, each stage has a specific purpose. End of each stage = milestone.
Method is sequential, 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 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 model you wouldn't 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.
Stages:
- Define Requirements: Describe 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 software will be tested, carry out tests to confirm that 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.
-
Selecting
Waterfall method:
- Good for managing large projects in terms of project time and manpower.
- Suited to companies that have enough staff to do 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 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 Spiral Method (example of RAD):
- 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 affected by the companies' future priorities, Early code will have functionality should the project be curtailed.
The Agile Method (e.g. extreme programming):
- 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.
White box 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.
TELOS
Method of analysis. Considers: technical, economic, legal and operational aspects of the project, as well as scheduling.
Software development methods offer:
- Capturing what the system needs to do
- Breaking system into manageable chunks
- Ways of keeping track of changes
- Ways of allocating staff
- Ways of finding & correcting errors-debugging
- Ways of planning and carrying out tests