7 Basic Software Development Life Cycle (SDLC) Methodologies: Which One is Best?

After tons of meetings, follow up emails and numerous phone calls, you finally got the contract signed.

Congratulations!

Out of all the bidders, you are the one who proved capable of delivering the best software solution. You share this information with your team and it’s time to celebrate.

Settling down, you start discussing the project. Leaving nothing to chance, you select only the best of your staff to form the project team. You schedule the kickoff meeting with the client. You list the topics of discussion and you’re ready for take off.

But are you really ready? Have you considered everything you need to check on before you start the project?

You may be surprised to find out that there is one very important thing which many project managers don’t give due attention to.

It comes at the beginning of the project and needs careful focus…

Do you know what it is?

It is the process of choosing the right Software Development Life Cycle methodology.

You have already engaged the client and so are aware of the kind of system or software product he expects you to develop.

As a result, you have a mental picture of the whole process to be followed by your team.

This is a good thing because you have to see the end of the project before embarking on it.

All the same, to make the right choice of an SDLC methodology, you need to slow down a bit.

You obviously know there are several to choose from and have a favorite one you normally use. But don’t just run with it because it works well. You need to find out whether it is the best for your current project. This way, you will avoid facing unnecessary challenges in the course of the project.

For example, you may end up feeling cornered when some stages of the SDLC model you chose start overlapping.

If this was not part of the plan, then it can open the door for some real problems.

Or you may be asked by the client to include a few ‘small’ features into the software. This may happen when the process is past the stage which could accommodate that.

As much as situations are rarely perfect, you should avoid getting into one like these.

The last thing you want from your client is being asked questions like, “How come you cannot do that?” or “Didn’t you promise to deliver?” Since you started on a good note, endeavor to finish on one too.

We will look at the various SDLC methodology types and see their strengths and weaknesses. We will also provide you with a helpful guideline to determine when best to use each one of them.

But before getting into that, let’s first go through the basic processes of a software development life cycle.

WHAT IS SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC) ANYWAY?

This is the process which a software system being developed goes through.

The system itself is intended to be the solution to a problem. As is the case with most solutions, implementation takes place through a process.

For example, when a company wants to expand its warehousing capacity, they have the option of either buying, renting or building a warehouse.

Whichever option they pick, they’ll have to go through a process of planning, surveying and final acquisition. Some of the things to be considered will be warehouse size, distance from the current warehouse and offices, number of new staff required etc.

It is the same thing with software development. The Software Development Life Cycle is the process which guides you through the project from start to finish.

Generally, there are stages involved in all the different methodologies. These stages are the steps of developing and implementing the solution. They are:

Planning

This is the phase where you do a feasibility study to ascertain the need for a new system.

You will examine the Problems customer’s face and then look for possible solutions. An estimation of the resources needed for the new solution will also be necessary. These will usually be in the form of time, costs, personnel and any other factor to be considered.

You will then develop a project plan and present it to the management. It is only after getting the approval that you proceed to the next phase.

Analysis

In this phase, you define the specific problems which the client has. Your team then suggests some solutions and settles on the best. All requirements should be clear to help you understand the client’s needs.

The goal at this stage is to gather information. Various methods may be used including one-on-one interviews, group interviews or questionnaires. Observing people as they work is also a great way of collecting information. This will give you valuable information which may never be given verbally.

The management should verify the requirements given by the end users to ensure they are within the project scope.

Design

In this phase, you describe the functions and features of the proposed solution in detail.

You will use process diagrams, screen layouts and other tools to paint a picture of the solution.

The design will also show how the processes will flow.

As part of the details, you can also use entity relationship diagrams and pseudo-code.

This is to ensure system engineers and developers understand what they are to create.

Development

This is the phase where the system or software product gets created.

In most cases, you would divide the work into units and have teams working on them.

Alternatively, you can assign the units to individual experts according to their skill level. Database developers would handle the database needs, network engineers work on the network requirements while system programmers produce the actual system code.

Testing is part of the development work and the test data is generated for this purpose.

A major challenge in this phase is checking the code for semantic errors. These are the hardest to detect yet can cause great problems if they go unnoticed. For this reason, the test data should have known results for comparison against test results.

The finished system should work as per the design specifications.

Deployment

Once the system has been developed and fully tested, it is implemented for the users to work with.

Depending on the situation, some implementations may require parallel running.

You will therefore have to keep both the old and new systems running for some time. Training the end users happens in this stage. Project ownership is also transferred to the client.

This phase also enables you to get user feedback.

Maintenance

As the client continues using the new system, there will often arise the need to make changes and improvements.

With new requirements, there will be need for additional functionality. Fine tuning the system can also be done for performance purposes. Performing scheduled upgrades can cover security gaps and any other need that arises.

These phases are sometimes broken down further depending on the project type.

For example, you may want to break the development phase into development and testing. You will then carry out the two activities separately.

Deployment can at times have maintenance as part of it in cases where there are rapid changes to the system requirements. This will however keep the project running for longer.

THE 7 BASIC SDLC METHODOLOGIES YOU SHOULD KNOW OF

Having looked at the phases in the process of system development, we will now get into the different methodologies. After that, you will learn how to pick the best for your project.

Waterfall

The waterfall is the classic SDLC methodology which has been used for many years.

Being linear and sequential, it emphasizes on the need for a logical progression of the phases involved.

One phase must be carried out to completion then it’s output used as the input for the next.

Source: softwaretestinghelp.com

A short discussion on what happens at all stages will be in order.

Requirement Analysis

This is the first stage at which the requirements of the new system are collected and analyzed.

There should be enough details so that nothing is missed. As an information gathering stage, it is critical that the end users be engaged properly.

Various ways should be used to ensure every possible need is captured. This is because once a certain stage is complete, you cannot go back to make changes.

Ample time should be set for this stage.

System Design

This stage is all about coming up with the design specification of the system to be created.

The system architecture is created and other aspects selected. Examples of these are the programming language and database to be used. This is done in accordance to the requirements in the first Phase.

The design specification describes how the requirements of the system will be technically fulfilled. Data flow diagrams and other process diagrams are used to show the interactions between the parts of the system.

Implementation

This is the stage of actual system development. The different parts of the system are assigned to individuals or teams to deal with them. Database developers work on the database while system programmers handle the coding work.

Network engineers can also be included for the networking part of the system. Some systems need particular networking capabilities which may call for specific network development.

System Testing

In this phase, the developed system is tested to ensure it solves the problems raised in the requirements stage. Any bugs discovered are fixed to ensure the system works correctly.

Bugs discovered mean that the system has to go back to the implementation stage for coding. If they are major, then this is given priority.

System Deployment

After a rigorous testing phase, you install the system for the users to use. You will train the users and provide them with the necessary user guides. This is also where you hand the system over to the client. You will then reach an agreement on the maintenance and upgrade needs.

System Maintenance

Maintenance is the final stage where you will perform system upgrades as well as bug fixes. New requirements which come up as a result of business growth will also be handled at this stage.

Advantages

• Provides an opportunity to have clarity on the project’s progress. This is because the stages do not overlap. The project can only be in one stage at a particular time. Setting timelines for each stage can also be done.
• Since each stage has very specific deliverables, this model makes it easy to manage the project.
• With its rigidity, the system developers and the client adhere to strict discipline for the project. Focusing on the stages becomes a necessity.
• Adaptable to a changing team due to the extensive documentation done at every stage. The project is rarely dependent on one person. When someone joins the team, they can simply go through the documentation and be able to catch up.

Disadvantages

• It is very difficult to estimate the time and cost of each stage of the process.
• Does not allow for changes to be made once the process is in the testing stage. Only minimal fixes can be done.
• Not suitable for complex projects where requirements keep changing or cannot be known at the beginning.
• The extensive documentation happening at every stage takes a lot of time.
• It is almost impossible to include valuable client feedback once development starts.
• The system is only ready after all the processes are over.
• Major problems can occur at later stages when changes are needed.

V-SHAPED

Similar to the waterfall method, the V-Shaped model is linear and sequential though different.

The difference is in the associated tests for every development stage. These are the tests which will be run after the coding phase to confirm that the requirements at each stage are met.

It is also called the verification and validation model because every phase has a validation test attached to it. The left side of the ‘V’ has the verification phases while the right side has the validation phases. At the bottom is the coding phase.

Below is an illustration of the model.

Source: crackmba.com

The verification phases are used to check that all requirements have been factored into the system. The validation phases on the other hand confirm that the requirements have been met by the developed system.

The stages involved in verification are:

Requirements Analysis

The functional and non-functional requirements are received from the users.

These get documented in detail as per the communication from the customer. All the customer’s requirements should be understood.

From these requirements, the user acceptance test is planned.

Functional Specification

This phase is where the system design is planned for. Hardware, software and network requirements are considered before the actual design is agreed upon.

The testing team comes up with a system test plan for running later after development.

High Level Design

This is where the architecture of the system is designed.

Several technical approaches to the solution are suggested and discussed before reaching an agreement.

A blueprint of the system layout is made. This is what will be used for the next phase. The integration test plan is made at this point.

Detailed Design / Program Specification

Also known as the module design phase, this stage has the system designed in detail.

Care has to be taken when designing the modules for compatibility purposes.

There should be compatibility among the system modules and with external systems. The unit or module test plan is made at this phase.

The coding phase

This is at the bottom of the ‘V’ and all the system designs are implemented at this stage. The best programming language is chosen and used to develop the system in accordance to the previously-defined designs. General coding standards are also adhered to.

The validation phases then begin and follow the below order from the bottom up:

Unit Testing

As the first level of testing and at the lowest level, the actual code is checked for bugs.

The developed system is broken down into smaller units/modules. These are then analyzed to ensure they perform as expected. The unit test that was designed during the program specification phase is used in this stage.

Integration Testing

After the units have passed their tests, they are joined and their functionality is tested as a larger unit. Internal communication between the modules is checked as well as integration between the modules and external systems.

This is the test which was designed during the high level design or architectural phase.

System Testing

This test is done to check whether the system meets all the functional requirements outlined during the functional specification phase. Incompatibility with external systems will mostly be uncovered at this stage.

At this point, the test is done on a complete system ready for deployment.

User Acceptance Testing

This is the test prepared at the beginning of the system’s life cycle.

Since it is based on the user requirements, it is run on the user environment. The user is to confirm that the system meets all his needs. There may be specific incompatibilities discovered at this stage.

The cause may be the other systems running in the user environment. The development team may come up with solutions or suggested workarounds which are acceptable to the customer.

Here is a video showing how the V-Shaped model is used mainly for it’s testing capabilities.

Advantages

• Enables the team to detect errors early in the process
• The close working of the development and testing teams helps increase the project’s success
• Easy to manage the process due to its rigidity
• Its strict flow ensures discipline in the whole process thus offering greater chances of success

Disadvantages

• Inability to adapt to new requirements which may come up in the course of the project
• Not the best for long-term projects
• Tends to focus on the business requirements more than the system development aspects. This may cause the complexities of system development to be overlooked.
• Does not avail a working system until late into the project

PROTOTYPING

This model is mainly focused on providing an approximation of the final system at the initial stages.

It is widely used when fixed requirements are not available. A prototype is built to show how the final product will look and work. With the prototype, there is no full functionality provided.

The prototype is then subjected to tests by the customer to check if all the requirements are met.

If not, more information is gathered. With the additional information, the prototype is updated and availed to the customer for further testing. It is only after the customer gives an approval that the production starts.

The below illustration shows the stages of this SDLC model.

Source: testingexcellence.com

Advantages

• Prototypes make it easy for customers to give feedback as they get a feel of how the system will look
• The prototypes give the developing team an experience of the final product thus improving chances of successful development and implementation
• The prototypes help to clarify user requirements which could otherwise have remained ambiguous
• User involvement makes it better placed to cover all needs. It also increases chances of system acceptance
• Errors are detected and fixed early

Disadvantages

• Scope of the project may expand beyond what was initially expected or planned for
• It can be very time consuming
• If not monitored, too much effort may go into building the prototypes instead of building the actual system
• Users may confuse between the prototype and the final product
• Focus on the prototype may create a distraction from the complete project

SPIRAL

This model uses a sequential approach while working like a prototype.

This way, it delivers a system that is not complete but is under constant review. The biggest differentiating aspect though is that it is focused on risk analysis. It is best suited for projects where risk management is critical.

Below is an illustration of the spiral model.

Source: airbrake.io

The development team starts with a few requirements and goes through the whole process for those particular requirements. The stages are:

Planning Phase

This stage is for requirements gathering, feasibility studies and cost estimation.

Risk Analysis

Analysis of the requirements is done to identify potential risks. A risk mitigation strategy is then created to guide the development process.

Engineering

This is the stage of actual development of the software. Testing is also done and the system is deployed at the user environment.

Evaluation

The customer reviews the software and gives feedback. Risk monitoring is also done at this stage. The risk mitigation strategy is confirmed to have worked well for the project.

Advantages

• Suitable for large projects which are of a critical nature
• Drastically reduces the risks associated with developing big systems
• Software is available at an early stage of the process
• Guarantees customer feedback in the development process
• New functionality can be added at later stages

Disadvantages

• Requires expertise in risk analysis and mitigation
• Unsuitable for smaller projects
• Might turn to be very costly due to required expertise and continuous cycles

The below video shows how this works;

ITERATIVE

The iterative model begins development by building only a part of the software.

Full specifications of requirements are usually not known. The small part of the system developed is reviewed to identify further requirements.

Every successful iteration produces a software build upon which more features are implemented. This continues until the final system is achieved.

The below illustration shows this model’s phases:

Source: airbrake.io

Let’s go through the phases for an understanding of how this model works.

Planning and Requirements

This is the phase of collecting user requirements and expectations.

Analysis and Design

An analysis of the requirements is done and the system is designed. Suggested solutions are discussed then one is picked. A technical representation of this solution is done.

Implementation

The actual development happens by translating the system design into code.

Testing

The developed system is tested for any bugs. If found, they are fixed before deployment in the user environment.

Evaluation

The system build is reviewed to check if it meets the specified requirements. This is also the stage where further requirements, if any, are collected.

After this point, the current build is taken back to the planning phase together with the received feedback. The whole process (iteration) begins again. This cycle continues until the system is complete.

Advantage

• Quick software turnaround enables the customer to give feedback from interacting with it
• Suitable for projects with changing requirements or those not clear from the onset
• Since the software is built in the early stages of the system development, it is easy to detect and fix problems
• Open to valuable customer feedback

Disadvantages

• There might be design issues cropping up in the future since not all requirements were taken into account initially.
• New features being implemented may make the users request for more. The project may thus take longer than expected
• Continuous and necessary customer involvement may be a burden to the client
• Not suitable for small projects

INCREMENTAL

This model focuses on building the whole system in small portions.

It works quite similarly to the iterative model but the difference is that this approach starts with the full knowledge of requirements.

This determines the number of smaller portions of the system to be built. When these portions are finished, they are delivered to the customer as complete modules.

It uses the classical waterfall approach only that it does not build the whole system at once. Commonly confused and at times wrongly taken to be similar to the iterative model, it stands out because of two aspects:

1. All requirements are known at the beginning of the project whereas with iterative, only a few are known. More are discovered as the user interacts with the delivered software build. It is important to understand that a software build is not a complete system but a developed part of the system which is undergoing testing.
2. In the incremental model, the modules delivered are complete standalone parts of the whole project which offer extra functionality. With iterative, the new builds are simply working to adapt to new requirements.

Here is an illustration of this model.

Source: BBC Bitesize

Advantages

• The core part of the system is delivered early as the others follow
• The overall workload is reduced
• Prevents the effects of introducing a new system all at once
• Each release adds extra functionality
• Reduces the chances of new requirements being introduced

Disadvantages

• Requires very good planning and designing
• Needs a complete understanding of the system to be built before design begins
• Might turn out to be more costly than envisioned
• Not suitable for small projects
• Rectifying a problem in one module may require corrections in other modules

AGILE

This method is used to counter the limitations of those which cannot cater for a fast-changing environment.

Projects which use the agile approach always have their requirements changing quickly.

This approach is based on the iterative and incremental processes. It guarantees customer satisfaction through quick deliverable parts of the whole systems. The cycles through which the system is delivered are called sprints.

Technically speaking, the agile model is more of a framework or guideline than a distinct model. Various individual ‘sub-models’ exist to implement this approach. They include extreme programming (XP), Kanban and Scrum.

The agile approach focuses on delivering a working software while ensuring customer collaboration.

Interaction among team members and a quick response to changes is also vital. Here is an illustration of a typical agile software development model.

Advantages

• Quickly delivers working software for the customer’s use
• Faster turnaround times
• Promotes customer feedback
• Easily adapts to changes in requirements
• Issues are detected and fixed quickly

Disadvantages

• Documentation is usually lacking or not having enough details
• Overlapping phases make it difficult to measure project progress
• Difficult to estimate the project cost at the beginning
• There is no enough time for the designing of the system architecture
• The many cycles can distract the team from the overall goal of the project

THE BEST METHODOLOGY TO USE

So, which of the above 7 SDLC methodologies is best?

To help answer this question, you will start by asking some other questions.

These questions will help you understand the situation. Below is a list of some to start you off. You can add to them if need be.

• How big/complex is the project?
• How much expertise does your team have?
• What is the financial strength of the client?
• How much time is the client willing to give the project?
• What technologies are you going to use?
• Are all the requirements known and are they fixed?

The answers to these questions will paint a picture of the situation. The situation will further determine the model to use.

Let’s now look at a list of situations best suited for specific software development models.

When to choose the waterfall model

• When the requirements are clearly known and not prone to change
• The project is small and short-term
• When the project is to follow a strict procedure
• When strong documentation is required
• When you have enough resources and expertise

When to choose the v-shaped model

• When the requirements are known and fixed
• The technology to be used is well known by the team
• The project is short
• When technical resources and expertise are available
• When thorough testing is needed

When to choose the prototyping model

• When constant customer interaction is important
• When there is need for a great user interface
• When building complex systems
• When the requirements are not well known
• When there is no great urgency in delivering the final system

When to choose the spiral model

• When risk evaluation and avoidance is important
• When requirements are not clear
• When the project is big and complex
• When changes are expected
• When the technology to be used is not well known

When to choose the iterative model

• When the project is big
• When the requirements are not clear and prone to changes
• When there is need for proper documentation
• When the technology to be used may not be well known

When to choose the incremental model

• When the project is big
• When the requirements are clear and not subject to change
• When there is need for proper documentation

When to choose the agile model

• There is need for quick feedback
• Requirements are not fully known or understood
• When you have a passionate team or a mentor who will keep the team focused and motivated
• When there is no strong requirement for proper documentation

CONCLUSION

Software development is a process that requires proper collaboration between the developer and client. This is what will ensure the project is successful.

Whichever model you choose, you should be comfortable with it. If working with a team, the members should also be able to work with it.

Developing teams may face fatigue when working on projects which require a fast turnaround or long working hours. It’s therefore important that the time to be used for daily and overall work be well planned for.

With this knowledge, now it’s easy to make a decision for all your software development projects.

Have you faced any challenges in this area? Share with us in the comments.