SDLC in practice: practical definition (Part 1)
When talking about process in software development, the first word that comes into your mind is SDLC (Software Development Life Cycle). If you ask any software engineer about this acronym he would quickly describe it to you and most probably list all of its phases because simply it is a mandatory course in any university and all you have to do is just memorize the phases in order to pass it.
I choose to start my series of articles through talking about process because i believe that it is the key factor of success for any software company and most importantly because i believe that most software developers don’t even know how SDLC is practically applied.
In this article we’re not going to give logical definitions for each phase and the several implementation models, however we’re going to describe in details the practical process of each phase starting from signing a deal with a new client until launching the system live, the same would happen when maintaining an existing system for an old client.
SDLC in practice
After several meetings between the sales department and the stakeholders, the client finally gets excited about the project and starts imagining how simple his life will be after buying it, so here it comes the new deal and the typical development cycle begins.
1. Requirements gathering & analysis
After signing the deal, a project manager (PM) is assigned to the new project in order to interact directly with the client and discuss with them the expected behavior of the system. The client list all their requirements, the expected functionalities, input/output of the system and the type of users who will be using the system, the PM in turns gathers their requirements and discusses them with the responsible team leader who will be leading the design and development phases.
The team leader and the PM start analyzing every requested feature from technical and business perspective until they end up approving the feasible ones and providing the best practices and business alternative solutions to the unfeasible ones. The filtering of the features normally happen due to several factors: lacking resources, time estimations, technical feasibility and financial stuff.
At the end of this phase, the client and the PM should have both decided what are the required features in the new system in addition to the implementation methodology (Agile, waterfall … ) though most software companies go for Agile nowadays. Finally they write all the requirements in a document called FSD (functional specification document).
At this stage, it is clear what development platform will be used for implementing the system, this is decided in the first phase based on the client’s budget and resources (OS, memory, storage … etc). During this stage, the team leader builds a team of developers and starts splitting the requirements into smaller modules and tasks so that he assigns them to his team.
When the developer receives a task , he should do the following:
- Files a new record in the company’s tracking system in order to keep track of the status of the task and for future reference.
- Starts analyzing every single point in the task so that he returns back to his leader when facing any unclear scenario.
- When everything becomes clear for him, he starts thinking of the solution design which defines all the components that needs to be developed,the communication between components, the required third party libraries, the database communications as well as the front-end representations and behavior of each component.
The solution design should be perfect enough to match the best design principles, keeping in mind that every single component is going to be maintained later on in the future.
Based on the size of the task, the design is either written in a well-formatted design document or in an email and sent to the leader for review, companies mostly prefer that the architectural designs be written in a well-formatted design document because it will be a reference anytime a big enhancement arrives at the system.
The leader in turns should be aware of the business and should be able to predict if developer’s solution would affect their product in the future based on his understanding of the business, and also he should be professional enough to suggest better technical or architectural solution if the developer doesn’t propose the perfect one.
If the requirements are too much and there are a lot of tasks, then obviously the team leader would not be able to handle assigning tasks to all developers and reviewing their solutions at the same time, so normally the team leader assigns multiple sub leaders to handle the solution reviews and task assignment and he only manages them from the top and handles the communication with the PM and the client.
At the end of this phase, all solution designs of the project are reviewed and approved and most importantly documented for later usages.
This is the most important phase in the development cycle , since a good architecture would make the system live longer and be ready for future maintenance.
Now that the developer has the approved solution design in his hands , so all he has to do is to start coding using the convenient development tools and the best coding conventions.
After finishing the implementation, the developer should write unit tests which cover his code and validates the business scenario of his task , in addition to that he is also asked to run manual tests on the basic scenarios before sending the code for review to his leader.
The leader reviews the code and makes sure that it matches the company’s coding conventions and best practices. He would add his comments (if any) and ask the developer to submit the code to the version control system (the system which stores the history and the versions of the source code).
Every implemented task should be submitted to the QA team who ensures that the business scenario behind the task is perfectly covered.
The assigned QA engineer should execute the test cases and scenarios related to the task and ensures that all scenarios pass successfully, The QA engineer would do 3 different tests:
- Functional test: make sure that there are no functional bugs in the task being delivered.
- Integration test: make sure that the new scenario integrates well with other modules and the whole workflow works perfectly.
- Regression test: make sure that the task doesn’t corrupt or affect old functional scenarios.
The testing could be done either manually or dynamically through testing automation tools.
After finalizing all the tasks, the system is now tested well, packaged and ready to be deployed at the client’s servers. The release is first deployed on the test server and tested well by the support engineers to make sure that all business needs are reflected.
After that, UAT (user acceptance testing) sessions are done between support engineers , PM and the client’s users in order to get the end user acceptance before publishing, in this phase several training could be done to the end users in order to make them familiar with the system.
After publishing the system, normally bugs would still appear and change requests would also rise, hence the above development cycle starts again until the client believes that the system is stable enough and exactly matches their needs (Although client requests would never end ).
Finally, process is very important in software engineering and most big companies tend to apply it strictly in their development due to its importance in organizing the work and building a successful product. Please refer to “SDLC in practice: live impacts“ if you are interested to know more about the advantages of process and the negative impacts of neglecting it, in the second part i elaborate the basic problems which companies face when they choose to not apply process.