CXOs' Guide to SDLC: Processes, Models, and Best Practices

Globally, it’s estimated that $3.4Tn would be spent annually by organizations on digital transformation initiatives, with cloud, AI, big data, cybersecurity, and robotics as core transformative technologies. It doesn’t matter which technologies you plan to ride on; Software development is always going to be an integral part of all your digital transformation initiatives. 

By the way, could you guess what’s common between software development, meal preparation, manufacturing a car, building a house, and composing music? 

They all have high-level processes split into different phases to yield a high-quality final product. 

The software development process, aka software development lifecycle (SDLC), is a systematic approach to architect, design, and develop scalable, secure, high-performing, and meaningful digital applications that intended users love to use.

Read this insight to thoroughly understand the software development process from scratch and lead the digital transformation initiatives at your organization.

What Is SDLC?

SDLC is an umbrella term for the series of activities that go into developing a digital application. It encompasses SDLC phases/stages, software development methodologies/models, tools, and standards.

Let’s explore the SDLC processes in detail.

SDLC Phases for Developing a Software Product

The SDLC process adds predictability, consistency, and clarity to a software project. It all starts with ideation and is followed by software requirements analysis, design, development, quality assurance, delivery, documentation, and maintenance. 

Let’s dive into each of these SDLC phases.

1. Requirement Analysis, Effort Estimation, and Functional Specification

The first stage of the SDLC process is about exploring the problem space, i.e., WHAT needs to be developed. It entails eliciting, documenting, and maintaining software project requirements.

Eliciting requirements, aka software requirements gathering through 

• Stakeholder interviews
• Surveys and questionnaires
• User observations
• Brainstorming, role-playing, and prototyping

Requirements need to be exhaustive and should cover:

• Business and customer requirements 
• Architectural and structural requirements 
• Behavioral, functional, and non-functional requirements 
• Software performance requirements 
• Software design requirements

Documenting requirements in a simple and consistent language discreetly mentions:

• User personas (stakeholders)
• Use cases (functionality)
• User stories (software features to perform a functionality)
• Process specifications (resources, frameworks, technologies, strategies) 
• Tangible/measurable goals
• Strengths, weaknesses, challenges, risks and tradeoffs

Maintaining requirements, aka analyzing requirements by refining them iteratively to make it clear, concise, uncluttered, and free from any conflicts. In the first stage of the SDLC process itself, you can do cost, time, effort, and talent estimations. But there’s a funny law about the estimates made at this stage, which is known as Hofstadter’s Law.

“It always takes longer than you expect, even when you take into account Hofstadter's Law.”

Anyway, one of the main deliverables of the requirements analysis stage of the SDLC process is a list of artifacts (independent components that accomplish specific tasks on a user journey).

Example

A trimmed functional requirement for an e-commerce store application development could be:

• A product description page
• Products listing page
• Product booking page
• Cart functionality
• Payments gateway
• Shipping and parcel tracking
• User registration
• Seller registration
• A CRM for sellers

2. Software Architecture, Design Patterns, and Tech Stack

The 2nd stage of the SDLC process is about the solution space, i.e., HOW to develop the software. In simple terms, in the 2nd stage of the software development lifecycle, you design the architectural blueprint of the software that you’re developing. Architectural blueprint, aka software blueprint, is nothing but the simplest form of the complete software architecture, often presented as a flow chart. In addition to the software architecture blueprint, in this stage of the SDLC lifecycle, you also decide on the technology stack that the development team will be using. Together, these comprise what’s called software architecture design.

Software architecture design elaborates on the technical implementation of the individual artifacts and how they are bridged together to function as a holistic application. 

But how do you design a software architecture? It involves three steps— architecture analysis, synthesis, and evolution.

• Architectural analysis: This is to discover and benchmark different technologies and IT infrastructure (on-premise/cloud resources) required to architect the solutions.
• Architectural synthesis: This is an actual architecture blueprint that elaborates on how various technologies and platforms are used to build individual software artifacts and how these artifacts are connected to communicate with each other and function as a whole.
• Architecture evaluation and evolution: This is to evaluate if the software architecture blueprint will fare well on different quality parameters.

Besides, there are some common architectural designs that are referred to as architectural design patterns. But why use an existing architectural design pattern? Why not design your own from scratch? Well, there is no point in reinventing the wheel. But you can always modify a wheel to evolve into something better. This philosophy is applicable to software architectures as well. Some application design problems have already been solved by many, and their solution architecture and practices have become the go-to approach for others who need to solve the same. Such architecture designs are called design patterns or software architecture patterns.

• Client-server: a client (such as a web browser) requests information or services from a server (computing device) over a network.
• Microservices: A software architecture design pattern where a large application is broken down into smaller, independent services that can communicate with each other using APIs (URL requests with certain parameters without human intervention). This is highly popular for building SaaS software in the cloud. A rising trend inspired by microservices is a micro-frontend architecture where the UI components serve as independent components that together build a complex UI.
• Service-oriented: A model where services are designed to perform specific functions and communicate with each other to achieve a larger goal. Sounds like microservices, but the difference is the resources here are shared enterprise-wide for data consistency and governance.
• REST architecture: A model where resources (such as web pages or data) are identified by URLs, and the system uses HTTP methods (such as GET or POST) to interact with them.
• Reactive: Applications built to react to changes in data or events in real-time.
• Layered architecture, i.e., the system is divided into different layers (such as presentation, application, and data storage) to achieve modularity and separation of concerns.
• Monolithic: A software architecture where the entire application is built as a single, self-contained unit. Lastly, the software architecture design should be such that it scores well on the following:
  • Compatibility, i.e., interoperability between different software components
  • Scalability, Modularity, and Extensibility, i.e., software architecture can be scaled easily with new components, and ideally, components should be highly independent of each other so that they can be easily replaced/removed without impacting the remaining architecture.
  • Fault tolerance, i.e., failure of one or more components, shouldn’t disrupt the functionality of the entire application.
  • Maintainability, i.e., bugs can be easily fixed, and components can be easily updated to absorb the evolution of technology/market.
  • Reliability, robustness, and security, i.e., it should perform as expected under specific conditions and must be resilient enough to tolerate mishaps and hostile activities.
  • Usability, reusability, and portability, i.e., the software should be of use to the target audience, the components can be reused in other applications, and also under varying conditions/environments.
  • Performance, i.e., the tasks should be completed within defined time frames, and judiciously use memory and computing resources

3. UI/UX/CX Design

Once you’ve got the software blueprint ready, you need to kick off the 3rd stage of the SDLC process, which is relevant for applications with a graphical user interface (GUI), i.e., software with visual elements with which users can interact to get a task done. Examples could be a simple website, email clients like Gmail, or software like Microsoft Office.

UI/UX design can often be pursued right after the requirement analysis phase. In this stage, you revisit the functional requirements of the application and try to refine the project requirements and scope by working alongside the project stakeholders. Here’s the high-level UI/UX design process:

• The UI/UX design stage of the SDLC process starts with segmenting user personas (attributes that define target customers/users), designing user journey maps (how customers may use the application), and empathy maps (deciphering user emotions during interactions with the software).
• Extensive research is done to assess market competition, better understand the users, and identify potential monopolies/differentiators.
• The next step in the UX design SDLC process is to draw wireframes and then convert them into low-fidelity prototypes.
• It helps in developing user-centric design if designers are empaths by nature and base their design on data.

4. Application Code Development

After UI/UX design is ready for the entire application, or at least for the independent components, it enters into the picture — coders, aka programmers. This is the stage of the SDLC process where actual coding happens, i.e., artifacts are envisioned using algorithms, which are translated into computer code (algorithms -> application source code) using a suitable programming language (decided in the software architecture stage of the SDLC process).

Also, depending on what has been discovered and agreed upon in the requirement analysis and architecture design stages of the SDLC process, different software development models and methodologies can be incorporated to write the application code. Here are some popular software development models—

• Waterfall: It’s a sequential software development process where development shifts to the next stage only when the previous stage is completed. The stages are — Software requirements gathering, drawing models and schema, designing software architecture, coding and integrating software components, testing software, debugging the defects, operations, and maintenance.
• Agile: It’s an iterative software development approach emphasizing flexibility, collaboration, continuous value delivery, and continuous improvement.
• Incremental and iterative: A software development methodology where software is built in small increments and cycles of iterations. In contrast to the waterfall model, users are involved at every stage of software development. This is suited for small-size projects.
• Spiral: A risk-driven software development process that involves iterative cycles and continuous risk assessment. It is not that popular, though it adapts parts of evolutionary prototyping, waterfall, and incremental software development approaches based on the involved risk factors.
• Prototyping: A bare-bone working model of the system is built to gather stakeholder feedback, validate the usability of the product, the efficacy of the architecture design, and refine requirements.

Irrespective of the methodology you chose, your focus must be on yielding high-quality code. The choice of the programming language, the skills and experience of the programmer, and the software development methodology highly influence the developer's productivity. In general, adherence to coding best practices, programming laws, and principles and using developer productivity tools can help in further refining the quality of code and overall outcome of this stage of the SDLC lifecycle. 

By the way, here are some popular programming laws and principles that can be recommended during the architectural documentation and implemented in this (development) phase of the SDLC:

• DWIM: "Do What I Mean," write software in a way that it automatically handles trivial user errors by inferring the user intent and then performing the intended action. A simple example could be removing trailing spaces from email addresses entered in the username input field of a login form component.
• DRY: "Don't Repeat Yourself" is to reduce redundancy by abstracting common functionalities into reusable modules. Example — writing functions (lines of code) that accept dynamic parameters (variable inputs from users or from other software components themselves) to perform a common task. A simple real-life example would be a function that makes the first letter compulsorily uppercase for the passed parameters before storing it in the database. And then, you can pass Name, Surname, City, Country, etcetera to this function.
• Fail fast: An approach to writing code (usually preferred during the development stage), where on encountering an error, it is prompted immediately to the developer, and it seizes all functions of the application. It can be used in transaction-critical applications for security reasons.
• KISS: "Keep It Simple, Stupid" Don’t make things unnecessarily complex.
• Loose coupling: Code application components and artifacts that interact with each other with minimal interdependence, allowing for greater flexibility and easier software maintenance. Suits microservices design patterns.
• Release early, release often: The soul of the DevOps approach, where the software is released frequently in small increments, allowing for faster feedback and iteration.
• YAGNI: "You Ain't Gonna Need It" minimalist approach to functional requirements that advocates not writing lines of code, functions, or components, which would not be compulsory to tick off the functional software requirements and scope of work (SoW).
• Gall’s Law: “A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a simple working system.”

5. Software Testing

The fifth phase of the SDLC process is software testing, which is altogether a complete universe in itself. Software testing is a process to validate and verify that the developed software is free from any error and exhibits the behavior as outlined in the requirements analysis stage of the SDLC process. The engineers who perform software testing are often referred to as quality assurance engineers, aka QA developers or software testers. Software testers work with the development team to ensure that the developed application performs well on different KPIs and metrics:

• Usability metrics (backlog features and ease of use)
• Performance metrics
• Application Security
• Infrastructure resilience and its security

High-Level View of the End-To-End Software Testing Process:

• Testing requirement analysis, i.e., identifying what needs to be tested and for what set of input parameters, the devices for which the test needs to be performed, network conditions, performance expectations, etc.
• Test planning and strategy, i.e., types of software testing that should be performed to accomplish the testing requirements.
• Write test scenarios and test cases (scripts) and gather datasets for performing the tests.
• Test execution, i.e., running of the test scripts on local devices or in the cloud using device emulators.
• Test report generation, i.e., the result of running the test scripts to share with the stakeholders (management, developers, project managers, engineering lead). Lastly, test results are analyzed, the identified defects are delegated to concerned developers for debugging, and extensive report documentation and logs are archived for future reference.

There are a couple of software testing methodologies. Okay, a lot of them. Here are some frequently used software testing approaches, techniques, and methodologies. For brevity, we’re not explaining them in detail.

• Unit testing: To verify the correctness of the programs at the individual class or function level (FYI, class and functions are blocks/lines of code), i.e., atomic components of an artifact are tested.
• Integration testing: To verify that when unit components are integrated, they function accurately.
• System testing: To verify all integrated components function correctly as a whole application.
• Acceptance testing: To verify if the system as a whole is ready to be deployed, i.e., by testing it with real-world conditions, with actual user inputs and use behavior.
• Regression testing: To verify that no new bugs are introduced even after a major update or code change. These are small test scripts to test the integration of new code and to verify that adding new functionality/code does not trigger old errors or application failure cases.
• Functional and non-functional testing: To verify that users can perform features listed in the requirements document (functional) and match the expectations for scalability, accessibility, security, and other non-functional software performance aspects.
• Performance/load testing: To check if the software functions well under specific workload conditions
• Security testing: To test how protected the data is, if unauthorized users can read or modify it, or if external influences (hi, bad hackers) can interrupt the normal functionality of the software.
• Automation testing: Automate all the aforementioned testing activities using software tools like Selenium (for web testing), Appium (for mobile testing), etc.

6. Software Delivery and Deployment

Once the QA team gives a go-ahead signal for the source code of the software (complete or partial), the next stage of the SDLC process is to take the necessary steps to put the application in the hands of the users, i.e., push the code to production.

This is the responsibility of the DevOps team. Here’s a high-level view of the process of delivering and deploying the code in production: 

• Software delivery is packaging all the code (developers call it ‘build’) developed by different developers together with the necessary dependencies that are ready to be deployed.
• Software is often released as alpha, beta, and production versions.
• Software deployment is the actual process of pushing that code out to servers or other environments to be served to the end users.

7. Software Maintenance, Technical Support, and End-Of-Life

What next after pushing the code to production? You have to be on your toes to ensure that the shipped application is available, works as intended, and is secure too. That’s exactly what the final stage of the SDLC process, i.e., software maintenance, is all about. It augments the existing software with new functional enhancements, bug fixes, and performance improvements.

Software maintenance could be:

• Reactive/corrective (fixing bugs)
• Adaptive (updating with market/technology evolution)
• Perfective (performance aspects)
• Preventive (fixing bugs before)

Software maintenance continues until the software reaches its end of life. Thus, the SDLC process also includes migrating platforms without disrupting normal functionality and/or performing the last rites of redundant components/functionalities. For example, Google is finally shutting down its Universal Google Analytics Software and is substituting it with GA4. And they are providing a buffer time for people to easily switch to GA4 to avoid any sort of business interruption/disruption.

Conclusion

Chaos surfaces in the absence of systems, processes, and discipline.  In the end, processes are useless if not executed correctly. So, as mentioned earlier, stick to the software development lifecycle processes and best practices — implementation may vary, but the soul of the SDLC process remains the same for every project/organization.

Also, do tap into emerging trends with tangible or promising ROIs — Design thinking, QA automation, engineering analytics tools, and infrastructure automation tools for enhanced outcomes.