upgrade
upgrade

🎨Design Strategy and Software

Software Development Life Cycle Stages to Know

Study smarter with Fiveable

Get study guides, practice questions, and cheatsheets for all your subjects. Join 500,000+ students with a 96% pass rate.

Get Started

Why This Matters

The Software Development Life Cycle (SDLC) isn't just a checklist developers follow—it's a framework for understanding how complex systems move from idea to reality. You're being tested on your ability to recognize why each stage exists, what problems it solves, and how skipping or poorly executing a stage creates downstream failures. The SDLC demonstrates core principles of iterative design, abstraction, and systematic problem-solving that appear throughout AP coursework.

When you encounter questions about software development, think beyond "what happens when." Focus on the relationships between stages: how requirements shape design, how design constrains implementation, and how testing validates everything that came before. Don't just memorize the stage names—know what concept each stage illustrates and be ready to explain why the order matters.


Planning and Analysis Stages

Before any code gets written, developers must understand what they're building and why. These early stages prevent the most expensive mistakes—building the wrong thing entirely.

Requirements Gathering and Analysis

  • Stakeholder needs drive everything—this stage identifies what users actually want, not what developers assume they want
  • Elicitation techniques like interviews, surveys, and workshops ensure comprehensive coverage of both obvious and hidden requirements
  • Feasibility analysis evaluates whether requirements are technically possible, economically viable, and clearly defined enough to implement

Design

  • Architecture decisions establish the system's blueprint, including data structures, user interfaces, and component relationships
  • Functional and non-functional requirements must both be addressed—the system needs to work (functional) and work well (performance, security, scalability)
  • Design patterns promote reusability and maintainability, applying proven solutions to common problems

Compare: Requirements Gathering vs. Design—both happen before coding, but requirements define what the system should do while design defines how it will do it. If an FRQ asks about project failures, trace back to which of these stages was inadequate.


Building and Validation Stages

These stages transform abstract plans into working software, then verify that what was built matches what was planned. The gap between design and reality is where most bugs are born.

Implementation (Coding)

  • Translation of design into code—developers use programming languages and tools to build what the design specified
  • Coding standards ensure consistency across the codebase, making it easier for teams to collaborate and maintain code later
  • Code reviews catch errors early and spread knowledge across the development team through collaborative examination

Testing

  • Test cases validate requirements—each test should trace back to a specific requirement to ensure nothing is missed
  • Testing levels progress from small to large: unit testing (individual components), integration testing (components working together), UAT (users verify the system meets their needs)
  • Defect tracking documents bugs systematically so they're resolved before release and patterns can be identified

Compare: Implementation vs. Testing—implementation asks "does it run?" while testing asks "does it run correctly?" Strong exam answers recognize that testing isn't just finding bugs; it's verifying that requirements were actually met.


Delivery and Evolution Stages

Software isn't finished when it works—it's finished when users can actually use it, and even then it continues to evolve. Most software spends far more time in maintenance than in initial development.

Deployment

  • Environment configuration prepares production systems to run the software, often requiring different settings than development environments
  • Deployment strategies like phased rollouts reduce risk by releasing to small groups first, while full releases push to everyone simultaneously
  • User training and documentation ensure that technically correct software can actually be used effectively by its intended audience

Maintenance and Support

  • Post-deployment monitoring catches issues that only appear under real-world conditions with real users and data
  • Iterative updates respond to user feedback and changing requirements—software is never truly "done"
  • Ongoing support maintains security, performance, and user satisfaction throughout the software's operational lifetime

Compare: Deployment vs. Maintenance—deployment is a moment (releasing the software), while maintenance is ongoing (keeping it running). Exam questions often test whether students understand that maintenance typically consumes 60-80% of total software costs.


Quick Reference Table

ConceptBest Examples
Understanding user needsRequirements Gathering, UAT (in Testing)
Planning before buildingRequirements Gathering, Design
Abstraction and blueprintsDesign (architecture, patterns)
Translating plans to realityImplementation
Quality assuranceTesting, Code Reviews (in Implementation)
Risk managementPhased Deployment, Feasibility Analysis
Iterative improvementMaintenance, Requirements updates
Documentation importanceAll stages—especially Deployment and Maintenance

Self-Check Questions

  1. Which two SDLC stages are most focused on understanding what should be built rather than how to build it?

  2. A software team released an application that works perfectly but users find it confusing and slow. Which stages likely had inadequate attention, and why?

  3. Compare and contrast unit testing and user acceptance testing—what does each validate, and why are both necessary?

  4. If a company skips the Design stage and moves directly from Requirements to Implementation, what types of problems would you predict? Connect your answer to the concept of abstraction.

  5. An FRQ describes a software project where bugs discovered after deployment cost 10x more to fix than bugs found during development. Which SDLC stages could reduce this cost multiplier, and how?