The Software Development Life Cycle (SDLC) is a conceptual framework comprised of steps taken to produce high-quality software. The SDLC is followed by professional organizations that produce software products, and completing its steps involves collaboration between both software developers and stakeholders. On a general level, the SDLC is divided into these phases:
- Planning the basic approach for the project.
- Analyzing the requirements of the software product in terms of functionality and operability.
- Defining the requirements of the software product and documenting them in some way, such as in a Software Requirements Specification (SRS) document or in User Stories.
- Designing the architecture of the software product. The software architecture consists of the informational structure of the software, including the components responsible for different functions as well as the types of data shared between the components. This architecture serves as a sort of blueprint for the programmers and is typically illustrated via diagrams.
- Implementing (that is, coding/programming) the software.
- Testing the software to find glitches and to ensure that it is acceptable to end users.
- Deploying the software so that it can officially be used.
- Maintaining the software after deployment. This includes fixing any issues with the software discovered after its deployment. The team who maintains the software may not be the same team as the one that developed the software.
Different organizations publish different lists of SDLC phases. There are usually five to eight phases. Oftentimes, one phase might be a combination of two or more of the phases listed above. For example, in a five-phase version of the cycle, the first three phases might be a single “Planning and Requirements Analysis” phase, and the last two phases might be a single “Maintenance” phase. All the above activities are completed during software development regardless of the number of phases in an organization’s list. They are typically completed starting from the planning phase and going all the way to the maintenance phase. However, there are many different SDLC models for completing the phases. Two of the most popular ones are Waterfall and Agile.
Waterfall is straightforward but inflexible. This model typically has five phases: Requirements, Design, Implementation, Verification & Validation (same as testing), and Operation & Maintenance. These phases match up with the activities listed above, and requirements are documented in an SRS. The exact number of phases and their names will differ depending on the illustration you are looking at, but the overall concept is universal. Waterfall is linear. Once a phase has been completed, the developers must move on to the next. There is no going back. The only exception is when they reach the Operation & Maintenance phase. At that phase, they can move back to any previous phase, but from there on they can only go forward until they reach the Operation & Maintenance phase again. With Waterfall, the process of developing a software engineering project is modeled after the process of a physical engineering project. Once the foundations are laid and the concrete is poured, there is no going back; one can only move on to the next phase. However, changing the source code of software is significantly easier than changing a building, and the Agile model takes advantage of this.
With Agile, after the deployment phase is done, the developers review what they accomplished. If there are issues that need to be addressed or more features that need to be added, they go back to the analysis phase, then the definition phase, etc., all the way to deployment again. They repeat the cycle as many times as they need until the stakeholders are satisfied. Overall, Agile is an iterative and flexible process. At the end of each iteration, functional software is deployed. Functionality is incrementally added to the software with each iteration. The requirements for software are documented in User Stories, informal notes for how the software should function from a user’s perspective. Sometimes an SRS document will accompany the project, and the User Stories may be based on the requirements established in the document. Note that just like there are different SDLC models, there are also different Agile methodologies. One of the most popular Agile methodologies is Scrum. In Scrum, iterations of work—from analysis, to definition, to design, to implementation, etc.—are done in units of time called sprints. A sprint may be as short as one week or as long as two months. Scrum involves regular meetings, including 15-minute daily scrums, and two meetings at the end of each sprint: the sprint review for the developers to demonstrate the software to stakeholders, and a sprint retrospective to help developers reflect upon what went well for the sprint and discuss how to improve the next sprint.
Although Agile was originally made for software development, it can be applied to other projects in which processes and deliverables may need to undergo continuous change to properly meet the needs of stakeholders. In addition to offering application and platform development services, offers Agile transformation as a service to help improve the processes of your organization.