A2 SSD — Methodologies
Waterfall
- Each phase is fully completed, with deliverables, before the next phase is started. It is possible to move back up phases if problems occur but the methodology moves in one direction mainly.
Waterfall Model
[Identify]->
[Analyse]->
[Design]->
[Implement]->
[Test]->
[Install]->
[Review]->
[Maintenance]Advantages
- Highly Structured which makes project management easier
- Easy to stay on schedule
- Easy to stay within budget
- Clear understanding of what happens at each stage
Usually smaller projects where requirements don’t change. Good for when the requirements are known.
Disadvantages
- Highly structured which makes it hard to change half way through
- Changes in requirements could mean the project needs started again
- Mistakes early on can be carried on through to the end
- Little user involvement
- Might not realise requirements where misunderstood until late on
Prototyping
Make a mock-up (non-functional model) of the new system. It will have the user interface but not the actual programming functionality in the background.
Users give feedback on the prototype until they are happy with it.
Throw-Away Prototype — Used to gauge user requirements and when complete is thrown away and the system is developed with a different methodology. Used i the analysis stage of the waterfall model.
Evolutionary Prototyping — The functionality is added to the finished prototype so that it evolves into the final product.
Advantages
- User can see what the system will look like early on
- Analyst gets better understanding of user requirements
- Less structure than waterfall, deals with changes in requirements and design easier
Disadvantages
- Project management is more difficult due to less structure
- Lack of distinct features makes it more difficult to plan activities
- Easy to go over time and budget
RAD
Software products are created at increased speed. Usually 6 months or less. Since RAD is an agile methodology it is an iterative process. It cycles through iterations of design and develop until the project is complete or resources run out.
RAD is less concerned with requirements and focuses on development based around the prototype.
Suitable for form-driven applications.
Only suitable for small-medium projects.
Advantages
- Reduced development time — Due to reusable components
- Better quality software — Due to high user involvement and early detection of errors
- Lower development costs — Due to reusable components
Disadvantages
- Unwillingness of client to release staff — The client may want their employees for their own business and won’t give them for development
- Less control — More flexible which means less control of the project
DSDM (Dynamic Systems Development Methodology)
Another agile methodology which tries to fix the problems with RAD caused by lack of structure by adding distinct stages into the methodology while retaining the iterative approach.
DSDM phases
Feasibility study -> Technical, Economic
↓
Business Study -> Meet what business needs, who will use it
↓
Functional Model -> Prototype designed, functionality planned, MoSCoW
↓
Design and Build -> Design, code, debug and review in order set out in MoSCoW
↓
Implementation -> Install, train users, acceptance testingMoSCoW Prioritisation
Not enough time to do everything so those that are essential are put before things that aren’t essential.
Prototyping
Prototypes are used heavily in DSDM and they ensure that all interested parties have a clear picture of the various aspects of the system.
Facilitated Workshops
Users and development team get together to review progress and plan future development. Users decide if user requirements are fully met or if modification of requirement definition is needed.
TimeBoxing
A TimeBox is a set amount of time for development. The development must stop at the end of the set time whether the code is completed or not.
- DSDM has lots of user involvement in every phase
- Fast delivery of software
- Low cost methodology
XP — Extreme Programming
Very focused on creating useable code, with all development starting with the “user story” and identification of key functionality which is prioritised.
Prioritisation is taken to the extreme because development time is not spent implementing functionality until it is actually needed.
XP tries to reduce paperwork, meeting and external testing.
XP places importance on doing actual programming tasks and doing them well.
Pair programming
Programmers work in teams, one types code into the computer the other oversees the code to help notice mistakes and thinks ahead to the next stage in coding.
Programmers swap roles regularly.
- Frequent small releases
- Simple requirements/code
- Pair programming
- User focus
- More time spent coding
Advantages
- Less errors in code
- Faster delivery time due to focus on coding
- User satisfaction due to focus on ‘user story’
- Can cope well with new/changing requirements
- Cost savings as unnecessary tasks are avoided
Disadvantages
- Need for constant user involvement which isn’t always possible
- Focus on code leads to lack of documentation which is bad for large systems maintained by multiple people
SCRUM
SCRUM is another agile methodology with a focus on the ‘user story’ and short iterations.
Product Backlog (Requirements list)
↓
Sprint Backlog (What's to be completed in this sprint)
↓
Sprint (Development iteration, actually implementing)
↓
Review (Uncover requirement changes/discuss future iterations)Roles
Project Owner — The person paying for the software, who decides the direction of the project i.e. which requirements are most important and what should be done next.
Scrum Master — A member of the development team, and the spokesperson for the team during large scrum meetings. They check and ensure progress of development, remove impediments and distracting influences for other members of the team and chair the daily scrum meetings.
Team Members — A member of one development team. Scrum teams are multi-disciplined, i.e. specialists in different areas, coding, SQL etc … Scrum teams work together to create complete working piece of software.
Terminology
Sprint Planning — At the beginning of each sprint the Product owner and team holder a meeting to figure out which items from the Product Backlog they will convert to working product during the sprint.
Daily Scrum — Everyday at the same time and place the Scrum Development team members report to each other and each team member summarizes what they did the previous day and what they will do today.
Sprint Review — A meeting where the Project Owner gets a working demonstration of the product increment to review. Any items the Project Owner says aren’t done are put back on the Product Backlog.
Backlog Refinement — Product Backlog Items (PBIs) need refinement because they are too large and poorly understood.
Product Backlog — Full list of all requirements not yet met.
Product Backlog Item (PBI) — Single user requirement, specifies the what more than the how- Customer centric feature.
Sprint Backlog — Consists of committed PBIs negotiated between the team and the Product Owner during the Sprint Planning Meeting, Referenced during the Daily Scrum Meeting.
Sprint — This is one full development iteration including planning and reviews. All of the Sprint Backlog agreed at the Sprint planning Meeting should be met. Each complete sprint should result in a possibly shippable application.
Sprint Task — Specifies how to achieve the PBI’s what. Requires one day or less of work. Remaining effort is re-estimated daily, typically in hours.
Sprint Burndown Chart — A publicly displayed chart, shows remaining work in the Sprint Backlog (in days), updated every day, gives a simple view of the sprint progress.
Story — A particular business need assigned to the software development team. Storied must be broken down into small enough components that they may be delivered in a single development iteration.
Story Point — A metric used in agile project management and development to determine the difficulty of implementing a given story.
