A Quick and Simple Introduction to Software Development Life Cycle (SDLC) - Why, What, How?

For any fresher who has never worked in a live project, the term SDLC, might seem to prevail only in theory. Now is your time, to acquire an in-depth understanding of this cycle which moulds an authentic and concrete software product.

SDLC, an acronym for Software Development Life Cycle, is a well defined and systematic approach, put into practice for the development of a reliable high quality information system. It’s a methodology that is employed by business analysts which describes the activities carried out at each juncture of the development of software. The end result of a well described and handled SDLC would be a highly dependable software system that leaves the customer ecstatic in terms of its working, completion accomplished well within time and expense estimates, works proficiently and effectively in the prevailing environment and infrastructure, and is easy on the pocket to maintain and economical to enhance.

DIFFERENT PHASES OF SOFTWARE DEVELOPMENT LIFE CYCLE

1. Requirement Collection:

Requirements are statements that point towards what a system ought to perform in order to provide a capability (i.e. utility or benefit) which are generally prepared during the early stages of a project's system development lifecycle (SDLC). 

Requirements have to be defined with accuracy and this is critical to the success of a project since they describe what the users want a system to perform. Bad requirements are direct attributes to a majority of the software defects.  Fixation of an error during the implementation stage is of larger magnitude than doing the same during the analysis stage. Based on the level of details provided, different names are used to requirements documentation like business requirements, user requirements, functional requirements etc. 

2. Design Phase:

Design phase can be divided into two:

• High level design : The complete System Design is given in a High Level Design (HLD) and this includes Functional Architecture and Database Design. All the modules, from the main module to all sub modules are designed in this stage. The flow of the system is hence well understood by the developers.  The Review team, i.e. the testers and the end users (customers) play a vital role. The entry criteria for this is the requirement document, commonly known as the SRS (Software Requirement Specifications).  And HLD, projects standards, the functional design documents, and the database design document forms the exit criteria. In short, High Level Design describes how the program is to be broken down into various modules. 
• Low level design : In the detailed phase, while defining the Low Level Design, the application obtained after the high level design is further broken down into modules and programs. A unit test plan is created for every program. The HLD document created in the previous phase forms the entry criteria for this stage. And the program specification and LLD (unit test plan) will be the exit criteria. If the analysis made is proper and an accurate and precise Low Level Design document is drafted, it makes the developers’ job painless, since the code can be developed directly from LLD. This keeps the debugging and testing efforts also nominal.

3. Coding Phase :

The complete assessment and evaluation of a system is done once the design phase is completed. The next phase – coding phase, aims at translating the design created into a set of programs in some given programming language, so that the design can be implemented in the most efficient manner. This phase affects the subsequent phases, such as testing and maintenance, acutely. While coding, the focus has to be on minimizing testing and maintenance effort. All endeavors while coding should stand for simplicity and lucidity.

4. Test Execution phase :

This phase involves testing of the code written in the coding phase to discern the result of the application developed. The detected defects, if any, are then to be raised. Test execution is the process where the software developed is tested on the basis of test documents. The errors are then reported to the development team.

5. Maintenance phase :

This process comes into picture once the software is installed at the customer’s location. It includes all the activities performed to maintain the system up and running. The main two forms of maintenance activities are :

• Adaptive maintenance

When the system in question is large, elimination of all the faults before delivery is practically close to impossible. The correction of errors as and when they are found are the activities included in adaptive maintenance.

• Corrective Maintenance

When software is installed in a new environment, it often changes what is desired from the system. The close and direct interaction of the users with the software helps them to identify newer and more precise needs which couldn’t be captured during the requirement analysis. Changes are found in output formats and system environment too. This calls for modification of the software and the maintenance activities related to such changes comes under Corrective maintenance.

Maintenance, hence, involves the following:

 - A good knowledge of the existing software

 - Better comprehension of the outcome of the changes

 - Putting the changes to action – both the documents and code

 - Retesting the modified parts and resetting the old portions.

Conclusion:

There could be scenarios when a proper SDLC is not required to be followed. For instance, as far as in-house developers are concerned, they are also a part of the end user group who would be well acquainted with the requirements and criteria that have to be met with. In such circumstances, SDLC is clearly not called for.

A common question could come up at this point of time; similarly can’t all developers do away without the need for such a tedious task of a planned and timed process? The answer can be quite fiddly. I don’t think a customer would be satisfied if there was a delay in the delivery of the product, howsoever bug-free the product was, because that could put them behind their competitors in the market. Neither will a customer be pleased if a bug-filled product was delivered and launched well within the time constraints, since that could impinge on their reputation. There has to be a tactful way to deal with such a situation where there has to be a trade-off between the quality of the product and the development time.

And don’t you think this will require careful planning and a structured environment, where all the requirements are gathered and translated effectively into a user friendly product? Of course it does! Hence, the answer to the question:SDLC.