Yet, the success of delivering the project depends on many factors. It is estimated that each year almost a quarter of all IT projects fail or are put on hold before they are completed. The remaining projects are usually completed late, over budget or with lacking functionality.

More than half of those problems could be prevented by choosing the right software development model and by taking into consideration user involvement/customer value, product requirements, the possibility of software development outsourcing, or specific business needs.

Let’s focus more on the essence of software development models to explain what benefits they offer to the businesses, what are their specifications and limitations and how are they implemented in practice.

Software development life cycle (SDLC) – think before you act

Dynamic evolution of any technology organisation (especially the software development company) requires it to have a structured framework within which the diversity of its processes and guidelines would fit. Such frameworks are traditionally referred to as software development cycles, also known as the models of software development life cycle (SDLC).

In the broadest sense, SDLC means the iterative process of building an information system that includes certain guidelines, software development methodologies and standards. While the concept is traditionally used in computer and information systems sector, it also applies to system/software engineering. In all of these areas, SDLC methodologies are understood as a software development planning and control framework.

The purpose of SDLC is to define the activities and steps involved in developing specific software (i.e., customised software), and to determine its relationship towards other organisational methodologies. The concept is successively used to plan, design, build, and deliver IT systems.

The cycle is a six-phase process:

• Planning phase – collection and analysis of requirements presented by clients, stakeholders and industry experts, confirmed by market research. Based on the comments and data gathered, further actions are planned and a strategy is developed
  
• Analysis phase – defining problems the team may encounter during the development cycle (i.e., the analysis of constraints, goals as functions or recommendations)
  
• Design phase – designing a product based on collected requirements, analysis and consultations (system design)
  
• Implementation phase – building a product, creating the code, prototype development
  
• Integration & Testing phase – software testing and integration with libraries, databases or other programs. Test techniques differ depends on the active phase of the development
  
• Deployment phase – installation of the software in the selected environment (sometimes combined with the maintenance stage)
  
• Maintenance phase – training users of the software, providing documentation and guidance in using the software, solving errors and failures on an ongoing basis

It’s worth mentioning that each team member must follow this procedure to obtain a quality product as well as meet customer’s expectations under the program at a premium cost.

What are the different types of SDLC models?

The software life cycle models could be explained as different philosophies (or views) on the issue of the development lifecycle (or IT lifecycle). Hence, a good deal of SDLC models have been developed to provide a consistent, iterative improvement to the existing software development models – by giving clear, evaluable steps to define and update project parameters and statuses (such as progress, failure or success).

Currently, there are 50+ software lifecycle methodologies recognised. Although they have many functions, they still differ, mainly due to approaches to the application development used by the organisations. Let’s compare the most popular ones.

THE WATERFALL MODEL (the Cascade SDLC model)

One of the most basic (and easiest to explain) software development models is the Waterfall model. As the name implies, it is graphically represented as a cascading set of steps and acts, working as a software development pipeline.

The phases are represented by the independent highly skilled professionals (i.e., tester, developer) who are responsible only for their own ‘component’ of the software system. Hence, as the water in the waterfall can’t go backwards, the team has to move forward – leaving one stage is also entering the next one, without the possibility of returning. Also, if one person (or step) fails, the project may fail as well.

The model has been criticised many times for its rigidity – as it does not allow the software development process to start until clear requirements are identified. Also, the software is only assessed against initial requirements after the design phase is completed. Due to such inflexibility, this SDLC causes a lot of wastage and rework, which is why it is rarely used in modern IT companies.

• For whom
  It is a good solution when the scope of work and requirements are stable and known at the beginning of the project or the client plans to use proven and stable technology. This method works well for managing high-risk activities where analysis and testing phases are constantly needed (i.e., in banking, insurance or healthcare industry).
  
• Main disadvantage
  Lack of customer feedback. Delivery of a working product is at the end of the manufacturing process which may cause the result to differ from what the customer ordered. An attempt to change requests almost always causes a significant increase in the cost of building the software.

THE V-MODEL (Verification and Validation model)

The model V is a safer variation of the SDLC waterfall model, adding some flexibility to it. Thanks to the expansion of the production stages with testing activities, we obtain a quality product that meets the customer’s expectations. Tests are designed to verify and validate the correctness of each stage of the software development life cycle – saving both time and money.

Due to the fact that each of the final stages ends with reviews and inspections related to development and operation, the project is progressing faster and matches the client vision better. This significantly reduces the cost of operating the system. In addition, the result of each production stage is the test plans that after the end of the top-down production cycle (left arm of the V), are carried out bottom-up (the right arm of the V).

• Main disadvantage
  The V model works well with strict requirements set at the start of the software development process – which is rarely possible under the real-life conditions.

Iterative Development

Most modern software development models are based on an iteration, the concept devised to reduce the cascade model’s main drawback: lack of improvement (i.e., user feedback). In the iterative model, the requirements are ordered and divided into smaller subsets.

Each iteration includes all phases of SDLC model, resulting in the creation of a working prototype (i.e. SDLC prototyping) which can be discussed with the client in the terms of fixes, changes and new system requirements on a regular basis. Over time, the prototype develops into the final system, getting closer and closer to what we want to achieve.

This approach allows the team to quickly implement at least some of the required functionalities (i.e., the ones with the highest priority or the highest risk of failure). Thus, the iterative model allows for fast verification of the feasibility of the produced system and the feedback from the customer whether what he needs is what he will receive as a product of the manufacturing process.

INCREMENTAL MODEL

In this model, the functionality of the software is divided into smaller components. Each element is divided into four phases: inception, elaboration, construction and transition. Each of these phases consists of iterations, which are defined in terms of duration but not in terms of functionality. The incremental model is especially useful in situations where customers are unable to precisely define their needs.

SPIRAL MODEL

This model combines the features of the cascade model and the prototyping model, as an attempt to formalise an iterative approach to software development. The main feature of the spiral model is the risk analysis occurring at each iteration. Continuous monitoring of changes enables proper risk assessment.

After each complete iteration, the system is being reviewed. If the project requires further work, then the next iteration should be planned and then the risk analysis of the implementation of the next release should be carried out.

The spiral model can be seen as a cyclically repeated four activities:

In fact, the spiral model is a synergy of all the SDLC approaches mentioned, as it allows the incorporation of several methods within one development project. Teams can switch between SDLC types depending on the risk level of the project. The spiral model is thus an “encapsulated” version of the chosen model based on an ongoing risk analysis.

• For whom
  The technology has been proven effective for projects with high levels of uncertainty and variability in requirements.
  
• Main disadvantage
  The success of the project depends greatly on the risk analysis (serious consequences of errors).

RUP (Rational Unified Process by IBM)

It is an iterative structure of the software development process created by Rational Software Corporation. It is rather a process template than a single process. The intention of the creators was for the organisations of developers and design teams to adjust the structure to their own needs. As a result, RUP contains a hypertext knowledge base with sample artefacts, and detailed descriptions of the different types of activities.

The RUP life cycle is based on an incremental life cycle model software, so there are also four phases: Inception, Elaboration, Construction, and Transition. The construction of the RUP model is based on building blocks, or content elements describing what is to be created, what skills are required and how to – step by step – achieve particular goals.

PRINCE 2 MODEL

PRINCE2 is the most widely accepted project management model in the world, guiding people and organisations from various industries and sectors through the basic elements needed to manage successful projects, regardless of their type and scale. 

Prince2 relies on rigorous planning at the start of a project and keeping the project organised and controlled throughout its lifecycle. What’s interesting, the priority of the team is a working system, not its documentation. Therefore, it is not straightforward to associate Prince 2 with action-driven management as the feature-driven development guarantees quality software and frequent customer interaction.

One of the model’s main rule is to not plan distant things in detail. The entire project is planned in general and only the next stage in detail (principle – phased management). The rest of the rules are:

The Steering Committee is an indispensable element of every PRINCE2 project. It includes the customer (or chairman), the user’s party representative (Primary User), and the supplier or specialist representative (Primary Provider). The task of the Steering Committee is to make decisions necessary for the project manager to solve problems and continue the project. In addition, the Steering Committee receives regular status reports from the Project Manager.

PRINCE2 is a structured project management model. It means that the software development methodology defines several processes that describe all activities undertaken from the beginning to the end of the project. Each process is associated with the responsibility of a specific person.

• For whom
  Despite many common myths, PRINCE2 is not only intended for managing large projects. It is adequate for IT projects in which a specific product is created (i.e., development of a dedicated solution or implementing an existing software) or in ones with several IT suppliers.

Thanks to its standardisation, PRINCE2 also works well in projects that require formalities and detailed documentation (for example the ones financed by the risk management subsidised by the EU).

CRITICAL PATH MODEL

This methodology is a mathematics-based algorithm. In the critical path method, the team follows three steps: define a list of activities, set dependencies between activities, and estimate how long each activity takes. As they go through the preparatory steps, they should be able to see which path is the most efficient one. The critical path method allows the development team to get rid of activities that could delay the project. 

• For whom
  The critical path method is useful for large projects with a specific scope.  
  
• Main disadvantage
  Lack of flexibility.

Agile Methodology

Agile software development is one of the most popular models today, praised for its maximum flexibility. Milestones are short, with a duration of 2–4 weeks (known as “sprints”), allowing the software engineers to view the change process of the applications by comparing them with a previous sprint, then evaluate them along the way.

The agile model continuously delivers a working product and engages the client in the review process, putting an emphasis on every new requirement (setting it as a ‘goal’ for the next sprint). An undeniable advantage is the cyclically determined scope of work, and dynamic adaptation to changes that arise during the production process.

Similar to iterative processes, agile models perform multiple iterations of analysis, design, implementation, and product testing. This methodology is based on the concept of Minimal Viable Product (MVP) whose core is formed by the first pair of successful iterations.

The development team can create software quickly, flexibly adapting it to the inevitable changes (without the element of constant control) – which results in increased customer satisfaction. The methodology is born in the field of software development, but can be used in any industry or enterprise company.

• For whom
  Agile is more suitable for new projects with no clear picture of what the final product should look like. It works wonders in the situations, where the requirements are not fully known or are constantly evolving.
  
• Main disadvantage
  Some decide on incorrect use of the methodology through incomplete understanding, or even worse, selecting only some Agile elements as Agile works best when implemented as a whole.

	AGILE DEVELOPMENT	TRADITIONAL DEVELOPMENT
Documentation	Everything is changing, so it’s no point to write it down (replaced by face to face/ chat communication)	Everything needs to be written down in detail, the documentation contains the essential project details and a description of the project
Management	People-centric: Collaboration and leadership	Process-centric: command and control
Team	Self-organising, Agile, knowledgable, collocated and collaborative	Distributed teams of specialists, plan oriented with adequate skills
Goal	Exploration, Adaptation	Optimisation, Improvement
Development Life Cycle	Iterative (evolutionary-delivery)	Linear (life-cycle model)
Architecture	YAGNI (You ain’t gonna need it) the rule tells to keep things simple and to design and implement only the things that are really needed	Heavyweight architecture for current and future requirements
Success	Running software is the most important measure of progress	Proper documentation is essential to the project success
Testing	Before you write the code snippet, you should write the code test that you are going to write. Daily automated tests	In standard software development, we write code first and then test it. Testing only after the phase is finished.
Customer engagement	Close, everyday cooperation between businessmen and software developers	Client submits the requirement, pay, give feedback on the end of the iteration, and then pick up the software
Changes	Accepting changes in requirements, even in the late stages of development	Need planning

SCRUM MODEL

This is a project management model derived from agile development. Although it was created to manage manufacturing projects’ software, it can also be used by software development teams, or as a general management approach program/project.

Scrum is a process framework containing a set of practices and predefined roles (the Scrum Master, Product Owner, and the Development Team). The team works in a 2-or 4-week period called sprint, the result of which should be the delivery of the next working fragment of the product/code. The set of functionalities to be performed in the sprint comes from the product backlog, which lists the jobs with their priority.

A very important aspect of the Scrum methodology is close, daily cooperation between individuals. Hence, the necessity of regular meetings and collecting feedback is the key element.

Kanban

Kanban is another technique that can be used in any field of business and it visually breaks down a project into tasks. A Kanban board typically has three segments called: To Do, In Progress, and Done, so the team can physically update their statuses and see the work progress.

Kanban facilitates project management and allows the team to identify areas of low performance (weaknesses), thus improve its productivity and workflow efficiency. If you notice that too many tasks are stuck in Progress Mode, this is a clear sign that tasks are taking longer than originally planned.

Extreme Programming (XP)

The Extreme Programming SDLC is based on communication, simplicity, and constant feedback from the client, team, and the system itself (by conducting the unit testing, and acceptance testing on a regular basis). Unlike the waterfall model, XP tries to reduce the cost of changing requirements by introducing many short cycles of development phase, instead of just one. 

According to this methodology, changes are natural and inevitable while working on the project and should always be included in the product definition. Thus, the development process does not have a distinguished phase of planning the project in detail, because each development stage happens dynamically. The goal is to satisfy the user needs by conducting quality control on each software application product version. The model supports simple projects, collaboration between users and programmers as well as frequent verbal communication and feedback.

• For whom
  For small systems, a highly motivated, well-coordinated and experienced development teams, which can work efficiently.
  
• Main disadvantage
  The priority of working code over its documentation often leads to very high costs of future maintenance of the system.

Recognise your client needs

A very important step of each project development is the choice of the proper SDLC methodology. To do it well analyse the project’s specifics and decide on some aspects e.g. if the software development contract allows to change the requirements while ongoing.

It is also worth to consider the following issues:

• Clarity of user requirements (the context). Often, the requirements are not clear or understandable at first or not well documented. The first stage of the project is to discover and understand what motivates the user. This is where good business analysis and prototyping come in handy.
  
• New technology use. In this case, the experience of the team is no longer sufficient. In such cases, it is useful to initially design and test hypotheses, ideally with a hired expert familiar with the technology. Discarded prototypes are perfect for such cases.
  
• Complexity. Complex systems are not suitable for working on the basis of intuition. They require documented analysis and design, testing, as each mistake is very costly. Systems of this type are assumed to have a long-life cycle, thus management requires well-prepared documentation.
  
• Software product that require reliability and constitute a high risk (i.e., in business) for the user, requires well-structured planning and testing processes (bugs entail huge costs).
  
• Sometimes, the critical factor is the limited time to perform (e.g., limited access to resources) or the strictly defined date of product commissioning. In both cases, the project must be very predictable at the planning stage.
  
• Customer evaluation. Is your client willing to provide the team members with feedback? Client needs to be aware that every update translates into another interaction with the project team. Can he/she adjust to the (sometimes unique) working hours of the remote software developers?

Which of the popular software development models will match my project requirements?

Most of the software development projects need a modern approach – they are usually very flexible projects with a rough idea of ​​the final scope, time and budget. Agile, Scrum and XP methodology works best for such projects.

On the other hand, the traditional SDLC eliminates wasted effort but does not allow for creativity. Traditional methodologies such as Waterfall model, Prince2, and the Critical Path Method work best for projects where the final result/release date is clearly defined, and the risk management is an important part of each development phase.

Regardless of whether we are talking about Agile or Waterfall model, remember that no project will be successful if there is no proper customer involvement in each development phase. Keep in mind that the software development life cycle models are more of an instruction manual, not a recipe for success.

If you want to get more practical knowledge on the topic of software development models, or you are facing the dilemma of choosing the most efficient model for your business requirements (or choosing a software development company), contact one of our highly experienced software development experts – and let the Future Processing team prepare a detailed analysis for your case!