Quiz: Software Development Lifecycle

Test your understanding before moving on. Target: 70% or higher to proceed confidently.

Section 1: Multiple Choice (1 point each)

1. Which of the following is the correct order of phases in the traditional SDLC?

  • A) Design, Requirements, Implementation, Deployment, Testing, Maintenance
  • B) Requirements, Design, Implementation, Testing, Deployment, Maintenance
  • C) Requirements, Implementation, Design, Testing, Maintenance, Deployment
  • D) Design, Implementation, Testing, Requirements, Deployment, Maintenance
Answer **B)** Requirements, Design, Implementation, Testing, Deployment, Maintenance. *Why B:* This is the standard sequential order — you determine what to build, then design how, then build it, then test it, then deploy it, then maintain it. *Why not A:* Design can't come before Requirements — you need to know what you're building before you design it. *Why not C:* Implementation before Design means coding without a plan. *Why not D:* Requirements must come first — everything else depends on knowing what to build. *Reference:* Section 26.1

2. Which methodology works best when requirements are uncertain and likely to change?

  • A) Waterfall
  • B) Agile
  • C) Both work equally well
  • D) Neither — you should wait until requirements are stable
Answer **B)** Agile *Why B:* Agile is specifically designed to accommodate change through iterative development and continuous feedback loops. *Why not A:* Waterfall requires stable requirements up front — changes are costly and disruptive. *Why not C:* They are explicitly different in how they handle change; Agile is definitively better for uncertain requirements. *Why not D:* In many projects, requirements are *never* fully stable. Waiting indefinitely is not a viable option. *Reference:* Section 26.3

3. In Scrum, who is responsible for prioritizing the product backlog?

  • A) The Scrum Master
  • B) The Development Team
  • C) The Product Owner
  • D) The CEO
Answer **C)** The Product Owner *Why C:* The Product Owner represents the user/customer and decides what features have the highest business value. *Why not A:* The Scrum Master facilitates the process and removes obstacles but doesn't decide priorities. *Why not B:* The Development Team decides *how* to build things, not *what* to build. *Why not D:* The CEO may influence priorities, but in Scrum, the Product Owner role has this specific responsibility. *Reference:* Section 26.4

4. Which is a properly formatted user story?

  • A) "The search function should be fast and work well."
  • B) "Implement search functionality using binary search algorithm."
  • C) "As a user, I want to search tasks by keyword so that I can quickly find specific tasks."
  • D) "Search: must support keyword, tag, and date filters."
Answer **C)** "As a user, I want to search tasks by keyword so that I can quickly find specific tasks." *Why C:* It follows the standard user story format: As a [user], I want to [action] so that [benefit]. *Why not A:* "Fast" and "work well" are vague and untestable. *Why not B:* This specifies implementation details (binary search), which user stories should not do. *Why not D:* This is a technical requirement, not a user story — it doesn't specify who needs it or why. *Reference:* Section 26.3, 26.5

5. What is the primary purpose of a code review?

  • A) To prove that the author wrote bad code
  • B) To catch bugs, share knowledge, and maintain code quality
  • C) To slow down the development process
  • D) To ensure the code compiles without errors
Answer **B)** To catch bugs, share knowledge, and maintain code quality *Why B:* Code reviews serve multiple purposes: finding defects, spreading knowledge across the team, enforcing standards, and mentoring. *Why not A:* Code review critiques the code, not the person — the goal is improvement, not blame. *Why not C:* While reviews add time to the process, they save far more time by catching bugs early. *Why not D:* Compilation is checked automatically — code review focuses on higher-level concerns like design, correctness, and readability. *Reference:* Section 26.6

6. Which of the following is an example of technical debt?

  • A) Using a database instead of flat files
  • B) Writing a quick hack to meet a deadline, planning to refactor later
  • C) Adding comprehensive tests to existing code
  • D) Refactoring a function to improve readability
Answer **B)** Writing a quick hack to meet a deadline, planning to refactor later *Why B:* Technical debt is created when you make a shortcut that works now but will cost time later — exactly like financial debt. *Why not A:* Using a database is typically a sound design decision, not a shortcut. *Why not C:* Adding tests *reduces* technical debt — it makes the code safer to change. *Why not D:* Refactoring is *paying down* technical debt, not creating it. *Reference:* Section 26.7

7. What does CI stand for in CI/CD?

  • A) Code Inspection
  • B) Continuous Integration
  • C) Continuous Implementation
  • D) Code Integration
Answer **B)** Continuous Integration *Why B:* CI means that every developer's changes are automatically integrated and tested as soon as they're pushed. *Why not A:* Code Inspection is related to code review, not CI/CD. *Why not C:* "Implementation" is an SDLC phase, not part of the CI/CD acronym. *Why not D:* Close, but the "Continuous" is the key word — it means automated and ongoing. *Reference:* Section 26.9

8. What is an MVP?

  • A) Most Valuable Programmer
  • B) Minimum Viable Product — the smallest version that delivers value
  • C) Maximum Value Planning — the most thorough project plan possible
  • D) Managed Version Protocol — a versioning system for releases
Answer **B)** Minimum Viable Product — the smallest version that delivers value *Why B:* An MVP is the simplest version of a product that can be released to users to test assumptions and gather feedback. *Why not A, C, D:* These are made-up terms that don't exist in software development vocabulary. *Reference:* Section 26.3

Section 2: True/False (1 point each)

9. In Waterfall, you can easily go back to a previous phase if requirements change.

Answer **False.** Waterfall's sequential nature makes going back to a previous phase costly and disruptive. This inflexibility is one of the main criticisms of the Waterfall model. *Reference:* Section 26.2

10. Agile teams deliver working software only at the end of the project.

Answer **False.** Agile teams deliver working software at the end of every sprint (typically every 1-4 weeks). Frequent delivery is a core Agile principle. *Reference:* Section 26.3

11. A sprint retrospective focuses on demonstrating completed features to stakeholders.

Answer **False.** The sprint *review* (or demo) is for showing completed work to stakeholders. The sprint *retrospective* is for the team to reflect on their process — what went well, what didn't, and what to change. *Reference:* Section 26.4

12. Outdated documentation can be worse than no documentation at all.

Answer **True.** Outdated documentation actively misleads developers, causing them to waste time following incorrect instructions. No documentation at least forces people to read the code directly. *Reference:* Section 26.8

Section 3: Short Answer (2 points each)

13. Name two situations where Waterfall would be a better choice than Agile.

Answer Any two of: 1. Requirements are stable and well-understood (e.g., tax calculation software based on published tax law). 2. Regulatory compliance requires formal documentation of each phase (e.g., medical device software). 3. The cost of post-deployment changes is very high (e.g., embedded systems, satellite software). 4. The project is small and well-defined with a clear scope. *Reference:* Section 26.2

14. Explain the difference between a sprint review and a sprint retrospective.

Answer A **sprint review** is a demonstration of completed work to stakeholders (the Product Owner, users, management). Its purpose is to gather feedback on the product and adjust the backlog based on that feedback. A **sprint retrospective** is an internal team meeting focused on the *process*, not the product. The team discusses what went well, what didn't go well, and what changes to make in the next sprint to improve their way of working. *Reference:* Section 26.4

15. What is the difference between "deliberate, prudent" technical debt and "deliberate, reckless" technical debt? Give an example of each.

Answer **Deliberate, prudent:** The team knowingly takes a shortcut but has a plan to fix it. Example: "We'll hardcode the database connection string for the prototype and switch to environment variables before launch." **Deliberate, reckless:** The team knowingly cuts corners without planning to fix it. Example: "We don't have time for tests" — knowing that tests are important but choosing to skip them permanently. The key difference is whether the team plans to pay back the debt. *Reference:* Section 26.7

16. In code review, why is it important to say "Could this be simplified by...?" instead of "Rewrite this — it's too complicated"?

Answer The first phrasing is a *question* that invites collaboration — it suggests an improvement without demanding it, and it acknowledges that the author may have a reason for their approach. The second phrasing is a *command* that criticizes without being constructive, provides no specific guidance, and can feel like a personal attack. Code review is a social skill. Constructive feedback improves the code *and* maintains trust on the team. Harsh feedback may improve the code but damages the working relationship. *Reference:* Section 26.6

Section 4: Applied Scenario (3 points each)

17. You're leading a team of four developers building a student grade management system for your university. The registrar's office has given you detailed specifications for grade calculations, GPA formulas, and transcript formats. The system must comply with FERPA regulations. You have 6 months.

Would you use Waterfall, Agile, or a hybrid? Justify your answer by considering: (a) requirement stability, (b) regulatory needs, and (c) timeline.

Answer A **hybrid** approach is most appropriate: **(a) Requirement stability:** Grade calculations and GPA formulas are defined by university policy and are stable — this favors Waterfall-style up-front planning for the calculation engine. However, the user interface and reporting features may need iteration based on registrar feedback — this favors Agile. **(b) Regulatory needs:** FERPA compliance requires documentation and audit trails, which Waterfall handles naturally. However, compliance requirements can be integrated into an Agile process by treating them as acceptance criteria on every user story. **(c) Timeline:** Six months is long enough for requirements to shift (e.g., the registrar may request changes after seeing early versions). Agile's iterative delivery lets stakeholders see progress and adjust course. **Recommended hybrid:** Use Waterfall-style documentation for compliance requirements. Use Agile sprints for feature development, with sprint reviews where the registrar sees working software and provides feedback. *Reference:* Sections 26.2, 26.3, 26.4

18. Your team's codebase has the following issues: - No tests for the payment processing module - Variable names like x, tmp, and data2 throughout - The README says "Installation: TBD" - A 500-line function that handles user registration, email verification, profile creation, and notification sending

Classify each issue as technical debt, documentation debt, or testing debt. For each, describe one concrete step to begin paying it down.

Answer 1. **No tests for payment processing — Testing debt.** Step: Write integration tests for the three most critical payment paths (successful charge, declined card, refund) before making any changes to the module. 2. **Poor variable names — Technical debt.** Step: Rename variables to be descriptive as you encounter them (Boy Scout Rule). Start with the most-changed files, since unclear names there cause the most confusion. 3. **Incomplete README — Documentation debt.** Step: Write installation instructions and basic usage examples. This can be done in under an hour and immediately helps every new team member and contributor. 4. **500-line function doing four things — Technical debt.** Step: Extract each responsibility into its own function: `register_user()`, `verify_email()`, `create_profile()`, `send_notification()`. Write tests for the original function first so you can verify the refactoring doesn't break anything. *Reference:* Sections 26.7, 26.8