Software Development Lifecycle (SDLC)

Despite having implemented many systems in the past, I realise that I have not taken time to document and share what I know. This post illustrates the basics of SDLC for those who are new in this space.

What is SDLC?

Software Development Life Cycle (SDLC) is used in software engineering and software projects to describe the process for planning, creating, testing, and deploying an information system. SDLC is important because the process is in place to ensure an application produces high quality software that meets or exceeds customer expectations, and reaches completion within timeline and cost estimates. 

SDLC Phases

The following section describes the key phases in SDLC and their various activities:

Stage 1: Project Planning and Requirement Analysis 

Requirement analysis is the first and most important fundamental stage in the SDLC. Activities in this stage is usually performed by senior members of the team with inputs from the customer, sales department, market surveys, and industrial domain experts. Based on business inputs, the information is then used to plan the project approach, feasibility study, and risk analysis. Feasibility studies can be broken down into economical, operational, and technical requirements. The outcome of this stage is to determine key factors and agreements that will eventually guide the project to be implemented successfully with minimal risks.

Stage 2: Defining Requirements

Once the requirement analysis is done, the next step is to accurately define and document the product requirements and get them approved by the key business users. The Software Requirement Specification document is the deliverable that documents all product requirements that needs to be designed, developed, and tested to eventually deploy.

Stage 3: Designing the Software Product

Based on the Software Requirement Specification document, product architects would come out with multiple design approaches to attain the required outcome. The respective designs and their relationship to each other are documented in the Design Document Specification. For example, in my previous SAP project, we produce RICEFW (Report, Interface, Configuration, Enhancement, Form, Workflow) design documents based on the initial Requirement Specification document. The design documents at this stage is reviewed by key business stakeholders and technical experts, and upon considering design concerns like product robustness, scalability, design modularity, budget and time constraints etc, business users would sign off the design before moving on to the next stage of the SDLC.

Stage 4: Implementing by Building or Developing the Product

This is the stage of the SDLC where the build of the product starts based on the design documents. Developers will build with the chosen programming language and check-in their codes in a common code repository based on coding guidelines defined by their organization.

Stage 5: Testing the Product

The key purpose of this stage is to ensure that the built product functions as per user requirements. Defects are usually identified, tracked, fixed and retested till it reaches the expected quality defined by key users in their Software Requirement documents.

Stage 6: Deployment to Market and Maintenance

Once the product is tested and ready to be deployed, it is released formally to the required business users. There are various deployment methods (i.e. Big Bang, Parallel etc.) that can be explored depending on the complexity of the new system. Once deployed, the system moves on to the maintenance phase to serve customer needs until key business users decides to upgrade or change the system by retriggering stage 1 of the SDLC again.

SDLC Models

As it costs a lot more to fix an issue at a later stage of a project than at the beginning, the best practice to ensure that most issues are found and resolved as early as possible. With this in mind, different models of SDLC were created and deployed accordingly depending on business needs. These are some common models used by the industry currently:

• Waterfall - A linear, sequential SDLC from stage 1 to 6 to implement a system.

• Iterative - A simple implementation of the software requirements is first done, then the SDLC repeats with enhancements to complete the full functionality.

• Incremental - A simple implementation of a subset of the software requirements is first done, then the SDLC repeats with incremental functional capabilities until the full functionality is eventually completed.

• Prototype - This is more useful for software development that has high user interactions like online systems. A prototype is first developed for business users to give the eventual look and feel before the actual application is developed.

• RAD (Rapid Application Development) - This is based on prototyping and iterative development with no specific planning involved so as to rapidly create a working model with functionality equivalent to a component of the product. The aim is for this prototype to be eventually reused for the final product.

• Spiral - This model is a risk driven model. Four activities (Planning, Risk Analysis, Engineering, and Evaluation) is repeated in loops until the completion of the project. Proper project management must be in place to prevent going on an infinite loop.

• V-Model (Verification and Validation model) - The V-Model ensures that various level of testing is done according to the corresponding requirements. For example, Unit Test is done based on module design, Product Test is done based on Design documents, User Acceptance Test based on Software Requirement documents etc.

• Big Bang Model - This is the SDLC without process. There is little planning involved and requirements are implemented on the fly without much analysis. This model works only for very small projects where the development teams are very small.

After Thoughts

To make this article more complete, we could further compare the pros and cons of each SDLC model. In the past, as I implemented huge ERP systems with well-defined functionalities, the Waterfall approach works well because system requirements are mostly standard features out of the box, with a few additional customised extensions. The complexity comes during the process where we had to manage change among stakeholders, and having clear well-defined milestones makes it easier to account for different people in the organisation. However, in recent years, as I journey towards creating innovative technology products that attempts to quickly iterate to solve customer's pain points, I use a lot more Agile methodologies in my current projects. This works better especially for projects that venture into the blue ocean, as it allows the flexibility to quickly learn and continuously improve our product offerings to quickly meet and serve market demands.

That's all I have to share for today, let me know in the comment section if this is useful for you, and if there's anything that you would like to know more. Cheers!

References

• Mona Lisa Images -- https://watirmelon.blog/2015/02/02/iterative-vs-incremental-software-development/ 

• Spiral Model Image - https://melsatar.wordpress.com/2012/03/15/software-development-life-cycle-models-and-methodologies/

• V-Model Image -- https://tfortesting.files.wordpress.com/2012/10/vmodel.png