Applying Process in Software Development: Practical Definition (Part 1)

When talking about process in software engineer, 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).

2. Design
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