Introduction

The Software Development Life Cycle (SDLC) is a conceptual model used in project management that specifies the stages involved in the development of an information system, from an early business plan to the maintenance of the finished application.

Various SDLC models are used in the software development phase. These are also known as "Software Development Process Models". To ensure success in the phases of software development, each process model follows a sequence of phases unique to its nature.

What are popular software development models?

There are already more than 50 recognised SDLC models in use. None of them are flawless, and each has advantages and downsides for a particular software development project or team. Here we are going to look at some of the commonly used models.

Waterfall model

Once upon a time, at the dawn of the programming age, the only participants in the development process were programmers. They wrote software functions to facilitate mathematical calculations or automate other routine activities. Today everything is different. Modern systems are so large and complex that entire teams of specialists of various profiles work on their creation: programmers, analysts, system administrators, testers, and end users. They all work together to develop programs containing millions of lines of code.

The oldest and most well-known model for building a multi-level development process is the waterfall model: in it, each development stage corresponds to a certain phase of the software development life cycle and directly continues the previous one. That is, in order to move to a new stage, we must fully complete the current one.

The waterfall model is simple and straightforward, but not as practical as it once was. In the face of dynamically changing requirements, a rigidly structured process can turn from an advantage into a hindrance to the successful completion of system development. Therefore, today the waterfall model is mainly used by large companies for large and complex projects that involve comprehensive risk control.

Pros of the waterfall model:

• Full documentation of each stage;
• Clear planning of terms and costs;
• Transparency of processes for the customer.

Cons of the waterfall model

• The need to approve the full scope of requirements for the system at the first stage;
• If it is necessary to make changes to the requirements later,you have to return to the first stage and redo all the work;
• Increased costs and time if there is a change in requirements.

Despite the fact that the waterfall model is still in use, it has already lost its former positions. Today it is being replaced by more advanced models in software development and methodologies.

V-model

The V-model is an improved version of the classic waterfall model. Here, the process of each stage is monitored in order to make sure that it is possible to move to the next level. In this model, testing begins at the stage of writing requirements, and each subsequent stage has its own level of test coverage.

For each level of testing, a separate test plan is developed. So as the current level is being tested, we are already developing a testing strategy for the next one. We also define the expected test results and indicate the entry and exit criteria for each stage when creating test plans.

Pros of the V-model:

• strict staging;
• testing planning and system verification are carried out at early stages;
• improved time management compared to the cascade model;
• intermediate testing.

Cons of the V-model:

• insufficient flexibility of the model;
• the actual creation of the program takes place at the stage of writing the code, that is, already in the middle of the development process;
• insufficient risk analysis;
• no work with parallel events and the possibility of dynamic changes.

Spiral model

The spiral model represents a software development process pattern that combines the ideas of the iterative and waterfall models. Its essence is that the entire process of creating the final product is presented as a conditional plan, divided into 4 sectors, each of which represents separate stages of its development: setting goals, assessing risks, developing and testing, and planning a new iteration.

In the spiral model, the life path of a product under development is depicted as a spiral, which, starting at the planning stage, unwinds with the passage of each consecutive step. Thus, at the exit from the next round, we should get a ready-made tested prototype that complements the existing build. A prototype that satisfies all the requirements is ready for release.

The main feature of the spiral model is the concentration on possible risks. There is even a corresponding stage for their evaluation. The main types of risks that may arise in the software development process are:

• Unrealistic budget and deadlines;
• Lack of specialists;
• Frequent changes in requirements;
• Over-optimisation;
• Low system performance;
• Inconsistency in the level of qualifications of specialists from different departments.

Pros of the spiral model:

• improved risk analysis;
• good documentation of the development process;
• flexibility - the ability to make changes and add new functionality even at relatively late stages;
• early creation of working prototypes.

Cons of the spiral model:

• can be quite expensive to use;
• risk management requires the involvement of highly qualified specialists;
• the success of the process depends to a large extent on the risk analysis stage;
• not suitable for small projects.

Iterative and incremental model

Not all life cycle models are consistent. There are also iterative (or incremental) models that take a different approach. Instead of one long sequence of actions, the entire product life cycle is broken down into a series of separate mini-cycles. Moreover, each of them consists of all the same basic stages of the life cycle model. These mini-loops are called iterations. In each of the iterations, a separate component of the system is developed, after which this component is added to the previously developed functionality.

The iterative model does not assume the full scope of requirements for starting work on the product. The development of a program can begin with requirements for a part of the functionality, which can subsequently be supplemented and changed. The process is repeated, ensuring that a new version of the product is created for each cycle.

In a somewhat simplified form, the iterative model consists of four main stages, which are repeated in each of the iterations (plan-do-check-act):

• definition and analysis of requirements;
• design and engineering - according to requirements. Moreover, the design can either be developed separately for this functionality, or complement an existing one;
• development and testing - coding, integration and testing of a new component;
• review phase - assessment, revision of current requirements and proposals for additions to them.

Based on the results of each iteration, a decision is made whether its results will be used to supplement existing functionality as an entry point for the next iteration (the so-called incremental prototyping). Ultimately, there comes a point when all the requirements have been embodied in the product. That means it's ready to release.

In mathematical terms, the iterative model represents the implementation of the successive approximation technique - that is, the gradual approximation to the image of the finished product.

The key to the successful use of this model is a strict verification of requirements and a thorough validation of the developed functionality in each of the iterations.

The main stages of the development process in the iterative model actually repeat the waterfall model. Each iteration creates software that requires testing at all levels.

Pros of the iterative model:

• early creation of working software;
• flexibility - ability to change requirements at any stage of development;
• each iteration is a small stage for which testing and risk analysis are easier to provide than for the entire product life cycle.

Cons of the iterative model:

• each phase is independent, individual iterations do not overlap;
• there may be problems with the implementation of the overall architecture of the system, since not all requirements are known at the beginning of the design process.

Scrum

Scrum is a sporting term taken from rugby. Initially, it denoted the state of the teams at the beginning of the match, before the ball is dropped.

In software development and support, its value lies in the minimum required number of resources, roles, common rules, and other things that are necessary to start a teamwork cycle. Otherwise, it can be called the basic necessary set of rules, which at the output will give a ready-made working solution.

Scrum development methodology involves creating a product with new business opportunities that have the highest priority. This is done in a certain number of fixed time intervals (cycles), which are called sprints.

Usually, before the start of the sprint, there is a meeting where tasks and the duration of the sprint are planned. Following the results of the sprint, a review meeting is held, where the customer is shown a version of the product with all the main functions. The customer must accept the product at this stage or make adjustments so that it is clear what the next step should be - another sprint (finalisation) or the delivery of a finished solution.

The duration of one sprint is 1-4 weeks. On one hand, reducing sprint time speeds up development and makes it more flexible, because releases come out more often. It also allows you to quickly respond to feedback from the customer / client. On the other hand, the increase in terms allows you to reduce the overhead costs for a lot of meetings, corrections, and so on. The team selects the duration of the sprint depending on the type of product.

Like any tool, Scrum is good for getting things done. However, sometimes it turns out to be an inefficient way to solve certain problems. In this section, we'll talk about when this happens and what to do about it.

So, the effectiveness of Scrum is manifested only when a number of conditions are met. Their list looks something like this:

• Scrum is good to use in cases where you need to solve a problem, but the solution is not immediately traceable, is too difficult to predict, or the customer allows experiments and research to get the result. If the benefit from the result is directly proportional to and depends on the clarity of the algorithm, then Scrum is not needed.
• Scrum is completely inappropriate in cases where the cost of an error is high.
• There must be feedback, and the customer must be involved in the process.
• If the team is poorly qualified, lacks budget, resources, and so on, the system will also not function. After all, Scrum methodology is focused on achieving maximum efficiency in a short time, and not long-term development.
• Restrictions on the specifics of the methods used. If there is no opportunity to experiment and test solutions, then the system will be ineffective.
• Restriction in terms of communication between team members, bureaucratization of the process. The system will simply get bogged down in papers, approvals, and so on. In other words, the very meaning of Scrum methodology will disappear.

The benefits of Scrum are also obvious:

• The system allows you to solve the problem quickly and in different ways. It allows you to experiment and test solutions in every possible way, finding the best course of action.
• Self-organisation of the team allows you to exclude "paper" intermediaries and respond flexibly to changes.
• Development time is reduced and a finished product is created.

The team is motivated, because no one engages in "passive sabotage" - stretching the work or slowing down the process.

Extreme Programming

Extreme Programming or XP is an agile software development methodology. Like other agile methodologies, it has its specific tools, processes, and roles. Although the author of XP did not come up with anything new, he took the best practices of flexible development and strengthened them to the maximum. That is why programming is called extreme. The purpose of the XP methodology is to cope with the ever-changing requirements for a software product and improve the quality of development. Therefore, XP is well suited for complex and uncertain projects.

The XP methodology is built around four processes: coding, testing, design, and listening. In addition, Extreme Programming has values: simplicity, communication, feedback, courage, and respect.

The XP methodology causes a lot of controversy and criticism from those who have not been able to implement it in their team.

The benefits of Extreme Programming only make sense when the team makes full use of at least one of the XP practises. So, it's worth a try for the following reasons:

• the customer receives exactly the product that they need, even if at the beginning of development they themselves do not accurately imagine its final form;
• the team quickly makes changes to the code and adds new functionality through simple code design, frequent planning and releases;
• code always works through constant testing and continuous integration;
• the team maintains the code easily, because it is written according to a single standard and is constantly refactored;
• fast pace of development due to pair programming, lack of revisions, and the presence of the customer on the team;
• high quality code;
• the risks associated with the development are reduced, since the responsibility for the project is distributed evenly and the departure / arrival of a team member will not destroy the process;
• development costs are lower because teams are focused on code, not documentation and collections.

Despite all the pluses, XP does not always work and has a number of weaknesses. So, extreme programming - disadvantages:

• the success of the project depends on the involvement of the customer, which is not so easy to achieve;
• it is difficult to predict the time spent on the project, because at the beginning no one knows the full list of requirements;
• the success of XP is highly dependent on the level of programmers, the methodology only works with senior specialists;
• management has a negative attitude towards pair programming, not understanding why they should pay two programmers instead of one;
• regular meetings with programmers are expensive for customers;
• requires too much cultural change: not being able to control every task can be stressful for the management or client;
• not suitable for large projects due to the lack of structure and documentation;
• because flexible methodologies are function-oriented, non-functional product quality requirements are difficult to describe in the form of user stories.

Kanban

Kanban is a system for setting goals and organising workflows to effectively achieve the necessary outcome. This methodology assumes transparency regarding the progress of work and is one of the most popular Agile approaches.

Kanban helps to track the progress of tasks and distribute the workload among employees. This method allows you to effectively manage the work of the team and monitor the timing of its implementation. The visualisation of all stages allows each employee to be aware of the current progress. Let's familiarise ourselves with the basic principles of the Kanban methodology.

• Visualisation of processes. It is important that all assigned tasks are added to the plan. Their status needs to be updated as each completed stage is completed. This approach allows you to move forward step by step, monitor progress, and spot which tasks require more time and help.
• Task grouping. This is done based on status. The easiest way is to divide the tasks into three columns: "To be done", "In progress", "Done". This approach involves moving the task from one stage to another and visualises the workflow.
• Attention to unfinished tasks. If some tasks are left hanging at a particular stage, you should understand the reasons why, allocate more resources if needed, or provide the necessary support to complete the work.
• Continuous improvement. Tracking the deadlines for tasks and their movement from one level to another in the Kanban system helps to see the weak points in the processes. Therefore, you can clearly determine where you need to devote more or less time to work, and in what situations it is worth adjusting the load.

The Kanban methodology has no hard and fast rules or restrictions. Therefore, it is used in various fields. The Kanban method is used by HR specialists for the selection of candidates, software developers, startups, and even bloggers. This approach can also be found in CRM systems when developing a sales pipeline. Take a look at the benefits of the Kanban methodology.

• Planning flexibility. The Kanban system is designed in a way that has the team concentrate on one specific task, despite the fact that there may be several of them. At the same time, the manager can change the priority of different tasks without affecting the workflow. Once one task is completed, the team moves on to the next.
• Control of deadlines. The Kanban methodology allows you to track the workflow, optimise its duration and predict the time it will take to solve future tasks.
• Improving work efficiency. Multitasking reduces the quality of work and slows down progress. The more unresolved tasks hang, the more often you have to switch between them. The Kanban method minimises stagnation because it helps to quickly identify weaknesses. This allows you to reduce the time of work on the task and improve the quality of the result.
• Visibility of work progress. One of the main advantages of Kanban process management. When all team members have access to the assigned tasks and progress performance, it is easier to identify problems and fix them.

Now that you've seen the benefits of the Kanban methodology, it's time to learn about the downsides of this approach.

• Not suitable for long term planning. The Kanban method is designed to achieve short-term goals. The work is built on the solution of urgent problems, while their priority may vary depending on the circumstances.
• Not suitable for large teams. The more people involved in the work process, the more difficult it is to control the execution of tasks. Therefore, it is best to have no more than ten people in one team, ideally five.

The Rational Unified Process

The Rational Unified Process is a universal methodology for assigning tasks and responsibilities in software development. Its goal is to create high-quality software that meets the needs and demands of users. The RUP methodology was developed by Rational Software Corporation, which was bought by IBM in 2003.

The incredible success of the RUP approach has helped many companies understand the importance of having a well-defined and documented development process.

The RUP methodology is designed for large development projects, so many managers believe that it is not suitable for small tasks that do not require a large amount of resources. But there are many examples where small projects have benefited greatly from the implementation of RUP.

The RUP is based on six main principles:

• Iterative development model - eliminating risks at each stage of the project allows you to better understand the problem and make the necessary changes until an acceptable solution is found;
• Requirements management - RUP describes the process of organising and tracking functional requirements, documentation and selection of optimal solutions (both in the development process and in business);
• Component architecture - system architecture is broken down into components that can be used both in current and future projects;
• Visual Modelling of Software - The RUP development methodology shows how to create a visual model of software in order to understand the structure and behaviour of the architecture and its components;
• Software quality control - in the process of software development, the quality of all team actions is controlled;
• Change control - tracking changes allows you to build a continuous development process. A favourable environment is created in which the team will be protected from changes in the work process.

RUP Benefits

• The RUP methodology allows you to cope with changes in requirements, regardless of whether they come from the client or arise during the work on the project;
• RUP emphasises the need for accurate documentation;
• Requirements integration occurs throughout the development process, and in particular during the build phase.

Disadvantages of RUP

• RUP relies on the ability of experts and professionals to assign actions to specific workers, who are then required to produce planned results in the form of artefacts;
• Integration into the development process can negatively affect other more fundamental activities during the testing phases.

Although the RUP development methodology shows excellent results, especially in the field of software development, it is a rather complex method that is difficult to implement in your project, especially if you have a small team or company.

Conclusion

Choosing between distinct software models is an important phase of product development in software engineering. When working on a project, the models provide you with ways and means to attain your goal, as well as with clear guidance and remedies for challenges.

You should be well-prepared to tackle your project with the top software development methods listed above. And if you decide to entrust your project to a custom software development company, you can be sure you will be on the same page as the team when it comes to discussing the approach to software development.

In case you are looking to get started with an experienced  development partner, consider Bamboo Agile. We are a trusted company that is recognised by many well-known brands in e-Commerce, Education, Telecom, and more. Contact us to book a free consultation and become one step closer to success.