The software development lifecycle
The SDLC is a systematic process for building software that actually meets its requirements, broken into distinct phases:
Planning -> Design -> Development -> Testing -> Deployment -> Maintenance
Working through explicit phases (instead of ad hoc) gives every team member a clear answer to "what should I be doing right now," surfaces problems earlier when they're cheaper to fix, and keeps responsibilities from overlapping or falling through the cracks.
Planning and the SRS
Planning gathers, analyzes, documents, and prioritizes requirements while estimating cost, staffing, and time.
- A Software Requirements Specification (SRS) records everything stakeholders must agree on: scope, assumptions, dependencies, interfaces, and both functional and non-functional requirements.
- A prototype is a small, throwaway mock-up used to validate an idea or clarify a requirement before committing to full implementation — cheap to build, cheap to discard.
Tip: a disagreement about requirements is far cheaper to resolve in the SRS than after code has already been written against the wrong assumption.
Gathering good requirements
- Identify stakeholders — decision makers, end users, admins, engineering, sales, support
- Set goals and objectives — goals are broad and long-term; objectives are the specific, measurable steps that reach them
- Elicit requirements — interviews, surveys, questionnaires
- Document, then analyze — check for consistency, clarity, and completeness
- Prioritize — must-have, highly desired, nice-to-have
Three levels of requirements documentation, from broadest to narrowest: SysRS (the whole system — interfaces, performance, security, acceptance criteria), SRS (the software's behavior), and URS (user stories: who needs what, and why).
Development methodologies and testing
| Model | Style | Strength | Weakness |
|---|---|---|---|
| Waterfall | Sequential | Clear stages, easy to budget | Inflexible to change |
| V-Shape | Sequential | Test plans built up front | Rigid, hard to accommodate new requirements |
| Agile | Iterative | Embraces changing requirements | Harder to budget and scope up front |
Testing verifies the code matches requirements and is free of defects, typically across four layers:
- Unit — one function or component in isolation
- Integration — do the pieces work together?
- System — the whole application, end to end
- Acceptance (UAT) — does it satisfy the actual business need?
Bugs get reported, tracked, fixed, and retested until the release is stable — a loop, not a single step.
Releasing and maintaining software
Software typically ships through three stages of increasing confidence: alpha (a preview for select stakeholders, may still change), beta (broader testing against real requirements), and general availability (stable, for everyone).
After deployment, maintenance handles bug fixes, UI issues, and requirements that only became clear once real users started using the product.
Two kinds of documentation carry a project past its first release:
- System documentation — READMEs, inline comments, architecture and design docs, maintenance guides
- User documentation — guides, manuals, and in-app help
Key idea: documentation isn't a deliverable you write once at the end — it's what lets someone other than you (including future you) safely change the system later.