Please enable JavaScript.

Coggle requires JavaScript to display documents.

SLR6 - Coggle Diagram

- - - - The waterfall is a 'plan-first-then-do' approach. Spending time and effort at the requirements stage saves time and money overall. The waterfall method encourages this by producing comprehensive documentation for the requirements that are signed off by the customer.
      - It encourages the project to be managed in a well-structured manner. Having formal milestones encourages a disciplined approach.
      - Well-defined formal milestones in waterfall allows progress to be easily assessed both by the team and the customer
      - Encourages extensive documentation at every stage. After the project is complete, this documentation can be reviewed. Leaders of future projects can learn from previous projects - what worked and what didn't.
      - Easy for someone outside the project (for example an auditor) to understand how the project is managed and progressed.
      - Suited for projects that are well understood in terms of technology risk and have clear and stable requirements.
    - - The biggest issue is that the clients very often do not know exactly what they want at the beginning of a project.
      - Not so good for high-risk or challenging projects. It is difficult to plan ahead if the team is unfamiliar with the technology or techniques required.
      - Requiring extensive documentation and tight discipline can stifle the creativity and individuality of the programmers.
      - Not so suitable when the requirements are vague or constantly being changed
      - Not such a good fit for companies that prefer a more informal way of running projects.
  - - - The biggest issue is that the clients very often do not know exactly what they want at the beginning of a project.
      - Not so good for high-risk or challenging projects. It is difficult to plan ahead if the team is unfamiliar with the technology or techniques required.
      - Requiring extensive documentation and tight discipline can stifle the creativity and individuality of the programmers.
      - Not so suitable when the requirements are vague or constantly being changed
      - Not such a good fit for companies that prefer a more informal way of running projects.
    - - The biggest issue is that the clients very often do not know exactly what they want at the beginning of a project.
      - Not so good for high-risk or challenging projects. It is difficult to plan ahead if the team is unfamiliar with the technology or techniques required.
      - Requiring extensive documentation and tight discipline can stifle the creativity and individuality of the programmers.
      - Not so suitable when the requirements are vague or constantly being changed
      - Not such a good fit for companies that prefer a more informal way of running projects.
  - - - Good for a large project that is known to be risky, right from the outset.
      - Extensive risk analysis helps steer the project towards completion
      - Like the waterfall method, the spiral includes comprehensive formal documentation and strong management
      - Prototypes prove that early requirements are being met
      - Customer has a chance to evaluate the project earlier than with the waterfall method
      - Allows for more functionality to be added later in the project
    - - The success of the project depends heavily on handling and analysing the risks early on.
      - Can be cumbersome and overkill for small, short projects
      - Can be costly in terms of the man-hours needed within the project for handling risk analysis for example
      - Requires customers to be diligent in evaluating the project effectively in the early stages of the project
      - Not suitable for straight-forward, low risk projects that the company has experience in delivering successfully already.
  - - - Functionality can be developed quickly and demonstrated that it will work
      - This method gives flexibility to developers
      - There is no need to undertake detailed long term planning at the start of the project (unlike waterfall)
      - Minimal formality and documentation
      - It can handle changing requirements as well as fixed ones
      - It is a very realistic approach as it takes on board that clients often do not know what they want until they see something in front of them
      - Promotes teamwork and cross training
    - - Not good where modules and features depend on one another in complex ways as it is then difficult to partition the project into smaller parts
      - As there is less documentation, it can be harder to maintain and extend the software in the future once the original team has dispersed
      - Depends heavily on customer interaction, so it requires a significant committment from them throughout the project.
      - It depends very much on the self-discipline of the developers to meet deadlines as it is a 'management-light' approach compared to waterfall
      - Passing on lessons-learnt from one project to another can be more difficult as there is less documentation
  - - - Extreme programming is an agile methodology and so has the advantages of those stated earlier
      - The idea of programming in pairs is that 'two heads are better than one'. It is an excellent way to learn new techniques from a more experienced programmer, and for an experienced programmer to be exposed to fresh ways of coding.
      - The resulting code is of high quality as it has been tested thoroughly by unit tests.
      - Customers are a key part of the project in the form of customer acceptance tests and involvement in the planning game meeting
      - Very good method for handling a project whose requirements are not well defined at the beginning
      - Works well for small, tightly knit, software companies whose staff are well used to the level of collaboration needed.
      - Good method for short projects lasting a few months as the same people are more likely to be there to completion.
    - - Extreme programming is an agile methodology and so has the disadvantages of those stated earlier
      - Programming as a pair is an intensive, tiring way to work and so the XP method recommends that programmers do not work more than 40 hours a week so they are well rested.
      - The inherent lack of final deadline in the method is an issue for those projects that have an absolute deadline. For example, writing code for a satellite that has to launch on a specific date.
      - The close collaboration of programmers needs an excellent team working personality, but many programmers prefer to have a specification and then be left alone to code.
      - Does not work well for geographically distributed teams as the pair method needs them to be co-located.
      - It needs a large time and staffing committment from the customers. It also needs the customer to have a good technical understanding of what the code is doing. But quite often the customer wants a 'hands-off' approach - they simply want to set out their requirements without too much interaction until the project is near completion.
      - Not so good for large, international projects involving dozens or hundreds of programmers or for projects that will last for years.
      - The longer the project, the bigger the issue of staff turnover will be and the loss of knowledege of what how the earliest code works.