METHODOLOGIES
In this page, we will be exploring the fundamentals of Methodologies and how it is used in various ways. These will include three different types of Methodologies including their structure and how it is applicable to different types businesses.
Types of Methodologies:
- Waterfall Life cycle/model
- Rapid Application Development (RAD) - E.g. Spiral Model
- Agile Methods - E.g. Extreme Programming
WATERFALL LIFE CYCLE/MODEL
CONTEXT: The Waterfall Life cycle was originally established by Dr Winston W. Royce and was written during 1970 - Royce had critiqued that his model still had flaws and that is was still applicable to software development to certain extents.
Regardless, the Waterfall Life cycle is still commonly used in modern software development today, a common example would be almost any gaming company in which most of their games involve testing at a consumer based level which may include alpha/beta testing stages in two variations; open or closed. Testing is essential in modern software development as it helps to debug and maintain the software to an acceptable standard towards consumers for when it is officially released or sold.
The model is sequential/linear meaning that each stage has to be finished in order to proceed to the next stage in an ordinally fashion. This is where Royce had made a necessary change to allow a return to previous stages if certain problems had occured in the current stage due to a previous mistake or problem in a former stage; hence the name given to the model as it is displayed as a Waterfall with arrows descending and ascending throughout multiple stages.
The stages of the Waterfall Lifecycle (following Royce's original phrases):
- Requirements - System and Software requirements including documentation.
- Analysis - Considerations of feasibility during development (i.e. technical, economical, legal, operations, schedule).
- Design - A design method is implemented to structure parts of the software (e.g. data dictionary, data flow diagrams, flow charts, structure diagrams).
- Coding - Looks at development aspects including integration of other codes and testing individual units.
- Testing - Includes elements of testing (i.e. alpha/best testing & white/black box).
- Maintenance - Focuses on updating the software (after released or before), such as corrective, perfective or adaptive maintenance (usually continuous).
Why it might be used:
- Used in linear projects where requirements are specified and fixated at the beginning.
- No real benefit towards the customer of having it early - arguably less time consumable.
- Often used for short projects (e.g. videogames, softwares, products etc.)
- Used as a method of trial and error to establish an ideal image.LI>
- Model is extremely easy to implement and output.
| Pros | Cons |
|---|---|
| Documentation allows analysis and crucial building points to expand | Lots of documentation can also mean it will be time consuming |
| Easy to schedule and arrange tasks to judge processes | Requirements may have to be modified if system fails to meet criteria |
| Testers not needed during early development | Testers not involved until late stage could affect late crucial feedback |
| Coding is structured and laid out so it is easy to organise | Efficient coding is not prioritised |
RAPID APPLICATION DEVELOPMENT (RAD)
CONTEXT: Rapid Application Development was originally introduced by James Martin and was established in 1981. It is said to be an alternative towards the Waterfall Life cycle as its primary focus is on the process for the software development as opposed to the planning involved (i.e. less documentation involved).
RAD can be explained in steps few steps which can be iterated to produce a refined final prototype which becomes the final product. Usually an analysis and a quick design is used to begin the prototype which is then further modified/alternated through multiple stages (some could be repeated several times) which often involves refining, developing and demonstrating the product the client.
The stages of the RAD Model (using a typical modern example):
- Requirements - Necessary details of the prototype are noted including System and Software requirements.
- Demonstrate - Evaluating the prototype with client.
- Develop Producing the prototype from the requirements and feedback from demonstration.
- Refine - Modifying or upgrading the prototype accordingly from feedback.
- Testing - Testing the functions of the prototype.
- Deployment - Final product of the prototype (end product).
Why it might be used:
- When client/customer is uncertain of their requirements.
- RAD is often used when a system can be modularised (i.e. flexibility or variation required).
- Certain stages/cycles are made easier to managed.
- Used as a method of trial and error to establish an ideal image.
| Pros | Cons |
|---|---|
| Helpful when requirements become obscure | Efficient code is not often prioritised |
| Usually results in excellent usability | Can be straining on client's time for feedback |
| Encourages customer feedback | Programmer's have to constantly adhere to client's need |
| Alternating requirements can be accomodated |
THE SPIRAL MODEL
CONTEXT: An example of RAD would be the Spiral Model which was invented by Barry w. Boehm during 1988. The spiral model adds the RAD prototyping and multiple risk analysis stages (to allow further analysis) to the already established waterfall model we've encountered before, the entire cycle consists of four divided quadrants (sections) and is shape as a spiral, hence its name. The starting point of the model lies in the center of the spiral which is then slowly proceeded by following each quadrant clock-wise until the end is reached.
Likewise, the spiral model is similar to the waterfall model as it builds upon the baseline of multiple software development models. These include the requirements, development, design, coding and testing. With the exception that the sprial model places a high priority on risk analysis - this is further reinforced through stages of iteration as the developing project would repeatedly pass through each quadrant until it reaches the end of the spiral.
As such, each quadrant/phase can be given its appropriate name starting with:
- Quadrant 1 - Objectives/Alternatives
- Quadrant 2 - Evaluating/Risk Analysis
- Quadrant 3 - Developing/Designing
- Quadrant 4 - Planning
Remember that in order to proceed to the next quadrant, you have to travel clock-wise throughout the spiral, so that the starting point lies on quadrant 1 ("Review") and that the end point ends at quadrant 3 ("Service").
Why it might be used:
- High chances of risks involved for a project.
- Users/client unsure of wanted product.
- Varying changes expected overtime (market and research).
- Long-term project that is fixated from the start.
- Explore different aspects of products (so new products are introduced).
| Pros | Cons |
|---|---|
| Lots of risk analysis so there is a high chance of avoiding risk | Risk analysis often require specific high skillsets to detect |
| Strong project control (including documentation) | Success of project solely depends on risk analysis stage |
| Ideal model for large group projects as it breaks down large stages which is then risk analysed | Not ideal for small group projects as it is too time consuming for each stage |
| Software is usually introduced early into the Spiral Model | Can be relatively expensive as it involves more expertised skillsets |
AGILE METHODS
CONTEXT: Agile Methods, similar to the Waterfall Life cycle, was once again created from Dr. Winston W. Royce except in an indirect manner, where a community of software engineers had taken Royce's criticism in the sequential/linear development cycle to create a more effective and light method - allowing a change in direction of a project throughout its development cycle. A specific reason for this design was by the time a project had successfully been completed using this method, the project becomes irrelevant and outdated due to all the time needed to reach every requirement. This is especially important as in the world of business markets and products are constantly changing at a fast pace and that companies cannot be completely dependent on one project as a liability.
The 12 principles (guidelines) of Agile Methodology:
- Customer satisfaction by early and continuous delivery of valuable software
- Welcome changing requirements, even in late development
- Working software is delivered frequently (weeks rather than months)
- Close, daily cooperation between business people and developers
- Projects are built around motivated individuals, who should be trusted
- Face-to-face conversation is the best form of communication (co-location)
- Working software is the principal measure of progress
- Sustainable development, able to maintain a constant pace
- Continuous attention to technical excellence and good design
- Simplicity—the art of maximizing the amount of work not done—is essential
- Best architectures, requirements, and designs emerge from self-organizing teams
- Regularly, the team reflects on how to become more effective, and adjusts accordingly
Since there are many variations and generlisations of Agile Methods, there is no official diagram able to completely justify each stage by one diagram/model. As such, this could be operationalised by thinking back to the Waterfall Life cycle but with each stage not having to become linear/sequential and that any stage could hop onto the next since it isn't fixated.
Here's a quick mock-up I produced (may not be entirely representable):
Why it might be used:
- Provides opportunities to assess the direction of the project.
- Potentially shippable product available as resource.
- Greatly reduce development costs and time to market.
- Helps companies build the right product as it is never irrelevant.
- Multiple opportunities to improve different aspects of the project.
| Pros | Cons |
|---|---|
| Regular maintenance of every work aspect | Could eventually become time consuming |
| Able to steer project in another direction | Time wasted on previous work produced |
| Encourages groups of teams to colloborate together | Higher employment costs and management of teams |
| Able to make the right product for the company | Working on a long project could potentially be draining |
EXTREME PROGRAMMING (XP)
CONTEXT: Extreme programming is an example agile methods, unfortunately the title isn't what it entirely suggests. Instead it involves pair programming (where two developers program together) which promotes the use of a flat management structure (there is only one manager controlling each and every pair group) in order to produce quality software production and potentially increases the productivity of working on long projects. Since extreme programming uses a flat management structure, it is highly encouraged to work in a small team of developers as management should be kept simple and coherent, otherwise it would be hard to manage each individual groups of pairs amongst a large team of developers.
Working in pairs allow developers to take shifts in programming and testing amongst the software so there is a continuous flow of feedback and opportunities for improvement with every working shift. As a result, it is arguably less tiresome and more motivating when working in pairs as there is an alternation of the work needing to be produced which is less tiring when the workload is shared. However, pair programming usually involves being at one workstation together as a pair and therefore requires two programmers to be in the same geographic location, otherwise it wouldn't necessarily work as efficiently or work at all.
The stages of Extreme Programming:
- Release Plan - Current planning of the intended project/software
- Iteration Plan - Steps/stages to be repeated as a quality assurance check
- Acceptance Test - Software is then tested for acceptability (required standard)
- Stand up Meeting - Developers/programmers meet together to further discuss any other requirements or plans
- Pair Negotiation - Assigned pairs will discuss with each other on what tasks they will be handling
- Unit Test - Modules of the source code is broken down and tested individually to make sure procedures work as intended
- Pair Programming - Each pair will produced a module of the software which will then be merged for the complete product
- Code - The final code is assembled with all the modules produced which is then the final product/software
Why it might be used:
- Provides opportunities to assess the direction of the project.
- Potentially shippable product available as resource.
- Greatly reduce development costs and time to market.
- Helps companies build the right product as it is never irrelevant.
- Multiple opportunities to improve different aspects of the project.
| Pros | Cons |
|---|---|
| Continuous flow of feedback | Feedback may not always be useful |
| Less draining when working on long-term projects | Working in pairs usually means long-shifts |
| Able to work together in one workstation | Pair has to be in the same geographic location |
| Increase productivity amongst the work force | Only able to work in small groups for it to be effective |