Exploring the different SDLC stages

What are the main activities in the SDLC? No matter which model you choose to follow to implement your product, there are six different stages that are considered as common stages in most of the existing models. However, depending on the model, those stages can be executed sequentially or in parallel. By executing this series of stages, it is expected that you will be able to avoid typical and costly pitfalls and achieve the following goals:

• Lower costs
• Improved overall quality
• Shortened production time
• Excellent customer satisfaction

Let's explore these stages since understanding them is very important to the solution architect, who will be involved with all of them. On the other hand, knowing those stages is necessary to organize and facilitate the development of the product, as well as to make the entire development process more transparent. We'll understand each of them in the following sections.

Planning and requirement analysis

Since the requirements analysis is the first stage, it is the most important and fundamental stage in SDLC. This stage starts by identifying the client's stakeholders, and then conducting several meetings and workshops to define the expectations and gather the requirements.

This stage is performed by the business analyst, the project manager, and the senior technical members of the team. They conduct meetings and workshops with the client to gather all the functional and non-functional requirements, such as the purpose of building the product, what problems it will solve, how it will improve the efficiency of the work, what it will include in terms of functionalities and services, who the target audience or the end user is, identifying the user journeys, detailed use cases and test cases, hardware requirements, backup strategies, and failover processes.

Planning is the process of creating a detailed but high-level plan for how and when each module or task in the project will be developed. The aim is to identify the tasks and their dependencies, along with the expected output of each task. This should be aligned with the client's expectations, as defined in the requirement analysis.

After this stage, everyone in the team should have a clear view of the scope of the project, including its budget, resources, and deadline, as well as possible risks and quality assurance needs. This will be shared with the client to align them with the execution of the project and to give them better transparency.

Let's take a look at the different techniques and activities that we usually use when executing the requirements analysis phases:

• Use cases: This is an effective technique that is widely used to capture user requirements. It allows us to identify the possible flow of each feature to be implemented in the system, along with how it will interact with the end users. You may be wondering, how many use cases should I write? This might sound difficult at first, but the simple answer to this question is to make sure that you write down as many use cases as possible, to make sure you cover all possible actions and functionalities that should be included in the system.

  The following are the common sections of a use case:

  a. Use Case Name

  b. Summary Description

  c. Actors

  d. Pre-Conditions

  e. Post-Conditions

  f. Level

  g. Stakeholders

• Business Process Modeling Notation (BPMN): This is used globally to create graphs that describe and document a business sequence using symbols and elements. This technique is recommended if you are implementing business automation processes or the product contains business workflows such as approval cycles.

  Here are the basic shapes of BPMN diagrams in Visio:

Figure 1.2: Basic shapes of BPMN diagrams

• Unified Modeling Language (UML): UML is used to create flowcharts and diagrams to visualize and document software components, such as classes and interfaces. UML is a good design practice and a very useful technique for creating object-oriented software; it helps software developers model and communicate any complex architectural software design:

Figure 1.3: Sample class diagram

• Flowchart technique: This is another graphical representation that's used to describe the different steps of a sequential and logical process flow. In the following diagram, we have a sample flowchart for a checkout process. The green box is the starting point for when the user attempts to add items to the checkout cart before settling the payment and receiving confirmation at the end. The red box represents the end of the process; that is, its completion:

Figure 1.4: Sample flowchart diagram

• Data flow diagram (DFD): A diagram is worth a thousand words. You can use a DFD to visually represent the way data flows through a process or service in the system. This diagram is used to identify and describe the input data and how it is moving through the system to reach its storage location and form the output data. Here is a sample DFD diagram describing the flow of the data in a purchase order process:

Figure 1.5: Sample data flow diagram

• Role Activity Diagrams (RAD): This is a role-oriented representation of every possible action in the system. It is used to easily describe and visualize the different roles that are involved in executing each process or service in the system. The following is a sample role activity diagram describing an ATM transaction and showing the steps that are accomplished by each key role:

Figure 1.6: Sample role activity diagram

• Gantt charts: These are used in project management to assist with planning and scheduling projects of all sizes. They provide a visual representation of tasks, their delivery dates, and the order and dependencies of each task.

  This makes the execution plan more simplified and transparent for the client. The following is a sample Gantt chart representing a project plan. The tasks are grouped based on a specific context and linked through the predecessor column, along with the start date and end date:

Figure 1.7: Sample Gantt chart plan

• Gap analysis: This is a technique that helps compare the current actual results of the system with what was expected by the client in the early stages of the project. It helps denote any missing strategic capability or feature in the system. It should also recommend ways you can make improvements that will help the client meet their initial targets. The following is a sample template that can be used to conduct a gap analysis exercise:

Figure 1.8: Sample gap analysis template

• Building prototypes: Building a mock-up, or a Minimum Viable Product (MVP) model, of the product will give the end users an idea of what the final version of the product will look like once all the features have been implemented. Using this technique, you can identify any feasibility challenges that you may face when you actually implement the product.

While performing your analysis, consider grouping the requirements into the following three categories:

• Functional requirements: These represent all the detailed features and functionalities of the system. They are very important for both the development team, to find out what to implement, and the client's stakeholders, to help them align on the final results of the product.
• Operational requirements: These define the scenarios and the performance measures, along with the associated requirements, that are needed for the product to operate properly in accordance with the client's expectations. This includes the following:

  a. Establishing critical and desired user performance

  b. Defining constraints

  c. Establishing the infrastructure needed

  d. Establishing measures of effectiveness

• Technical requirements: These describe the technical part that must be fulfilled to easily and successfully deploy the product and make it functional with good performance, as per the client's expectations. This includes the technology that will be used, the technical architecture, the hardware, third-party integration, testing, and deployment plans.

Here are a couple of things that should be considered during this stage:

• One of the main challenges in the requirements gathering phase is that each member of the client's stakeholders is seeing the product from his/her point of view. For the success of the project, consider listening and capturing all users' perspectives and document them in user stories or use cases. This will help you identify the full picture of what the product will look like and what it will provide as features.
• In the first meeting with the client, try to identify the different stakeholders and discuss the scope of work to make it clear for all parties. After that, you will have to meet with all the stakeholders to collect the detailed requirements. During these workshops, make sure you keep all your discussions within the scope set forth. This is important to keep the requirements aligned with the business needs and to avoid adding functionalities that the product was never expected to provide.

So far, we've explored the different activities and techniques we can use for planning and conducting the requirement analysis workshop, which is essential for the success of the project. In the next section, we will learn how to document requirements.

Defining requirements

The next step after completing the requirements analysis workshop is to document all the information that was gathered in the previous step to define the product requirements. Usually, the output result of this activity is the Software Requirement Specification (SRS) document, which consists of all the detailed requirements to be designed and developed during all the phases of the project, from the beginning to its end, until the desired product is delivered. This SRS becomes the requirements contract that will be used to develop the product. It will address all the business needs of your client.

Once the SRS document has been finalized and reviewed by all the parties involved in this project, make sure you send it back to the key stakeholders, or the representatives of the key stakeholders, to sign it. The purpose of signing the SRS is to agree that the requirements that are presented and defined in the document are clear and reflect the business needs, as discussed in the analysis workshop. This formal commitment, which is expressed by all parties involved, will play a crucial role in the project life cycle to ensure that the project will not struggle from scope creep during its implementation.

Important Note:

In project management, scope creep (or requirement creep) refers to a situation where the client is continuously requesting changes and adding new features to the product, even after project kickoff. As a result, the project's scope will continue to grow, which will affect the delivery time and the final cost of the product. This should not occur and to prevent it, you must make sure that all the business needs (that is, the scope of the project) are very detailed and properly defined, and that the client has officially committed to the scope of work.

A basic outline for an SRS document may look like this:

1. Introduction

   1.1 Purpose

   1.2 Intended Audience

   1.3 Intended Use

   1.4 Scope

   1.5 Definitions and Acronyms

2. Overall Description

   2.1 User Needs

   2.2 Design and Implementation Constraints

   2.3 Assumptions and Dependencies

3. System Features

   3.1 Functional Requirements

4. External Interface Requirements

   4.1 User Interfaces

   4.2 Software Interfaces

   4.3 Hardware Interfaces

5. Non-Functional Requirements

   5.1 Performance Requirements

   5.2 Security Requirements

   5.3 Software Quality Attributes

Feel free to use this outline and modify it as per your needs, but keep in mind that this document should describe the functionality the product needs to fulfill, along with the technical specifications. Therefore, it should be simple, easy to read, and understand by the project stakeholders. In the next section, we are going to learn about the architecture design phase.

Architectural design

How will we build the product? This a crucial question to answer, especially if you're building a complex or large-scale product that will be used by a wide range of users.

To answer this question, we need to start the architectural design phase, which consists of converting the software specifications that were defined and documented in the previous stages into an abstract design specification plan called the architectural design.

The starting point of this phase is to go through the SRS document and understand every single detail in the requirements. This will help you create the best architecture design, which will ensure you deliver a high-quality product. It is the responsibility of the technical team to document their design in a Design Document Specification (DDS) document. The intended audience of this document is the designers, software developers, and QA testers.

The purpose of this document is to present a comprehensive architectural overview and depict all the technical details of the system components. More specifically, it should present the following:

• The system architecture, components, classes, their attributes, and methods
• The database's design, including the definition of the tables and fields, along with the relationships between tables
• The graphical interface design
• Hardware or software environment
• End user environment
• Security requirements
• Performance requirements and capacity limitations

This DDS is reviewed by all the key technical stakeholders. Based on various factors such as design modularity, performance, security, capacity limitations, risks, budget, and time constraints, the best design approach is selected to build the product.

A basic outline for a DDS document may look like this:

1. Introduction

   1.1 Purpose

   1.2 Scope

   1.3 Design Goals

   1.3.1 Maintainability

   1.3.2 Optimized Performance

   1.3.3 Designed Friendly

2. System Overview

   2.1 Algorithms

   2.2 Technologies Used

   2.3 Architecture Diagrams

   2.4 Database Design

3. Design Considerations

   3.1 Assumptions and Dependencies

   3.2 General Constraints

   3.3 Goals and Guidelines

   3.4 Development Methods

4. Architectural Strategies

   4.1 Strategy-1 name or description

   4.2 Strategy-2 name or description

   4.3 ...

5. System Architecture

   5.1 Component-1 name or description

   5.2 Component-2 name or description

   5.3 ...

6. Policies and Tactics

   6.1 Policy/tactic-1 name or description

   6.2 Policy/tactic-2 name or description

   6.3 ...

7. Detailed System Design

   7.1 Module-1 name or description

   7.2 Module-2 name or description

   7.3 ...

8. Traceability
9. Glossary
10. Appendix

You can use this outline to describe your architecture and prepare the DDS document. The more you make it clear and detailed, the more you make it easy for the developers and testers during the implementation and testing phases. Next, we will explore the development phase.

Software development

In this stage of SDLC, the software developers start actually developing the product. The technology that's used and the programming language, including all the technical standards, should be aligned with what was agreed on in the DDS document. Keep in mind that the development activities can be accomplished very smoothly when the design specifications are detailed and organized in a proper manner.

Testing

Did we get what we want? Testing the product is a must before launching it to the end users. This stage starts alongside the development stage, where the developers are responsible for testing what they are developing. At this time, it is just basic testing and not enough to say that the product is ready to go live.

Therefore, an official testing cycle should be conducted once the development activities of a specific module or the entire set of features have been completed. During this phase, several types of testing should be conducted, every single functionality should be tested thoroughly, and the identified defects should be reported to the developers to get them fixed.

The quality assurance team can use the test cases that have been documented in the SRS, or they can refer to the use cases to test the product. It is recommended to run the test cases every time the developers release a new version of the product until it reaches a stable version. This is to make sure all the defects that were reported in the previous cycles have been closed.

Deployment and maintenance

Software developers tend to invest the majority of their time in the design and development activities of the product, which is good. Despite its importance, I have learned from several projects that this is not enough. Setting a strategic plan for deployment and maintenance is a key factor for the success of the product.

The focus at this stage is to make the product available for end users so that they can start using it. To do so, the product should be deployed to the production environment.

First, it is recommended that you deploy the product in a testing or staging environment. This is where the User Acceptance Testing (UAT) activities should be performed. All the issues will be solved and deployed back to this environment. Once the product reaches a stable version that is accepted by the client and meets all the specifications that were approved in the previous phases, the product can be moved to the production environment.

Important Note:

User acceptance testing is the final round of testing. It is performed by the client to verify that every single functionality provided by the software works, and to confirm that all the requirements have been covered. This will ensure that the software behaves exactly as the users expect and that they can easily use it without any errors or crashes occurring. At the end of the UAT, the client should accept the software or request some improvements before moving the software to the production environment.

The maintenance phase starts immediately after the product is fully operational in the production environment and signed off by the client. This is a crucial step from the client's point of view because it ensures that their product continues to perform as designed after its deployment.

Types of maintenance

There are four types of software maintenance:

• Corrective maintenance: This is used mainly to rectify some errors and faults that are observed while the system is in use or to improve the performance of the system.
• Adaptive maintenance: This may be needed when the client requests to run the software on a new environment such as new hardware or a new operating system. Sometimes, clients request to move their products from an on-premises environment to Azure Cloud. Moreover, it can cover integrating the product with third-party software.
• Perfective maintenance: This type of maintenance focuses on implementing new features in the product. These features can be requested by the client to accommodate new business cases, or they can be reported by users who have already started interacting with the product and noticed some missing functionalities that can help facilitate their work and improve the overall experience.
• Preventive maintenance: This is commonly used to detect and correct errors that may cause software failure in the future. It helps reduce the risk of the issues that aren't significant at this moment but may cause serious problems in the future; for example, assuming the clients are expecting to have an increased number of users who will start using their product after 2 months, but this load cannot be accommodated by the current environment's specs. In this case, planning and updating the software environment in advance to serve the load that will be caused by the new users is considered preventive maintenance.

Let's take a look at the following table to understand when and why we should apply these maintenance types:

Figure 1.9: Software maintenance types

In the next section, we are going to explore the difference between software maintenance and warranty.

Maintenance versus warranty

People may get confused about maintenance and warranty. A software warranty is a formal and legal guarantee that the product will perform properly, as per the specifications, for a certain period. It is a promise to fix any errors or malfunctions in the system at no cost during the warranty period.

The maintenance agreement is sold to the client for long-term and ongoing maintenance activities such as upgrades, updates, or product enhancements.

We have just explained the different stages of the SDLC and highlighted the expected output of each stage. In the next section, we are going to provide an overview of the popular SDLC models.

In this section, we explored all the SDLC phases, from planning and requirements analysis to deploying and sign-off. In the next section, we will get to know the most popular SDLC models.