This SDLC Tutorial explains the Software Development Lifecycle. If you are new to IT, it will help you understand the steps involved in a software development project.
If you want to get into IT and much of it is still a mystery to you, read on….
During a software development project, the team moves through several steps. These can have some overlap, but these phases include the activities that the team goes through to execute a software project. These are the phases of the life cycle.
Here are the six phases that the project team undergoes during a software development project:
- Requirements Gathering
- Design
- Development (Coding)
- Testing
- Deployment
- Maintenance & Support
SDLC Tutorial: Explanations of the six phases of software development
For this SDLC Tutorial, I’m going to use an example. It will help put things in context as we walk through these steps. But first, these qualifiers:
• I’m going to keep this simple.
• I’m going to keep the scope of this SDLC Tutorial narrow, and not get sidelined by many other terms and explanations.
• We’ll assume we don’t have to worry about security or compliance or other such areas.
Our Example: Let’s say you work for a new business that has grown so much that they now need to create a vacation time-off system since there are employees in various locations. Okay – let’s go…
1. Requirements Gathering
During requirements gathering, the business need has been identified and you need to determine what the solution requirements will be. You first look at what the business requirements are. You need to clearly identify what the business needs from this system. You could start with a clearly defined business case explaining the need.
Business Case for our example: The user needs an automated system that will allow employees to enter and manage vacation requests. It must include the ability for the request to be approved or denied. This system needs an intuitive (easy) user interface and email notifications of the request.
Business Case Translation: this means that the interface needs to be simple to use, and if someone puts in a request, the boss gets an email to act on it.
Now that you know what the user wants, it’s time to go get more information.
You would talk with the user who has requested this system about what they want and how the system needs to behave.
Think about the flow of the system and what needs to happen at each point. There are various ways to do this, and drawing up a diagram of the different steps can help you visualize and see what needs to be addressed.
The business will provide the requirements.
The business tells you what they want:
- Create an automated vacation entry system. The system must provide the following:
- An easy to use interface that employees can access with a log-in.
- An email notification to the boss to either approve or deny the request.
- A notification to the requestor that the request has been approved or denied.
- Someone in HR will download a file every two weeks.
These requirements are shared with the technical team, who translates this into technical requirements. These technical requirements tell the developers how the system needs to be built to deliver what is needed by the customer.
Related: Software Project Requirements 101: What You Need to Know To Get You Started
2. Design
During design, the developers and other technical team members look at all the different systems that the information needs to be shared with (HR and email, for example.)
They will look at how the users get information into and out of the system, what information will be used, and where the information is stored.
This is only a part of what needs to be considered, but we’ll leave it at that.
These teams will then make decisions about how the system will be designed and built. They decide on things such as process, data flow, user interfaces, hardware requirements, etc.
Usually, design documents are created at this point that explain how the system will be built. These can be diagrams, flow diagrams, text documents, or other forms of documentation.
3. Development (Coding)
In this stage of the software life cycle, the product is actually built. The developers write the code. As they write the code, they test each piece of code to make sure it behaves as is expected. This is called Unit Testing.
Additionally, database administrators would create the databases needed to store the data being used. In our case, these are things such as employee names and vacation dates requested. Interfaces are built
4. Testing
When the requirements are developed, the test cases are generally written at that time. The test cases are lists of activities that need to be tested based on what the solution is supposed to do.
In our example, test cases might be having a user log into the vacation system, input their information, and submit it. You would break these down into specific steps so that each is tested.
Another test case might be the manager checking to make sure she got the email and attempting to both approve a request and deny a request. Another test would be to log in and retrieve information as HR is suppose to do.
Integration Testing
One type of test that needs to be conducted is the INTEGRATION TEST. The new system is tested along with the other systems it interacts with, to make sure they work together.
User Acceptance Testing
One main type of testing is called USER ACCEPTANCE TESTING. This is where the users actually walk through the test cases and test the system. You want them to make sure it does everything they wanted, and how they want it.
Other Software Tests
There are still other types of tests that can be run, such as stress tests, in which you put a lot of usage on the system to make sure it won’t crash. System testing occurs when everything is put together and tested end-to-end.
It is not uncommon for the testers to find problems as they test. When they do, the developers need to know what needs to be corrected. This is the bug fixing component of testing. Once the bug is fixed – or the problem is corrected – that test case is executed again to make sure it works right.
5. Deployment / Implementation
Once everything has been tested, and the team and the users are happy that everything works as planned, it’s time to let the users have their new solution. This is generally called “moving it into production”.
Sometimes there is a formal sign-off for this. Sometimes there are training documents or user job aids created and provided for the users.
For the “move to production”, a time is identified in which the development team will move the solution to the “Production Environment”. This means moving the software code so that all the users can access it in their real daily work.
The process for this can vary among companies. If the change is large, and the system being changed has many regular users, the “move to production” might be done on a weekend when fewer people are using the system.
The implementation could include more than just the “move to production”. It could involve training users, too. The move to production could be big or small – simple or very involved – depending on your project.
Additionally, if you want to have different areas adopt on different times, you might have a “staged implementation” (or staged roll-out).
In our example, for a staged roll-out”, the development team picks a weekend and moves the changes to the “live” production environment, but does not make them available to everyone at once. On Monday, they make the changes available to the Jackson, TN team, and watch to see how everything goes. Then on the following Monday they make the changes available to the Nashville, TN team. And on the Monday after that they push the changes out to the Memphis team. This is a phased or staged rollout.
6. Maintenance & Support
Once the solution has been moved to production and the users are actually using it, it goes into maintenance and support mode. The users can ask for help or submit information about any problems.
The developers make sure it continues to run smoothly, and a user asks for help if needed. This is usually done by calling a help desk or putting in a support ticket.
If there is a problem to the system, or if the team identifies an improvement they wish to make, they will identify the requirements and the process can start over with the new change to be made. That’s why the SDLC is often seen in a circle.
I’ve laid mine out in distinct sequential steps, but it can start all over if changes to the system are desired or needed.
Summary
Software development may seem like a mystery to some people, but it doesn’t have to be hard to understand. I hope this SDLC Tutorial helped to demystify the process.
If you’d like to know more about software terms, explained in very simple language, you might also be interested in the download available with my post on how I made the move to IT project management.
If you’d like to download the SDLC diagram, scroll to the bottom to get it sent to your inbox.
Waow! Thanks so much for this Leigh – I am new to Project Management. I took an eight year break from IT to look after my kids and now back and trying to get into the workstream. I have just finished an Infrastructure project but looking to go into SD for variety. This post is really very helpful to me.
I also have to do a lot of confidence building and self development. Is there any guide you can give towards getting ready for interviews and portfolios I can take in to interviews to show the work I have done? Thanks again
The Real Person!
Author Leigh Espy acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
I’m so glad you found this helpful!
Regarding confidence-building, you might find this post on Imposter Syndrome helpful: http://projectbliss.net/11-strategies-imposter-syndrome/ It shares insights that may be helpful to you at this point. Also, joining your local PMI chapter and getting back in the “mix of it” may be helpful (depending on your situation).
Regarding getting ready for interviews, I’d say research PM Interview questions and then practice, practice, practice. Not just right before the interview, but weeks in advance. Study the questions and have answers ready. When you think of a great answer, write it down in a notes app or somewhere you can keep all the information together. You’ll likely think of situations or experiences that apply to a question, and not remember it later – for this reason I recommend writing answers as you think of them.
Whenever I interview, I take documentation from past projects to give the interviewers insight to my work. I don’t leave anything for them to keep, due to confidentiality concerns, but I want them see that I am coming prepared and that I have solid experience in creating standard project documentation. I take it organized in a binder and simply set it on the table – making it clear that it’s there and we usually get to it. They can thumb through as we talk.
Don’t forget to be ready with questions of your own for them.
This is a very exciting time for you! I’ve worked with others making the transition to project management. If you want to talk through it, let me know and I’m happy to have a call with you! Just use the “contact me” page or email me. As I’ve shared with others, I really enjoy the topic and helping others succeed in PM.
Best of luck to you!
Thank you so much Leigh – I truly appreciate your suggestions and help. Have a great one!