Skip to main content

Software Development Life Cycle (SDLC)

There is no single universal "official documentation" for SDLC, the software development lifecycle, because it is a concept, not a product.

Think of it as three different layers of the same subject:

  • Layer 1: The Fundamental Concept

    • SDLC (Software Development Life Cycle): This is the universal and generic concept that all software has a lifecycle: it is born from an idea, is planned, designed, built, tested, and maintained. It's the mother idea. It doesn't say how to do it, only that these phases exist.

  • Layer 2: The Methodology (The Working Approach)

    • This is where you choose HOW your team will go through the SDLC phases. It's your work philosophy. Most of the time it will be some Agile methodology (like Scrum or Kanban), but it all depends on the type of software we want to develop. When requirements cannot change we can use the waterfall methodology.
    • You do all SDLC phases using these methodologies.
    • This is the layer that most impacts the development team's day-to-day. It's the process engine.

  • Layer 3: The Framework or Standard (The Detailed Blueprint):

    • Here are the "manuals" or "rule sets" that define WHICH specific activities, artifacts, and controls must exist in your process, regardless of the methodology.

There are international standards and frameworks published by renowned organizations that are considered the closest to "official" documentation you can find. They establish guidelines and best practices that are adopted globally. In fact, it all depends on the requirements the development team needs to have.

Here are the most important and recognized documentations that serve as the standard for SDLC:

  1. International Standards (Closest to "Official") ISO/IEC/IEEE 12207: Systems and software engineering — Software life cycle processes

    • This is the main international standard for software lifecycle processes. It was developed by ISO (International Organization for Standardization), IEC (International Electrotechnical Commission), and IEEE (Institute of Electrical and Electronics Engineers).
    • It is a formal standard, recognized worldwide, that defines a common framework for any organization to develop, acquire, and maintain software. It details all necessary activities and tasks.
    • ISO documentation is generally paid and can be acquired through the official ISO website or national resellers.
    • It is most important in:
      • Government and Public Sector: In tenders for software development or acquisition, it is very common for bids to require that the supplier company follow the processes described in ISO 12207 (or its Brazilian version, ABNT NBR ISO/IEC 12207). This serves as a guarantee that public money is being invested in a project with a minimum of organization, documentation, and quality.
      • Highly Regulated Industries: In sectors where software failure can have serious consequences (risk of life, enormous financial losses), adherence to rigorous standards is mandatory.
        • Aerospace and Defense: Companies like Embraer and armed forces suppliers need a very high level of traceability and security.
        • Medical: Software for medical equipment (such as a tomograph or infusion pump) needs to be approved by regulatory agencies (such as ANVISA), which require proof of a robust development process.
        • Automotive and Railway: Software that controls a car's brakes or a train's signaling system needs to be extremely reliable.
        • Banking and Financial: To ensure transaction security and compliance with Central Bank regulations.
      • Large International Contracts and Outsourcing: When a large company (e.g., a multinational) contracts another to develop software, it generally requires conformance to ISO 12207 in the contract. This ensures both parties "speak the same language" in terms of processes, deliveries, and documentation.
    • Less used in:
      • Startups and Small/Medium Enterprises: The main focus is delivery speed and rapid market adaptation. The formality and bureaucracy associated with full implementation of an ISO standard can be seen as an obstacle. They follow processes, but in a much lighter and more flexible way.
      • "Pure" Agile and DevOps Teams: Methodologies like Scrum and Kanban already provide a process framework. A team that does its daily meetings, sprints, and has a well-defined product backlog is, in practice, fulfilling the spirit of many ISO 12207 processes (having requirements, developing, testing, delivering), but in a much more dynamic way and less focused on heavy documentation.

    It is a mistake to think that ISO 12207 and Agile development are enemies. The standard describes "what" needs to be done (the processes that must exist), but does not prescribe "how" they should be implemented. The requirements analysis process can be implemented through User Stories in a backlog and the testing process can be automated with pipelines.

  2. Governmental Standards (Highly Influential)

    • NIST SP 800-218: Secure Software Development Framework (SSDF)
      • Published by NIST (National Institute of Standards and Technology of the USA), this document defines a set of secure software development practices. It does not dictate a specific SDLC model, but describes security practices that should be integrated into each phase of any model you use (Agile, DevOps, etc.).
      • It is a US governmental standard and, due to NIST's influence in the technology and cybersecurity industry, it has become a global reference for creating a "Secure SDLC" (SSDLC).
      • Where to find: It is free and publicly available on the NIST website.

  3. Industry Frameworks (De Facto Standards)

    • Although not "official" in the sense of an international standardization body, the following frameworks are so influential that they have become de facto standards in the industry:
      • Microsoft Security Development Lifecycle (SDL)
      • It is the methodology that Microsoft created and implements to ensure that its software is secure from the start. The Microsoft SDL was one of the first and most complete efforts to formalize a secure development lifecycle.
      • Due to success and comprehensiveness, it has become a model for many other companies to create their own application security programs.
      • Microsoft makes all documentation, tools, and practices available for free. You can find everything on the official Microsoft SDL website.

  4. OWASP Software Assurance Maturity Model (SAMM)

    • OWASP SAMM is a framework to help organizations formulate and implement a software security strategy, tailored to their specific risks.
    • It is maintained by OWASP, the leading non-profit foundation focused on software security, and is widely adopted as a practical guide to mature SDLC practices.
    • It is free and open source, available on the OWASP SAMM website. Link to the PDF
    • OWASP SAMM is not a process for building software, but rather a guide to adding security practices to the process.

Regardless of the methodology, the conceptual stages of SDLC are the same. The big difference is how you execute them: all at once (Waterfall) or in small repetitive cycles (Agile). Let's detail each of the classic SDLC stages:

  1. Planning and Requirements Analysis

    Question it answers: What are we going to build and why?

    This is the foundation phase. The goal is to understand the business problem and define what the software needs to do to solve it. Mistakes here are the most expensive to fix later.

    Main Activities:

    • Feasibility analysis (technical, economic, operational).
    • Interviews with stakeholders (customers, users, managers) to collect needs.
    • Definition of project scope (what's in and what's out).
    • Documentation of functional requirements (what the system should do, e.g., "the user must be able to register with email and password") and non-functional (how the system should be, e.g., "the login page must load in less than 2 seconds").

    Main Stakeholders: Product Managers, Business Analysts, stakeholders.

    Main Result: A requirements specification document (SRS - Software Requirements Specification) or, in an Agile world, a prioritized Product Backlog with the first User Stories.

  2. Design (Project and Architecture)

    Question it answers: How are we going to build this?

    With requirements in hand, the technical team translates the "what" to the "how". This is where the software's skeleton and blueprint are created.

    Main Activities:

    • Architecture Design: Define the system's general structure (e.g., microservices vs. monolith), technologies (programming language, database, cloud), and how components will communicate.
    • Interface Design (UI/UX): Create wireframes (basic sketches) and mockups (visual prototypes) of how screens and user experience will be.
    • Data Design: Model the database structure (tables, relationships).

    Main Stakeholders: Software Architects, UI/UX Designers, Senior Developers (Tech Leads).

    Main Result: Technical design documents, architecture diagrams, visual prototypes.

  3. Development (Implementation or Coding)

    Question it answers: Let's build!

    This is the phase where ideas and projects become functional software. Developers write the code, following the specifications from the design phase.

    Main Activities:

    • Write source code in chosen languages.
    • Create and manage the database.
    • Write unit tests to verify small parts of the code.
    • Manage code in a version control system (like Git).

    Main Stakeholders: Developers (Front-end, Back-end, Full-stack).

    Main Result: Software source code, functional components.

  4. Testing (Verification and Validation)

    Question it answers: Does this work correctly and meet requirements?

    The built software is rigorously inspected to find and fix defects before it reaches the end user.

    Main Activities:

    • Integration Tests: Verify if different system components talk to each other correctly.
    • System Tests: Test the complete software end-to-end to ensure it meets all requirements.
    • Security and Performance Tests: Look for vulnerabilities and performance bottlenecks.
    • User Acceptance Testing (UAT): Present the software to stakeholders or a user group so they can validate if it meets their needs.

    Main Stakeholders: QA (Quality Assurance) Engineers, Developers, Stakeholders (for UAT).

    Main Result: A stable and quality-validated software, bug reports and a "green light" for deployment.

  5. Deployment

    Question it answers: How do we make this available to users?

    The software, now tested and approved, is released to the production environment so end users can access it.

    Main Activities:

    • Prepare the production environment (servers, cloud).
    • Migrate code and data to the final environment.
    • Perform final checks to ensure everything went up correctly. In DevOps, this stage is highly automated (CI/CD).

    Main Stakeholders: DevOps Engineers, Infrastructure Engineers (Ops), SREs.

    Main Result: Software running in production and accessible to users.

  6. Maintenance and Operation

    Question it answers: How do we keep this working well and improve over time?

    This is the longest phase of the lifecycle. The software is in use and needs continuous support and evolution.

    Main Activities:

    • Monitoring system health (performance, errors, security).
    • Fixing bugs discovered by users.
    • Technical support.
    • Planning and developing new versions with improvements and new functionalities, starting the cycle again.

    Main Stakeholders: Operations (Ops) teams, Support, Developers.

    Main Result: A stable, updated software that continues to deliver value.

    Remember: in the Waterfall model, you go through these 6 stages once, in sequence. In the Agile model, your team goes through a "micro" version of all these 6 stages within each 2 to 4-week cycle (Sprint).