The Waterfall Methodology – PM 2.

25th September 2019

The waterfall methodology consists of a step-by-step plan consisting of the following: Requirements, Design, Implementation, verification and maintenance. This 5-step method of development has its pro’s and con’s just like any methodology, but I believe it is particularly flawed in ways that methods such as Agile & SCRUM aren’t.  

Breakdown of the waterfall development process: 

Requirements 

The client and/or project owner will approach a development team with their idea/requirements/criteria etc. for the project they want developed. They usually only give input at the beginning and end of this waterfall process, (requirements to maintenance). 

This is flawed because the client should definitely have more input than just their initial idea. They should ideally know what’s going on with their project that they have paid for all the way through rather than just at the beginning and end of the development process. This prevents having to start the process all over again in order to meet the clients requirements that they might have given after shipping. It stops all hard work and time being lost. 

Design 

The design phase of the waterfall method is where the design team comes into play. This features members of the development team such as concept artists, product designers and coders which will then work out what they need in the game to meet the clients expectations. This will then be sent off to a QA or project manager who will sign it off and produce a plan (Game design document) to be given to the production team.  

This is flawed because if the production team doesn’t agree with the design team’s plan. This results in the process going back and forth from design to production. 

Implementation 

This is where the main body of work happens during the development process, also referred to as production. Individual teams such as modelers, programmers, concept artists etc. work to produce their section of the product. Everyone works separately to a plan with almost no say in what other teams are doing at all. Programmers will wait for assets to code,  level designers wait for functional assets, modelers wait for concept art. 

This is very flawed because each member of the team ends up feeling as if they have no say in the final product of the game as they have no clue what’s going on outside of their department. 

Verification 

This stage is where a collection of QA testers (quality assurance testers) will play the game and look specifically for bugs and then prioritize these defects on importance to fix on a number scale (1 being definitely fix, 2 being maybe fix). For example, you will prioritize a major cutscene bug over a minor bug where the player can fall through the world if doing a certain action in a certain place. 

Maintenance 

This is the final stage in which the game is shipped and the final stage of bugging commences once released. The development team gets feedback from the public and fixes problems accordingly.  

The problem with this stage is that if the programming team has spent time working on specific code, they will have to change everything they’ve done in order to make it into something else because of QA or client kickback. The code will then be buggy and ‘spaghetti’ like.