Software Development Lifecycle (SDL) is the set of processes that aid in the creation of high-quality software. Formal or defined SDLs are nothing new, they have been around in one form or another since the 1970’s1. If you are a user of software, you probably have some understanding of the aspects that make software high-quality. This includes:
- It does what I expect it to do.
- It performs well.
- It runs reliably.
- It produces expected results.
- Software terminology is that same as the context that it operates in.
But how do these translate into what the software developers, or software engineers can follow? That is where Requirements Engineering comes in, and we look at the software requirement from the software builder’s perspective, these often form the “ilities” of software.
- Usability,
- Maintainability,
- Scalability,
- Availability,
- Extensibility, and
- Portability.
These “ilities” are considered in addition to what the end users need from the system.
Note: For the moment, we are not considering Security, which can be explored in the Secure Software Development Lifecycle (SSDLC), as security is cross cutting and part of all steps of the SDL.
Types of Software Development Projects
In my experience, there are generally three types of software development projects:
- Bootstrapping projects: These are part of greenfield development and explore new areas of the business where the long-term viability of this exploration is unknown. Generally, these need to test and iterate more than they need to be stable and reliable.
- Modernization projects: These involve updating existing software systems to align with contemporary development practices, and these projects have well-founded long-term viability. These need to ensure that the software that is produced is stable and reliable.
- Digitisation projects: These projects usually take an existing manual, or analogue process and turn them into a digital process. These usually have well known processes, and the requirement of the new process is to be more efficient, stable, and reliable. These may be in the form of digitial transformation, evolution, or revolution projects.
All three types have unique requirements from the lifecycle and different needs regarding their process maturity. However, all have the requirement to have a software development lifecycle implelemented.
Why is SDL Required?
If you have used software that, has strange bugs such as:
- Allowing unrestricted input in a text field, leading to unhelpful error messages upon submission.
- The software was designed based on input from a single stakeholder, without considering end-user needs or preferences.
- Users receive no visual feedback when clicking a button, and the system’s response time varies unpredictably.
- Mathematical functions produce illogical results or impossible ranges, causing confusion for users.
- Despite claims of fixes, certain bugs persist, resurface, appear somewhere else, frustrating users.
- Some bugs appear to be random, and end users cannot re-create the conditions that caused the bug to provide a report.
- The software lacks effective user guidance, leading to confusing interactions, flawed design, and distracting elements.
- Navigating the application and entering data results in inconsistent or unreliable outcomes.
- Forms contain unnecessary information requests, and users struggle to differentiate between mandatory, optional, and constrained fields.
I think you get the picture by now. You have come across software that has these sorts of issues, and more. When the software has multiple of these sorts of issues, it becomes even more evident that the SDL does not exist for this piece of software.
A Software Development Lifecycle will never eliminate these issues, but it will greatly reduce them.
The SDL checks the documentation of the requirements, and then evaluates that the implementation has been done to see if the implementation actually meets the requirements. It is is really a communications tool to inform stakeholders. It helps all the stakeholders understand what was agreed upon to be implemented, and how the implementation was tested to successfully get what is desired2.
What is Software Development Lifecycle?
From my experience in organisations that have low maturity for SDL, they typically gather the minimum requirements, jump right to implementation, and then do the most minimal testing on the developer’s machine before shipping it. This can work effectively for trivial applications, bootstrapping, or experimenting. However, this will fall short for long term viability of the system and falls down even more when more than one developer is part of the project. Without a SDL, the developers can end up creating something with poor overal architecture.
The SDL is broken down into 6 or 7 (depending on the specific model), but all encompass the same areas of concern. There are plenty of resources out there to describe these, so let’s look at why these are important to the non-technical stakeholders who will not be the hands-on keyboards. The SDL does not define if you are using a waterfall approach, or any of the agile approaches, in this regard it is a best practice that will work for any specific implemented approach.
1. Requirements Gathering
At this stage, someone on the development team will engage with the primary group of stakeholders to understand the requirements. There are typically three types of requirements that are gathered (some of them are implicit, or assumed by the development team) they fit into the following categories:
- Functional Requirements (FR): These specify what the system should do. They describe the system’s behaviour, features, and interactions. Functional requirements are typically expressed in terms of use cases, scenarios, or user stories. For example, a functional requirement for an e-commerce website might be “Allow users to add products to their shopping cart.”
- Non-functional Requirements (NFR): Unlike functional requirements, NFRs focus on how the system should behave. They address quality attributes and constraints. Common categories of NFRs include:
- Performance: Specifies response times, throughput, and resource usage.
- Security: Defines access controls, encryption, and authentication mechanisms.
- Usability: Describes user interface design, accessibility, and user experience.
- Reliability: Covers availability, fault tolerance, and error handling.
- Scalability: Addresses system growth and capacity.
- Maintainability: Refers to ease of maintenance, code readability, and modularity.
- Portability: Ensures compatibility across different platforms.
- Compliance: Adheres to legal, industry, or organizational standards.
- Cross-Cutting Requirements (CCR): These are concerns that affect multiple parts of the system, often without being neatly encapsulated within any specific module. Cross-cutting requirements can lead to issues like code duplication or significant dependencies between modules. This can sometimes be referred to as Aspects. Examples of cross-cutting concerns include:
- Authentication: The system and tool that is being used for determine the specific user presented.
- Logging: Capturing system events for debugging, auditing, or monitoring purposes.
- Security: Implementing authentication, authorization, and access control.
- Caching: Storing frequently accessed data to improve performance.
- Configuration Management: Handling global settings and environment variables.
- Exception Management: Dealing with errors and exceptions consistently.
- Auditing: Tracking changes or actions within the system.
- Localization: Supporting multiple languages and cultural contexts.
The requirements should have attributed associated with them to inform the level of importance, if there is an order of the requirements, and any order of implementation required.
The point of this stage is to document and agree upon what the system needs to do. Ensuring that the stakeholders, and the development team have the same clear understanding of what the system needs to do. This may include the terminology, jargon, and lexicons to ensure that the everyone is speaking the same language.
FR‘s are typically set by the stakeholders, with input from the development team. These often can be summarised as short paragraphs, or single sentences that follow a set pattern. FR’s can have assumptions made by the development team by what is meant by certain terms, or how important certain things are based on how much stakeholders stress certain requirements.
NFR‘s are typically set by the development team, and confirmed with the stakeholders, or more savvy stakeholders may have some of these set already as SLA’s (Service Level Agreements), SLO’s (Service Level Objectives), SLI (Service Level Indicators), or KPIs (Key Performance Indicators). NFR’s often have assumptions made by the development team that may not align with the stakeholders’ assumptions.
CCR‘s are typically set by senior engineers or developers in the development team to ensure that as little re-work is done on foundational technologies. These are informed by the companies’ strategies, and goals. The CCRs may already have been decided based on other projects or may be informed by the FRs and NFRs.
2. Planning & Analysis
Any non-trivial project needs planning; however, even trivial projects need to have a plan about where the system is going to be deployed, who is responsible for it throughout the lifecycle, and who is involved in the project.
This stage involves determining the scope of the project, identifying the resources needed, and setting a timeline for the project’s completion. The common steps within this stage include:
- Resource Identification: This involves identifying the resources needed for the project, including the software development team, hardware, software tools, and budget. For instance, the team might need a project manager to oversee the project, software developers to write the code, and testers to test the software. They might also need hardware like servers and software tools like integrated development environments (IDEs). This also may be the time that the methods for development (Waterfall, or specific Agile) are determined for this project based on the requirements.
- Timeline Setting: The timeline sets out when each stage of the project should be completed. It helps keep the project on track and ensures that all team members know what they should be working on and when. For example, the timeline might specify that the requirements gathering stage should be completed by the end of the first month, the design stage by the end of the second month, and so on.
- Risk Analysis: Every project comes with risks, and it’s important to identify these risks early on and plan for how to mitigate them. Risks might include things like team members leaving, budget overruns, or technical challenges that are harder to overcome than anticipated.
In essence, the Planning & Analysis stage sets the foundation for the rest of the Software Development Lifecycle. It ensures that everyone involved in the project has a clear understanding of what the project entails and what is expected of them. This stage is crucial for ensuring the project’s success and for preventing misunderstandings and conflicts down the line. It’s like the blueprint for a building – without it, the Design and Implementation processes would be chaotic and disorganized. With it, everyone knows what they need to do and when they need to do it.
3. Design
It can be very tempting to just jump right into the stage right after this instead of spending time doing Design. But the Design stage is where the conceptual work done in the Requirements Gathering stage starts to take a more concrete form. This stage involves creating a detailed plan for how the system will be built and how it will operate. Here’s a closer look at what this stage entails:
- System Architecture: This is a high-level overview of the system’s structure. It outlines the system’s main components and how they interact with each other. For example, in a restaurant reservation app, the system architecture might include components like the user interface, the database, and the server.
- User Interface Design: This involves designing the system’s user interface (UI). The UI is what the user interacts with when they use the system. It needs to be intuitive and user-friendly. For example, the UI design for a restaurant reservation app might include a calendar for selecting the reservation date, a list of available time slots, and a form for entering the user’s contact information. The UI can also be confused with UX (User eXperience) which focuses on the overall flow through the system rather than the specific visual elements.
- Data Design: This involves designing the system’s data. This includes the models that are used in the data, and the various methods to actually store the data, how the data is retrieved, and the trade-offs with the different storage systems. The considerations should not be limited to the use of a SQL database, but also where logs and audit trails would be stored.
- Network Design: This involves planning for how the system will communicate with other systems. This is especially important for systems that need to interact with external services or APIs. For example, an insurance quoting system may need to communicate with the businesses accounting package to issue invoices.
- Error Handling Design: This involves planning for how the system will handle errors. This includes both system errors (like a server crash) and user errors (like entering invalid data). For example, the error handling design for a restaurant reservation app might include features like error messages (to inform the user when something goes wrong) and error logs (to help developers diagnose and fix problems).
The Design stage is where the development team decides “how” the system will fulfill the “what” defined in the Requirements Gathering stage. It’s a crucial stage that sets the direction for the rest of the Software Development Lifecycle. It’s like the blueprint for a house – it shows where everything goes and how everything fits together. Without it, the construction process would be much more difficult and prone to errors. With it, the construction process becomes a matter of following the plan.
4. Implementation
The Implementation stage is where the actual coding happens. The design blueprints are transformed into a working system. This is typically where the clients can start to see the “real progress”:
- Mocks: This is where quick and dirty examples of the final system may be developed. This could be as functional as a prototype, or as nonfunctional as a render from a design package.
- Coding: This is the process of writing the actual code for the system. The development team uses the design documents as a guide and writes code in the chosen programming language.
The Implementation stage is where the system starts to take shape and become a reality. It’s a crucial stage that brings the project to life. It’s like the construction phase of a building – it’s where the blueprint becomes a physical structure that people can use and interact with. Without it, the project would remain just an idea. With it, the project becomes a tangible product that provides value to its users.
5. Testing & Integration
The Testing & Integration stage is where the system is rigorously tested to ensure it meets the requirements and functions as expected. This stage also involves integrating the system with any other systems it needs to interact with. Whilst there are a few steps here that are done exclusively by the development team, there are steps here that are done by the other stakeholders and feedback provided to the development team. Essentially, we are comparing what has been implemented, to what was documented during the requirements gathering.
- Unit Testing: This involves testing each individual component of the system to ensure it works correctly in isolation. For example, a unit test for an e-commerce website might check that the shopping cart correctly updates when a product is added.
- Integration Testing: This involves testing the system as a whole to ensure that the components work correctly together. For example, an integration test for an e-commerce website might check that adding a product to the shopping cart updates the total price correctly.
- System Testing: This involves testing the entire system, including any integrations with external systems. For example, a system test for an e-commerce website might check that the payment processing system correctly charges the customer’s credit card when a purchase is made.
- User Acceptance Testing (UAT): This involves having actual users test the system to ensure it meets their needs and expectations. For example, UAT for an e-commerce website might involve having users try out the website and provide feedback on their experience.
The Testing & Integration stage is where the system is put through its paces to ensure it’s ready for real-world use. It’s a crucial stage that ensures the system is robust, reliable, and user-friendly. It’s like the final inspection for a building – it ensures that everything is in order and ready for use. Without it, the system might have hidden flaws that could cause problems down the line. With it, you can be confident that the system is ready to go.
6. Deployment & Maintenance
The Deployment and Maintenance stage is the final phase of the Software Development Lifecycle, and it’s where the system is finally delivered to the users and then maintained over time. Here’s a closer look at what this stage entails:
Deployment: This is the process of installing the system in its operating environment. This could be a server for a web application, an app store for a mobile app, or a user’s computer for a desktop application. The deployment process includes tasks like setting up the operating environment, installing the system, and configuring any necessary settings.
User Training: Depending on the complexity of the system, users may need training to use it effectively. This could involve creating user manuals, conducting training sessions, or providing online help resources.
System Monitoring: Once the system is deployed, it needs to be monitored to ensure it’s working correctly. This involves tracking system performance, user feedback, and any errors or issues that arise.
Maintenance: Over time, the system will likely need updates and improvements. This could be due to changes in the operating environment, new user requirements, or issues that were not discovered during testing. The maintenance process involves identifying these needs, planning and implementing updates, and deploying the updated system.
Retirement: Eventually, there may come a time when the system is no longer needed, or it’s more cost-effective to replace it with a new system. The retirement process involves planning for the system’s end of life, including data migration, user notification, and system shutdown.
The Deployment and Maintenance stage is where the system is delivered to the users and maintained over its lifetime. It’s a crucial stage that ensures the system continues to meet user needs and operate effectively in its environment. It’s like the building’s opening day and ongoing upkeep – it ensures that the building is ready for use and continues to serve its purpose over time. Without it, the system might not be used effectively, or it could become outdated or unreliable. With it, the system can continue to provide value to its users for years to come.
TL; DR – Why is SDL Required?
The Software Development Lifecycle is required because:3
- It keeps stakeholders upto date on what is happening in the project.
- Identifies, and reduces risk in the project.
- Strucutured approach to development.
- Ability to measure and track goals.