Skip to content

Understanding the SDLC

mike-snhu edited this page Aug 15, 2026 · 2 revisions

Understanding the SDLC

The Module Three materials introduce a simple sequence for developing a program:

Analyze requirements → Design the solution → Write the code → Test the code

This repository uses the shorter SDLC labels:

Analyze → Design → Construct → Test

Analyze

Analyze means determining what the program must do before deciding how to build it.

For the paycheck calculator, analysis includes identifying the input, required pay rules, decision boundary, and required output. The assignment Guidelines and Rubric is the official source. The SRS reorganizes those requirements for easier reference.

Design

Design means deciding how the solution will work before writing executable code.

In Module Three, the design artifacts are the graded work:

  • A flowchart
  • Pseudocode

Both should represent the same logic.

Construct

Construct means translating the design into executable Python code.

Construction is optional practice for this assignment. If you choose to complete it, use your own flowchart and pseudocode as the plan rather than designing the program again while you code.

Test

Test means checking whether the constructed program behaves as the requirements and design say it should.

Testing is also optional practice in Module Three. Boundary cases are especially useful because they check what happens where a condition changes from one path to another.

Why Keep the Full SDLC Here?

The graded assignment focuses on design, but seeing the later phases helps show why design matters. A useful design should be clear enough that it can guide construction and specific enough that its behavior can be tested.

This same habit becomes more valuable as programs become larger and more complex.

Clone this wiki locally