Foreword
Although the steps below are described sequentially, the Agile methodology foresees that SDLC process iterates over them several times and can switch between the steps when necessary.
Switching between the steps can happen in the scope of the whole project as well on the level of specific modules/features only.
Normally, the steps are performed in the sequence they are listed below but not necessarily. The sequence of the steps is defined and regulated by the technical project manager/architect/team-lead who performs the research and supervision of the project development phases, its business needs and makes decisions accordingly in order to make the software development efficient as possible by combining the efficiency with project requirements defined by the business.
1. Planning
Business prerequisites are acknowledged in this phase.
Meetings with supervisors, partners and customers are held to decide the prerequisites like:
- Who is going to use the software application?
- How is the software application going to be used?
- What information is the software going to process?
These are general inquiries that get replied during the prerequisites acknowledgement stage.
A Requirement Specification document is then created to serve the purpose of guideline for the next phase of the cycle. It usually consists of the following:
- Functional Requirement Specification
- Business Requirement Specification
- Client/Customer Requirement Specification
- User Requirement Specification
- Business Design Document
- Business Document
2. Requirement analysis
Performed by the senior members (systems architects and analysts) of the software development team along with marketing and industry experts. This is the crucial part of the project where the software development team leaders must understand the essence of the software to be developed, the specifics of the business case and the potential positioning of the software being developed against the products of competitors, (assuming they exist in the market).
The outcome of this stage, usually, is the SRS document, which stands for Software Requirements Specification.
At this stage, the identification of the development risks, as well as the quality assurance methodology baseline, is decided upon.
The outcome of the analysis stage is to define the technical solutions which will lead to the success of the project with minimum risk.
3. Design
After the requirements analysis, the leader of the project writes down the decisions that were taken and develops the so-called Software Requirement Specification (SRS) document. The SRS is the reference guide for the software architects to deliver the best possible result for the given software.
The outcome of the work of the software architect(s) is the System Design Specification (SDS). This document sometimes is also called the Design Document Specification (DDS). The best scenario is that the SDS is reviewed by the important stakeholders of the project from different outlooks, such as: risk assessment, product robustness, design modularity, budget and time constraints. The best design model is then discussed and selected for the product.
The design of the software clearly outlines the architectural modules of the product as well as data flow and communication diagrams within the product itself, in addition, it specifies any third-party integration that is relevant to the product.
4. Implementation
At this stage, development of the software on the basis of the previous step takes place. Fundamental features are implemented first while the analysts keep returning back to the requirement and design steps for further requirement gathering and analysis to implement less important features and tweaks in the following iterations.
The complexity of this stage heavily depends on the outcome of the previous two stages. The better the SRS and SDS, the easier it is for the software engineers to develop the required software modules. It is no secret that if the first prototypes/versions of the software are required within a very short timescale, then this can adversely affect the quality of the final software. Quality also depends heavily on the analysis capabilities of each individual taking part in the coding process, as does having a properly prepared SRS and SDS.
The more experience and brain-power the analysts, architects and developers have, the less time and documentation is needed in the design phase.
5. Testing and Integration
Although this stage is called testing, in real life, the situation is that faults found in the software in the testing phase, lead back to the development phase and then back to the testing phase in circles, until the software finally reaches the necessary quality. The testing phase normally consists of two internal phases:
- Automated unit/functional tests
- Acceptance tests performed by a human
6. Maintenance
This is when the software is released to the alpha/beta or stable state and feedback starts to come in. Analysis of the feedback can then lead to second third or fourth iterations of the SDLC which means, the process is continued again with phases 1, 2, 3, 4 and 5, gradually eliminating any issues that have been found in the released software.
The whole software development process can also be planned over several iterations, especially, when it comes to Agile, where the main focus is to release a working product as soon as possible and implement different features later on.
