9.2. Phases of SDLC

Each SDLC model may vary slightly in naming and ordering, but the common phases include:

This chunk introduces the main idea that the Software Development Lifecycle (SDLC) includes various phases. While different SDLC models might have unique names or order for these phases, there are commonly accepted phases that are generally recognized in software development.

Think of the phases of the SDLC like a recipe for baking a cake. Different bakers might describe their methods differently, but the basic steps remain the same: gather ingredients, mix, bake, and decorate.

• Goal: Understand what the user needs from the software. • Activities: o Stakeholder interviews o Feasibility studies (technical, operational, economic) o Requirements documentation (SRS: Software Requirement Specification)

The goal of this phase is to fully understand the users' needs. This is accomplished through various activities such as interviewing stakeholders to gather their expectations, conducting feasibility studies to assess the project's viability, and documenting the requirements in a Software Requirement Specification (SRS) document. This document serves as a reference for the development team throughout the project.

Imagine planning a surprise birthday party. You need to gather important details like the birthday person’s favorite foods, guest list, and location. This is akin to requirement gathering in the SDLC, where you discover and document what is necessary for the software project.

• Goal: Translate requirements into a design. • Activities: o High-Level Design (HLD): architecture, modules, data flow. o Low-Level Design (LLD): internal logic, algorithms, interfaces. • Outputs: UML diagrams, ER diagrams, database schemas.

In the system design phase, the focus shifts to taking the gathered requirements and creating a blueprint for the software. High-Level Design (HLD) covers the overall architecture and flow, while Low-Level Design (LLD) dives into more detailed aspects like the internal logic and specifics of how modules interact. The outputs of this phase, such as UML and ER diagrams, help visualize the system’s structure.

This is similar to an architect designing a building based on client requirements. The architect drafts a blueprint (design) that specifies how the building will look and function, just like how software design outlines the software’s architecture and functions.

• Goal: Convert design into source code using a suitable programming language. • Key Practices: o Follow coding standards and guidelines. o Use version control tools (e.g., Git). o Perform unit testing.

This phase is where actual coding begins. Developers take the designs created in the previous stage and start converting them into functional software using programming languages. It is crucial to adhere to coding standards to maintain code quality and readability. Using version control tools, like Git, helps manage changes and collaborate among team members. Additionally, unit testing is performed to ensure that individual components of the software work as intended.

Think of this phase like building a car based on a prototype. You need to follow the design specifications meticulously, ensure all parts fit together properly, and test each component to confirm it functions before moving on.

• Goal: Ensure that the software meets quality standards and works as intended. • Types of Testing: o Unit Testing o Integration Testing o System Testing o Acceptance Testing • Tools: JUnit, Selenium, Postman, etc.

The testing phase is critical for verifying that the developed software meets both functional and non-functional requirements. Various levels of testing are conducted: unit testing checks individual components, integration testing examines how components work together, system testing reviews the complete system, and acceptance testing validates whether the software meets user needs. Tools like JUnit and Selenium help streamline this process.

Imagine quality inspection at a factory where every product is checked for defects. Just as every car must pass specific tests before it can be sold, software must undergo rigorous testing to ensure it operates correctly and meets user expectations.

• Goal: Move the application from development/testing environment to production. • Models: o Big Bang Deployment o Phased Deployment o Continuous Deployment (CI/CD pipelines)

During the deployment phase, the finished software is moved from a controlled development or testing environment to production, where it becomes accessible to users. There are different models of deployment: Big Bang Deployment, where everything goes live at once; Phased Deployment, which introduces portions of the software gradually; and Continuous Deployment, where updates are continuously rolled out via CI/CD pipelines.

Think of launching a new restaurant. In a Big Bang approach, you open all at once to the public. In phased deployment, you could start with a soft launch to a small group before a full opening. Continuous deployment is like a restaurant that frequently updates its menu based on customer feedback and seasonal ingredients, adapting as it operates.

• Goal: Fix issues post-deployment and implement enhancements. • Types of Maintenance: o Corrective (fixing bugs) o Adaptive (changes due to environment/platform) o Perfective (improving performance) o Preventive (future-proofing)

After deployment, maintenance ensures that the software remains effective and up-to-date. This phase addresses any bugs (corrective), makes necessary changes in response to environmental shifts (adaptive), improves performance (perfective), and prepares for future issues (preventive). Proper maintenance is crucial for the long-term viability of the software.

Envision owning a car. Regular maintenance keeps it running smoothly—fixing any immediate issues (corrective), upgrading systems when new tech is available (adaptive), improving fuel efficiency (perfective), and inspecting to prevent future problems (preventive). The same principles apply to software.

--