Posted by: Daniel Boterhoven on Mon Oct 25
Like any other type of project, it has become necessary to establish and document processes and guidelines to best deliver web or mobile applications as quickly and cost effectively as possible. Luckily for us in the industry, the application development process has become particularly well defined.
Knowing the basics of the process outlined in this article will be fundamental to successfully releasing a web or mobile application of your own.
Up until the year 2001, the standard approach to application development, or any software development projects for that matter, was the Waterfall approach. This approach is defined as a linear set of stages that encompass the entire development and release of a piece of software. The stages are typically defined as requirements capture, analysis, design, development, testing and support.
The problem with the Waterfall approach is that it is at odds with the necessary flexibility and adaptability needed in modern software. The technological world is evolving at an exponentially fast rate, and so by the time the customer would see the end product from a Waterfall development, the customers’ needs and desires might have since changed a number of times.
So, in response to this inflexible and monolith of a development process, the developer community moved for a more versatile and granular approach.
The Iterative development approach originates from the “Manifesto for Agile Software Development”, which was released in 2001. After the publication of this manifesto, the software development industry started to slowly enshrine the iterative methodologies into the development procedures.
This Iterative approach, would be more flexible and adaptable compared to its predecessor. Fundamental to this approach would be the concept of iterations, which would be smaller and more manageable blocks of developmental milestones. By making these iterations small, typically 2 – 4 weeks, changes to the project requirements could be fed into the development in an orderly manner, between iterations.
At a high level, the stages within an iteration loosely reflect the stages defined in the Waterfall approach. However, there are some key differences, given that an iteration is far smaller when compared to the entire Waterfall lifecycle. Let’s go into some details of the steps that typically make up an iteration.
Commencing each iteration is the planning stage. This is where the project team discuss and evaluate requirements, priorities and timelines. In this stage, the plan for what will be developed and delivered at the end of the iteration is clearly defined and shared between all project stake holders.
Responsibilities will be assigned and tasks will be delegated to team members as required. If this is not the first iteration of the project, then analysis and requirement changes from the previous iteration will be factored in where necessary.
In the planning stage it is important to ensure that each task is assigned an estimated duration, or “size”. Tasks that are determined to be too large should be broken up into smaller components and should potentially be spread out over more than one iteration.
It is also expected that at the end of this iteration a working product should be available. This does not mean a fully-fledged product with all features implemented, particularly in the early iterations. However, a functioning and working application should be available for review by the project stake holders.
Once the plan for the iteration has been set in stone. The designers and developers will begin the execution of the tasks assigned to them.
A common approach is that designers will start wireframing the necessary application layouts and interfaces. While this is underway, the developers will start coding the necessary infrastructural “plumbing” of the application.
Once the wireframes have been discussed between the team and given the all clear, the designers will produce the final graphical mockups of each wireframes. These can then be implemented by development team into fully functional web or app components.
This stage is probably the most hands-on and will typically also take up the most time, particularly in the early iterations. The end goal of the stage is to have all the graphical and logical components of the application in place and operational so that the test team can ensure they adhere to the requirements set forth in the planning stage.
The testing stage is necessary to ensure that the design and developmental requirements have been met. It’s also the time to ensure that the product of the iteration is of high quality, with ideally minimal bugs and imperfections.
Typically, a dedicated test team will create use cases, or user stories, that match the requirements laid out in the planning stage. They will then go about physically testing the application by acting out the use cases. Any components that result in an incomplete or incorrect use cases will be classified as a bug that will be corrected by the designers and developers.
{{> relatedarticlesinline articles=model.related }}
A secondary level of testing, known as user acceptance testing, will also be performed following the successful completion of the use case testing. This is where the project stake holders have their chance to review the product and provide their feedback to the team. Any significant issues raised will be either resolved in the iteration, or factored into later iterations, depending on their severity.
At the conclusion of the testing phase there should be a fully functioning version of the application that includes all the agreed new features. This version should be stable and ready for use by the customer.
The final stage of the iteration starts with the go-live of the new product version. The act of releasing the version should be a simple one. However, what happens following the release is probably the most important part of the entire iteration.
Following the release is the time when customer acceptance and feedback should be gathered. Analytical systems should be built into the product from the beginning so that as much information about customer usage and behaviours can be extrapolated for consideration and review.
Ultimately, the team will need to understand what the customer finds valuable in the latest release, and also what they do not. This information should then be used to drive the future direction of the project, and in particular, what the priorities are in subsequent iterations.
The Iterative development approach superseded the Waterfall approach due to the latter’s shortfalls in the dynamic and rapidly changing technological landscape. By following a more fluid and flexible approach to application development, changes can be factored in earlier on, and the customer is more likely to end up with a product that they actually want.
By planning excessively long iterations with too many new features, your development lifecycle will reflect the traditional Waterfall approach too closely. So, to avoid inflexibility and the inability to factor in change, be sure to prioritise features effectively, and keep your iterations short.
Keep in mind that your end goal is to gather as much feedback from your customer, so that you can steer future iterations in the right direction. This will help your product to grow and will provide real value to your customer, which will ultimately ensure your products ongoing success. …
Photo by RealToughCandy.com (RTC) from Pexels
Subscribe for updates