Cascading and iterative models of software and application development

Iterative application development

Iterative application development is a software development process that takes place in small steps, during which the intermediate results obtained are analysed, new requirements are made and previous steps are corrected.

The project life cycle during iterative development is divided into a sequence of iterations, each of which is in fact a miniature project, i.e. it includes all the software development processes (requirements gathering and analysis, requirements specification development, direct implementation, testing and launching), but within one iteration not the whole project is developed, but only a version or a separate part of it.

As a rule, the goal of each iteration is to achieve a version of the application that includes both new or improved features implemented during the current iteration and the functionality of all previous iterations. The result of the final iteration, on the other hand, contains all the required functionality of the product.

The budget and timeframe required to implement the final version is usually not pre-determined, as the total scope of work is not defined and requirements are generated during implementation.

Iterative, iterative, incremental and evolutionary development are in fact synonymous.

Iterative (iteration, "iterating") in this case refers to a task-based approach of "mini-projects", incremental (increment "increasing") refers to the sequential addition of functionality to the product under development, and evolutionary (evolutio, "developing") refers to a product development process resembling the natural development of biological species.

Cascading and iterative model of application development

Metaphorically, the comparison between cascading and iterative development models is often described using the example of vehicle development.

In the case of the cascade model, the required vehicle features are first described and then the design documentation is developed based on these requirements. Once the design documentation has been developed, the individual vehicle components are assembled and integrated into each other. The resulting assembly is then tested according to the design documentation before the finished vehicle is handed over to the customer. All these stages take quite a long time, and it is only at the very end that the customer receives a usable product.

The iterative approach is slightly different. The task of constructing the vehicle is set at the beginning. And the result of the first iteration could be a variant of such a vehicle - for example, a scooter. It does not need an internal combustion engine and can be assembled dozens of times faster than a car. Yes, the scooter loses out to the car in many ways, but it is still more efficient to get around than walking. A second iteration could result in a scooter with an electric motor. In the third iteration, the scooter may have larger wheels and become an e-bike. In the fourth iteration, the e-bike may be equipped with an internal combustion engine and become a motorbike.

Indeed, with each iteration, functionality increases. And while waterfall advocates wait until the vehicle is ready, those who love the iterative approach are already using it. And it may turn out that the resulting motorbike is a better business outcome.

The key benefits of the iterative application development model are risk mitigation - early detection of conflicts between requirements, models and project delivery; increased focus on key tasks; dynamic requirements generation and management.

Organisation of effective feedback from the project team to the customer, resulting in a product that actually meets the customer's needs.

Quick release of a minimum value product (MVP) and the ability to bring the product to market and start using it much earlier.

The main disadvantages of the iterative application development model are architecture issues and overheads - when dealing with chaotic requirements and without a coherent global plan, the application architecture can suffer and additional resources may be needed to bring it into the right form. In fact, the ability to change requirements during development comes at a price, one way or another.

There is no set budget or deadline and a high level of customer involvement in the process is required - for some customers these are unacceptable conditions for working with a developer, better suited to a cascading model.

Cascading model of application development

The cascade model of software development (waterfall) is a development process in which the phases of requirements gathering and analysis, design and prototyping, implementation, testing, integration and support proceed sequentially.

According to the cascade model, developers move strictly sequentially from one process to the next. First, the requirements gathering phase is fully completed - a list of identified software requirements is created. Only after the requirements have been collected and captured, does the design process proceed, during which a programming specification is generated that describes the tasks to be performed by the programmers, as well as the implementation methods and associated constraints. Once the design is fully complete, the programmers execute the project according to the scope of the requirements - in the example of creating a website, the design is drawn, the layout and coding of the website is done. After the design phase, the developed product is tested. At this stage, all defects are identified and eliminated according to the scope of requirements. The project is then launched and support is provided - ensuring operability and debugging.

The cascade model assumes that the transition from one product development phase to the next occurs only after the completion of the previous phase and that there are no returns or overlapping of phases.

Developing software or applications in this model allows for strict budgets and deadlines. However, working in this model can be effective only if the client understands the goals and objectives of the product being created in great detail and is able to formulate them. This is due to the fact that the scope of work is also fixed - if something is not in the ToR, it will most likely not be completed within the agreed budget and deadline. Making changes in waterfall projects is also quite problematic. So for really big projects and creating anything innovative, this model is not suitable.

An alternative to waterfall is the iterative development model (for example, various "agile" methodologies).

Iterative development is great for large projects, for projects with uncertain requirements and for software products that are innovative and based on business hypotheses that need to be tested.

Are you looking to partner with a Python Software House that creates dedicated web applications, dedicated mobile applications and custom websites?

Are you looking for a Software House that has in its offer creating dedicated web applications using Python, Django and Flask?

We are Python Software House, which has existed on the market for 20 years and has in its portfolio made dedicated web and desktop applications and custom software, as well as advanced IT systems. We create digital tools and solutions that not only visualize data, but also integrate it into regular business processes, create data-driven full-fledged dedicated mobile and web applications that make data more accessible to the entire organization.

Maybe you want to use solutions based on artificial intelligence algorithms, machine learning or deep learning in your business?

Information technology has turned from a service to business into its foundation. We build digital competences in the area of your interests and help you find new models for your business. It's our mission

Talk to us about your project and we will take into account the specifics of your business, the time and budget provided and together we will choose the best option for its implementation.