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….
[click_to_tweet tweet=”An IT project manager doesn’t have to code but should understand software development. This SDLC tutorial can help. http://bit.ly/1YkAMci” quote=”An IT project manager doesn’t have to code but should understand software development. This SDLC tutorial can help. http://bit.ly/1YkAMci”]
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
- Development (Coding)
- 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 tells you what they want:
• Automated vacation entry system. The system needs the following:
o An easy to use interface that employees can access with a log-in.
o An email notification to the boss to either approve or deny the request.
o A notification to the requestor that the request has been approved or denied.
• Someone in HR downloads 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.
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
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.
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.
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.
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.
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.
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.
I hope that this SDLC Tutorial helped to demystify the software development lifecycle.
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.
And if you found this helpful, you might also like How I Made the Move to IT Project Management With No Technical Experience
Let me know if you have questions or comments.
If there’s more you’d like information on, I’d love to know that, too!