Designing software, a website or applications at a professional standard for clients or project managers, requires a team working in constant collaboration. To achieve this, various methodologies are used. A methodology is a system where set routines are followed to achieve a particular outcome. There are many methodologies out there, all of which have there strength and weaknesses, depending on a range of different factors. In this post, I’m going to go over the main methodologies used by software/web firms; discussing there pros and cons.
Fairly common among business, this methodology is pretty straight forward where you: Gather all the data and requirements, begin design, test the product(code, system and user acceptance), look for any issues, then finally, deliver the product. Each stage is of course, more detailed, but this is just a simple layout.
Everything is decided early on, making planning and design much simpler. In addition, the work required can easily be measured.
After requirement stage, customers or clients, doesn’t need to be physically present, except for a review, current progress approval meetings.
Possible for team members to work on other projects and task, as the team moves through different stages in the project.
Customers can have trouble visualizing product with just documented requirements
Customer only really sees what’s produced near the end of the product. The issue with that is the customer may not be happy with what they see, but at that point, it would be too costly and difficult to make any significant changes.
Agile methodologies is broads term that includes: scrum, extreme programming, RUP, among many. It’s heavily team based, where all members of the project are working together, rather than in separate departments at different phases. Unlike waterfall, the work being done is very visible for the client to see. The aim is to split the process into sprints(or iterations). Each sprint is like a mini project with well defined objective that can last between one to four weeks. Work at the end of each sprint is constantly reviewed and evaluated by the customers or stakeholders, so it takes a lot of commitment.
Development is very much based around the clients input, as the client is seen as the most “critical” member. This gives the client a sense of control on the outcome of the product.
As mentioned before, the work and progress of the team is very visible to the client early on, thus it’s easy for the client to make edit and changes to product throughout development.
Extensive collaboration with clients or stakeholders gives the team a true understanding of what is desired.
Opportunity for changes. New or changed items can easily be planned for future sprints(iterations)
Clients needs to commit a lot of time, which may not be practical for many
The time and dedication required leaves little room for team members to work on other projects
Many items may not be completed in the planned time frame of the project, adding to cost. This is due to the nature of agile, where thee are frequent re-prioritization and changes. Constant input by the customer may also add to cost.
Compared to waterfall, there is less focus on the end product at the start of the project. This could prove to be an issue in very large and complex projects, as well as projects that requires a high degree of integration.
The spiral method, is used by organisations such as NASA. The method has four distinct phases, which include planning, risk analysis, engineering and evaluation. The product continually go through these spirals.
The focus on risk analysis, ensures that risk is minimized at all cost.
Due to the emphasis on risk, it’s very good for very important and critical projects.
Software is made early
Can be very expensive to implement
Isn’t suitable for more moderate and smaller projects
Project reliant on the success of the risk assessment phase.
Other notable methodologies:
– Time and motion
– Prototype model