Understanding the SDLC

Understanding the SDLC

The Module Three repository uses a simplified Software Development Life Cycle (SDLC):

Analyze → Design → Construct → Test

The complete sequence shows how software work can move from requirements to a tested implementation. Module Three, however, grades the Design phase. You may stop after completing and reviewing the graded flowchart and pseudocode and then submit them in D2L Brightspace.

The required assignment path is therefore:

Analyze → Design → Submit

Construct and Test are optional practice after the graded design is ready.

Why Use an SDLC for a Small Assignment?

The paycheck calculator is intentionally small enough to understand while you practice a professional habit: separating what a program must do from how you plan to make it do that.

Without that separation, it is easy to begin typing code before the problem is understood. As programs get larger, unclear requirements and weak designs become harder and more expensive to correct.

Analyze — What Must the Program Do?

Analyze focuses on requirements.

For this assignment, you identify:

• the information the program needs;
• the regular-pay rule;
• the overtime-pay rule;
• the boundary at 40 hours;
• the decision the program must make; and
• the result the program must produce.

The official Guidelines and Rubric is the authority. The repository SRS reorganizes those requirements so you can review them systematically.

Analyze is not Design

During Analyze, avoid jumping immediately to a final IF condition, formula, or Python statement. First make sure you can explain the requirement in words.

A useful question is:

"What must be true when this program is finished?"

Design — How Should the Solution Work?

Design turns the requirements into a planned solution.

In Module Three, you create two representations of the same design:

• a flowchart; and
• pseudocode.

This is the graded work.

Your two artifacts should agree about:

• input;
• decision logic;
• processing on each path;
• the 40-hour boundary; and
• output.

If they disagree, at least one design needs revision before construction.

Design Can Be Tested Before Code Exists

You can trace a value through the flowchart and pseudocode by hand.

For example, select one of the verification cases in the SRS. Follow the input through every design step and determine the result. Then compare the two design representations.

This is a form of design verification. It can reveal logical problems before you spend time debugging Python syntax.

Construct — Turn the Design Into Code

Construct translates a design into executable code.

For Module Three, this phase is optional. If you choose to complete it:

1. finish the graded flowchart and pseudocode first;
2. open your pseudocode beside src/paycheck_calculator.py;
3. translate one design step at a time; and
4. run after small changes.

A key principle is:

The code should implement the design, not replace it.

If coding reveals that the design cannot produce the required result, return to Design, correct the design, and then update the code.

Test — Does the Program Behave as Intended?

Testing compares actual behavior with expected behavior.

For the optional Module Three implementation, useful checks include:

• a regular-hours case;
• exactly 40 hours;
• a value just above 40 hours; and
• the 60-hour assignment example.

The repository provides optional automated tests, but you should also understand the expected result yourself.

Testing is iterative:

Test → Find a problem → Correct → Retest

Moving Backward Is Normal

The arrows in an SDLC diagram can make development look like a one-way process. Real development is often iterative.

You may discover during:

• Design that a requirement was misunderstood → return to Analyze.
• Construct that the design is incomplete → return to Design.
• Test that code and design disagree → correct the appropriate earlier artifact.

Returning to an earlier phase is not a failure. It is part of incremental development.

Requirements Traceability

Traceability means being able to connect a requirement to the artifact that addresses it.

In this assignment, a simple trace might look like:

Pay-rule requirement → SRS requirement → flowchart step/path → pseudocode step/path → optional Python code → optional test case

You do not need an enterprise traceability system for this assignment. The SRS, SDD, and SDW simply introduce the habit of checking that nothing important disappears as work moves from one phase to the next.

Why the SDW Exists

The Software Development Worksheet (SDW) gives you a place to record short working notes while moving from Analyze to Design.

It helps you:

• explain requirements in your own words;
• identify input, processing, and output;
• think through the 40-hour boundary;
• plan without writing Python first;
• map requirements to both graded artifacts; and
• trace a case through the design.

The SDW is not the graded design itself. Your required work belongs in the .drawio and .pseudo files.

What to Remember

For Module Three:

Understand first. Design second. Submit the design. Code and test only if you want the additional practice.

Return to Home or continue to Understanding the Assignment Documents.