As an experienced software company with extensive technological know-how, we can not only explain theoretically which models are used when, but also implement them practically.
Process models of software development determine which activities are carried out in which order in the entire software life cycle. Today, more than 50 recognized models are in use, which raises the question: which process model is best suited when?
When selecting a model, certain requirements regarding budget, costs and deadlines of the project, roles and responsibilities of the participants can be taken into account. But one should not forget that none of the process models in software development is perfect and has its advantages and disadvantages. In our blog post we compare the 8 most popular models to give an insight into their basic principles and areas of application.
All process models of software development can be divided into several groups: depending on how the process is running (linear or iterative) and which relationships are established between the development team and the customer (formal or informal).
The process models from the lower quadrants of the graphic follow a sequential approach, i.e. all activities are performed one after the other. They are easy to implement, enforce and manage. The higher the models are in the diagram, the more flexible the software development process is when it comes to changing requirements for future software.
In the process models on the left side of the graphic, the degree of customer participation is very low. On the right side are models that are more “cooperative” and require more intensive customer involvement in different phases of the software development cycle.
Waterfall model
In this sequential process model the development process is organized in successive phases: Analysis, design, coding, testing, installation, maintenance. Each individual phase is strongly documented.
As soon as the previous phase is completed, the next one begins, based on concrete results of the previous phase. Therefore, there is no possibility, for example, to re-evaluate software requirements during the development phase.
It is also impossible to see and test the finished software until the last stage of development is completed, which leads to high project risks and unpredictable results. Therefore, errors are only found at the end of the project in the test phase. Their immediate correction requires more effort and leads to increasing overall costs.
Fields of application:
- Simple small or medium-sized software projects with clearly defined and unchangeable requirements (development of a website for small companies).
- Projects requiring tighter control, predictable budget and schedules (e.g. government projects).
- Projects where multiple rules and regulations must be followed (medical software projects).
- Projects that use a known technology stack and tools.
V-model
The V-Modell is another process model in which all phases are run through one after the other, i.e. linearly. But for each stage corresponding test activities are defined.
On the one hand, this allows to control the software quality more efficiently and thus reduce project risks to a minimum. On the other hand, this makes the V-Modell one of the most cost- and time-consuming models.
Even if errors in requirements specification, code and architecture are detected early, it is still expensive and difficult to implement changes during development. As with the waterfall model, all requirements are captured at the beginning and cannot be changed. Projects where disturbances and downtimes are unacceptable (e.g. medical software, software for fleet management in air traffic)
Incremental development
The development process based on the incremental process model is divided into several manageable iterations (a modular approach to software design in “Lego style” is required!) Within each iteration, new functional individual parts (increments) of the software are created and delivered, whereby the previously added parts remain unchanged.
The software development process can be either sequential or parallel. Parallel development enables faster delivery. In contrast, many repeated successive development cycles can be a basis for the project to take longer and become more expensive.
Iterative Development
In iterative development, individual phases are run through several times. Within each iteration the software is changed, developed further and extended. Since the software is improved step by step, i.e. iteratively, there is no need to create the complete specification at the beginning. Only the most important requirements are defined. The iterative approach offers the possibility to react flexibly to changes in requirements during the course of the project, which is also based on customer feedback.
Large projects in which business critical enterprise applications are developed, preferably based on loosely coupled components such as micro services or web services.
Spiral model
The spiral model focuses on a thorough risk assessment. To fully exploit the advantages of the procedure model, you need to involve specialists with extensive knowledge in risk assessment. A typical iteration in the spiral model takes about 6 months and includes 4 key activities – careful planning, risk analysis, prototyping and evaluation of the previously delivered part. Repeating cycles in the spiral model can significantly extend the project duration.
In this model, customers can be involved in the earlier phases, such as research and testing. During the development phase, additions from customers are not acceptable.
Fields of application:
- Projects with unclear business requirements or too demanding / innovative requirements.
- For large and complex projects.
- Research and development (R&D) activity or introduction of a new service or product.
Procedure model RUP
The Rational Unified Process (RUP) is a combination of linear and iterative frameworks. The model divides the software development process into four phases: Conception, design, construction and delivery. Each phase except conception is usually performed in several iterations. All basic activities (requirements analysis, design, etc.) in the software development process are performed in parallel over these 4 RUP phases, but with different intensity.
RUP helps to build stable and at the same time flexible solutions. Nevertheless, this model is not as fast and adaptable as pure agile process models (Scrum, Kanban, XP etc.). The degree of customer involvement, the scope of the documentation to be created and the duration of an iteration can vary depending on the project requirements.
Application areas:
Large and high-risk projects, especially use case-driven development and fast delivery of high-quality software.
Agile process models
As representatives of agile process models we have chosen Scrum, Kanban and XP. Today, more than 70% of organizations use this or that agile approach in their IT projects. Agile process models are generally characterized by iterative development, intensive communication and early customer feedback and are aimed at making the development process leaner and more flexible.
Each iteration can usually last several weeks and delivers a fully functional software version. The process models of this group focus more on the rapid development and delivery of a functional intermediate product. Less emphasis is placed on detailed software documentation and more attention is paid to testing activities.
The close cooperation both in the team and with the customer makes it possible to monitor and continuously improve the quality of the delivered product from iteration to iteration, to make the development process more effective and as a result to increase the return on investment (ROI). The customer needs are in the center of attention.
But there is one thing to keep in mind: it is difficult to get an overall view of the project (e.g. budget, time and number of project participants to estimate) if there is no detailed planning and openness for changes.
Fields of application:
- Virtually all startup initiatives where early feedback from end users is required.
- Most mid-sized custom software development projects where detailed software requirements are based on business needs.
- Large projects that can be easily broken down into smaller parts and implemented step by step.
There are different agile process models for every taste. But Scrum, Extreme Programming (XP) and Kanban are among the most popular ones.
Agile process model – Scrum
Scrum is one of the most popular Agile development methods, which allows the division of the entire project duration into short iterations (so-called sprints). Each iteration starts with careful planning and ends with the Sprint Retrospective, where the previous sprint is analyzed and evaluated. This is followed by the next sprint, which is built on the results of the previous sprint (e.g. customer feedback, new product requirements and more). An iteration usually takes from 2 to 4 weeks. Once the activities for the next sprint have been determined, no changes can be made.
Extreme Programming (XP)
Agile process model – XP
Extreme Programming (XP) focuses on short iteration cycles and customer integration. A typical iteration takes 1-2 weeks. This process model is based on customer requirements and needs and allows to involve customers intensively and to integrate necessary changes into the development process.
This flexibility makes the delivery of high-quality software considerably more difficult. To meet these requirements, XP applies best practices: programming in pairs, test-driven development and test automation, continuous integration, small releases, simple software design and coding standards compliance.
Agile Method – Kanban
Kanban is also an agile method. But in contrast to Scrum and XP iterations are optional. If they are used, they are extremely short (“daily sprints”). Instead, the focus is on the visualization of work steps.
The team uses the Kanban Board for visualization to get an overview of all project activities, their number, responsible persons and the progress of projects. Such increased transparency helps to prioritize and complete the most urgent tasks. In addition, the model does not have a separate planning phase, so a new change of requirement can be introduced at any time.
Communication with the customer never stops, so he can check work results at any time. Meetings with the project team can even be held daily. By its very nature, this model is often suitable for software support and development projects.
Based on the research data, we compared the models in terms of core characteristics – time, cost and quality – to make them clearer and easier to understand. All estimates refer to small apps with a code consisting of 1,000 code blocks.
Agile or classic? Which fits better?
We know that requirements must be the main focus when choosing a model. There are a number of parameters, such as the flexibility of requirements, the approach to collaboration and more, by which each process model can be evaluated to choose the model that fits your needs. Our team is ready to support you not only in the selection, but also in the implementation of your project with the appropriate model.
