Key Takeaways: Software Development Lifecycle
One-Sentence Summary
Building software professionally requires more than writing code — it requires structured processes for planning, reviewing, testing, documenting, and deploying that turn individual programming skills into reliable, maintainable products.
The SDLC Phases
| Phase | Key Question | Output |
|---|---|---|
| Requirements | What should the software do? | User stories, specifications |
| Design | How should we build it? | Architecture, data models, API design |
| Implementation | Build it. | Working code |
| Testing | Does it work correctly? | Test results, bug reports |
| Deployment | Get it to users. | Released software |
| Maintenance | Keep it running and improving. | Bug fixes, new features, updates |
Waterfall vs. Agile
| Dimension | Waterfall | Agile / Scrum |
|---|---|---|
| Planning | Extensive up-front | Just enough for the next sprint |
| Requirements | Fixed at the start | Evolve continuously |
| Delivery | One big release at the end | Working software every 1-4 weeks |
| User feedback | After deployment | After every sprint |
| Change | Resisted | Welcomed |
| Testing | Phase at the end | Continuous |
| Best for | Stable, regulated domains | Uncertain, evolving products |
Scrum at a Glance
Roles: Product Owner (what to build), Scrum Master (process coach), Development Team (builders)
Ceremonies: - Sprint Planning -> Daily Standup -> Sprint Review -> Sprint Retrospective
Artifacts: Product Backlog, Sprint Backlog, Working Increment
User Story Format
As a [type of user], I want to [do something] so that [reason/benefit].
Acceptance Criteria:
- [ ] Testable condition 1
- [ ] Testable condition 2
- [ ] Testable condition 3
Code Review Checklist
| Area | Key Questions |
|---|---|
| Correctness | Does it do what the story asks? Edge cases handled? |
| Design | Right place? Single responsibility? Unnecessary complexity? |
| Readability | Clear names? Understandable to a stranger? Comments where needed? |
| Testing | Tests for new functionality? Edge cases covered? Existing tests pass? |
| Style | Follows project conventions? Consistent formatting? |
Technical Debt Quadrants
| Prudent | Reckless | |
|---|---|---|
| Deliberate | "We'll ship now and refactor next sprint." | "We don't have time for tests." |
| Inadvertent | "Now we know a better design." | "What's a design pattern?" |
Managing it: Make it visible (track it), allocate time (10-20% per sprint), refactor incrementally (Boy Scout Rule), write tests before refactoring.
Four Levels of Documentation
- Code-level: Docstrings on functions and classes (what + why)
- Module-level: Module docstrings (purpose and scope)
- Project-level: README (installation, usage, testing)
- User-level: Tutorials, guides, reference docs
CI/CD in One Sentence
CI automatically tests every code change; CD automatically deploys code that passes all tests.
TaskFlow Progress
v2.5: Full documentation (README, docstrings), project board (conceptual), v3.0 feature roadmap. This version is about process, not features — the code doesn't change, but the project becomes professionally maintainable.
What's Next
Chapter 27: The road ahead — map CS1 concepts to advanced topics, survey CS subfields, and build your personal learning roadmap.