What are the SDLC Phases?

While the phases of the Software Development Life Cycle (SDLC) were touched on already in the SDLC Overview, here we will go over each phase in a little more detail to give a better sense of purpose for each of the seven phases, plus a final, seldom talked of phase.

</div>

1: Planning

The planning phase is where the development team gets a feel for what kind of project they may be taking on. This planning includes gathering an assessment of the end goal of the application, what kind of hardware will be used, and whether or not the project is feasible to take on with the given resources.

For example, imagine a video game development company wants to create a new title for an expansive open world fantasy title. Their end goal will be to create such a game. For hardware, they may choose to release the game on a PC platform, and even expand their reach out towards game consoles. From here the team can draft up a budget and timeline. This estimation is usually done by the more experienced members who have gained a sense for actual costs of things and time it takes to create them from previous projects. However, when asking themselves if this project is feasible, they might realize that their team might not be large enough to handle developing a game and porting it to consoles. This is where they would have to compromise and either hire another company to help port the game, or do without a console release title.

> Sometimes, a project might not make it past this "filter" of feasibility, and this is okay; it is better to realize a project isn't feasible before it begins rather than when you are well-invested!

2. Requirement Analysis

The requirements of a project are the things that the client or end user would like to see and be able to do with the product. This includes things like being able to send messages on a social media platform, or having an email inbox automatically refresh when a new item is received.

Continuing the game development example, the requirements analysis of an open world fantasy game might look something like this:

Users can navigate a 3D environment freely without constraint.
Players can battle enemies where the winner is the person who brings the opponents health to zero first.
At the end of a battle, the player is awarded experience points that allow them to level up and become stronger.
Enemies may drop items that the player can pick up and use.
Players can visit shops to barter goods.
Players exchange currency with shop owners for items.

> The actual requirements document would be much more exhaustive in practice, however this is a good sample of basic tasks that would define a fantasy video game.

In the creation of the requirements, a team will work closely with clients or focus groups to perform a preliminary testing of ideas to ensure they are producing something that is within the end user's interests.

3. Design

If we view the requirements as what will be implemented in the application, we can then view design as how requirements will be implemented in the application. This phase includes creating diagrams, models, and other documents that outline how the requirements will be implemented, attempting to bridge the gap between the problem and the solution.

As to how these documents will be developed, there are plenty of tools at the disposal of the designers. For example, the development team might use UML diagrams for modeling code and outline system interactions. A database engineer might use entity relationship diagrams (ERDs) to model the interaction of columns and tables in a database.

4. Implementation

Implementation, sometimes referred to as development, is the phase where the plan finally is put to action. So far, all of the work put into the development of the application has happened entirely without an IDE.

Using the documentation from the design phase, the models are translated into actions that a computer understands and is able to carry out in a way that echoes the functionality outlined in the designs.

Beyond just programming, systems engineers might use this phase to build any physical hardware needed to run the application. Suppose the game development studio decided they wanted to introduce a cooperative online function to their game; the systems engineers would use documents from the design phase to implement a server capable of handling user sessions.

5. Testing

Once the features have been designed and implemented, the now usable application enters into testing to ensure that it is usable and properly implements the requirements set out by the client.

It is easy to get sucked into the idea that testing only revolves around ensuring the code functions properly, however the world of software testing and quality assurance runs much deeper; not only is the code tested extensively, the designs are also tested to see if they properly capture the requirements.

During the testing phase, the goal is not to prove the absence of defects, but to find defects; this is an important distinction as the former is often impractical, if not impossible, to achieve.

> Vocabulary: Humans make errors, errors create defects, defects can cause failures in a system. A defect is a fault make by a human error, where a failure is what happens when a defect causes a program to act contrary to the program requirements.

6. Deployment

Once the application has been well-tested and meets the clients requirements, the application is deployed to the client or on a market place if it is not for a single end user.

7. Maintenance

Even though the software has been delivered, sometimes there is more work that needs to be done after the fact. For instance, the client may find a part of the software that does not function properly under certain conditions. In this case, the development team would look into the problem and issue an updated version of the software that fixes this problem. Maintenance can also handle the case where a client might be changing their infrastructure and requires changes on your end to make sure the software functions properly on their new systems.

8. Disposition

Sadly, all good things must come to an end eventually. Disposition is the end of a software system's life cycle, and can occur when a client no longer has a use for the product, or other factors occur where the company cannot continue supporting the software.

This phase requires a plan to break down the software gracefully to ensure a peaceful exit without any unintended after effects, and is a seldom touched on topic of the software development life cycle. However, this phase is often not reached for many years after initial deployment, and is not in the immediate future of most applications.