Agile, Scrum, Waterfall, DevOps… And there’s plenty more where that came from. If you’ve looked under the hood of SW development, you’ll have noticed that it actually develops a little different in each company. Why is this so and what are the approaches and methods of SW development? We’ve put together a guide to the basics that might help you stop those spinning brain cells and make things a little clearer.
Let’s be clear from the start: the SW development process can also be called the SW development life cycle. It consists of 5 basic phases that make the final product: software in whatever form you can think of (app, platform, website…).
SW development is not a discipline involving hard facts like medicine, chemical experiments or physics. It is a process based on experience and proven activities. In order to achieve the desired result at the end of the process, i.e. the functional SW, it is necessary to know what to do, when to do it and who should do it and why. These essential things are described and summarised in the methodology. The methodology therefore determines how to approach the development and how to achieve the final product. And these approaches differ quite significantly.
Traditional, agile or DevOps?
Approaches to development, or methodologies, can be broadly divided into 3 categories:
- Traditional ways of development
- Agile ways of development
- DevOps approach to development
In traditional approaches to development, client requirements are defined at the beginning of the process and do not change during development. The team is therefore in touch with the client initially in the analysis phase and then only at the end, when the finished product or prototype is presented to the client; there is no communication with the client in between.
Main methodologies of the traditional way of development:
- Build and Fix model
- Stagewise: strict sequence of phases
- Waterfall model
- Spiral model
- Other methodologies: RUP, USDP, …
Agile development approaches respond to accelerating times and customer needs. Clients often don’t initially know exactly what they want, or conditions or resources change over time and they have to react to that. Agile methodologies therefore emphasize contact with the customer even during the process, and priorities are continuously reassessed. The only way to achieve a good result, according to Agile, is to design a part of SW as quickly as possible, present it to the customer and modify it based on their feedback.
Main methodologies of the agile way of development:
- Adaptive software development
- Extreme programming
- Lean Development
- SCRUM
- Crystal methodology
- Test-Driven Development
- Feature Driven Development
One of the newer and increasingly widespread approaches to development in recent years is DevOps. As the name suggests, it comes from the combination of Development and Operations. Understanding this approach essentially means a complete change in thinking about how SW development works: So simply forget what you’ve read so far. Done? Now let’s explain DevOps.
In very simplified terms, SW has so far been developed as follows: The people responsible for development have created the application and passed it on to system administrators who have deployed it for customer use. So there is Development and Operations, two groups that are dependent on each other. Their communication is crucial for a good outcome, but very complicated in practice and often insufficient for various reasons. Things that are simple from a development perspective may not be implementable on servers from an infrastructure perspective. And what is very easy to solve in the infrastructure might be a tough nut to crack for developers.
But what if these two groups are connected? A DevOps specialist will emerge to facilitate seamless collaboration between development and operations through high-level collaboration, risk sharing, transparency, automation, and change adoption.
Compared to other development styles, they release the product or application into the live environment much more frequently, allowing the team to fix bugs quickly and guaranteeing short delivery times.
Are you interested in the IT field and looking for job positions and opportunities in the IT industry? Whether you are a programmer, developer, tester, analyst, or software architect, contact us and we will find an IT project tailored to your needs from our IT job offers. Take a look at the current available job positions in the IT field. We will help you find new job challenges and opportunities. We look forward to collaborating with you!
Selected methodologies in detail
Let’s take a magnifying glass and explore 3 basic approaches to a little more detail.
SCRUM
Of the agile methodologies, SCRUM is clearly the most used. New project will be initiated by presenting the vision of the final product. The features that the SW should contain are defined, resulting in the description of the so-called User Stories.
What can User Story look like?
As a CMS user, I can:
- upload photos
- crop photos
- change the name of the photo
- show changes made to the photo
All the described User Stories are listed under one another in the so-called Product Backlog. Priorities are then set as to which task to start working on first. An estimate is made of the time it may take to create them, which is used to determine how many tasks can be processed in the first sprint. Sprint takes 2 weeks in Scrum, but no more than a month.
During the sprint, the team holds 15-minute meetings every day, called daily scrum. In particular, problems and factual comments on the development are addressed.
When the sprint is complete, the product is presented to the client. The features that could not be completed are hidden, so the client can only see the completed work. The features are always developed and tested. The client knows which tasks have not been completed and can decide whether they are to be completed. The implementation of the product in a live environment is done at the end, when all the required product features have been developed and tested.
Scrum places great emphasis on risk analysis. The risks are reviewed at the end of each interaction, but also during daily meetings.
Pros
- flexible response to changes
- more freedom for the team – the method is not so much focused on documentation, but rather on the creativity of the solution
- client involvement in development
Cons
- due to frequent changes, there may be large variations in price estimates
- success largely depends on the client’s willingness to cooperate
- a relatively senior and independent team is needed
WATERFALL
The Waterfall methodology has many critics, but it is still the best possible solution for some projects. This approach to development divides the project into phases which it tries to separate; the second phase can therefore only start after the first phase has been completed, etc. In most cases, there are five basic phases:
The philosophy of waterfall is that quite detailed and strict rules are set at the beginning, which are then followed by everyone. The project team has minimal room for change.
Pros
- easy to plan and check
- allows clear identification of responsibilities
- the product can also be delivered by a lower quality, more junior team
Cons
- relatively inefficient way of development
- not enough customer feedback
- little possibility to react to changes
DEVOPS
Finally, let’s take a look at a few more details concerning the DevOps approach.
The philosophy of this methodology is to divide the project into smaller development units, which will allow to present a functional product to the customer in the shortest possible time and get immediate feedback.
It is based on 3 principles:
- continuous integration
It helps detect problems in the coding phase. As soon as the developer implements a piece of finished code into the versioning system, the robot checks the current version and flags any bugs.
- automation testing
The time-efficiency of this methodology is due to the extensive use of automation testing. The tests are usually written by developers themselves and there is no need to wait for the results of manual testing. If this idea is to be taken to the absurd, the tests should be programmed first and the functions after that.
- continuous deployment
Continuous deployment of finished product parts in a live environment enables more efficient and flexible product delivery.
Pros
- shorter development time
- reliable releases of new product parts
- Faster bug fixing
Cons
- the need for automated testing
- use of a large number of tools that are frequently switched between
- so far, it is difficult to get experts with the right knowledge and experience
In conclusion, we would like to point out that every project is different and few projects will actually mirror the theory perfectly in practice. the company always needs to tailor everything to best suit its needs. This is just for the record, so that those brain cells that we calmed down at the beginning don’t get too bored. :)
Approaches to software development are always moving forward bit by bit, responding to changes in the times, client requirements and, of course, time and financial efficiency.
🟡 Are you looking for an interesting project? Check out how we do things here and see which colleagues we're currently looking for.
🟡 Do you have a colleague or friend who is looking for a new project? Join our Referral program and get a financial reward for your recommendation.
🟡 Would you like to start working in IT? Download our ebook START WORKING IN IT: From First Steps to Dream Job, in which we guide you step by step with information, courses, and practical experience that are so essential not only for those who want to switch fields, but also for those who want to advance their careers and further their education.
Or share this article, which may also be useful to your acquaintances.
