Understanding the SDLC

Understanding the SDLC

IT 140 uses a simplified Software Development Life Cycle (SDLC):

Analyze → Design → Construct → Test

Module Four exposes all four phases, but only the Design artifact is graded.

The required assignment path is:

Analyze → Design → Submit

Construct and Test are optional practice after the graded pseudocode is complete.

Analyze — What Must the Program Do?

Analyze focuses on requirements, not implementation.

For the Higher/Lower Game, this means understanding behaviors such as:

• obtaining lower and upper bounds;
• validating the relationship between those bounds;
• generating the target number;
• obtaining and validating guesses;
• distinguishing too-low, too-high, and correct guesses; and
• continuing until the correct guess.

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 finished pseudocode or Python.

First be able to explain:

• what information is needed;
• what makes input valid;
• what decisions the program must make;
• what work repeats; and
• what causes repetition to stop.

Design — How Should the Solution Work?

Design turns requirements into a planned algorithm.

In Module Four, the graded design is:

• design/hilow_game.pseudo

Pseudocode should be detailed enough that another programmer could follow the logic, while remaining independent of exact Python syntax.

A strong design makes clear:

• sequence;
• input and output;
• validation;
• decision branching;
• loops; and
• stopping conditions.

Design Can Be Tested Before Code Exists

You can trace a scenario through pseudocode by hand.

For example:

1. choose a behavior from the SRS verification table;
2. follow the pseudocode one statement at a time;
3. note each decision and loop condition; and
4. confirm that the required result or next action occurs.

This is design verification. It can reveal logic problems before you debug Python syntax.

Construct — Turn the Design Into Code

Construct translates a design into executable code.

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

1. finish the graded pseudocode first;
2. open it beside src/hilow_game.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 pseudocode is incomplete, return to Design and correct the graded design first.

Test — Does the Program Behave as Intended?

Testing compares actual behavior with expected behavior.

For the optional Higher/Lower Game implementation, useful checks include:

• valid and invalid bounds;
• guesses outside the selected range;
• too-low and too-high valid guesses;
• a correct guess; and
• several guesses before success.

Testing is iterative:

Test → Find a problem → Correct → Retest

Moving Backward Is Normal

Software development is not always one-way.

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 part of incremental development.

Requirements Traceability

Traceability means connecting a requirement to the artifact that addresses it.

A simple Module Four trace might look like:

Assignment requirement → SRS requirement → pseudocode step/branch/loop → optional Python code → optional test behavior

You do not need an enterprise traceability system. The SRS, SDD, and SDW simply introduce the habit of checking that requirements do not disappear as work moves forward.

Why the SDW Exists

The optional Software Development Worksheet helps you:

• explain requirements in your own words;
• separate inputs, outputs, validation, decisions, and loops;
• identify stopping conditions;
• plan before writing detailed pseudocode;
• map requirements to your design; and
• trace behavior through the design.

The SDW is not the graded design itself.

What to Remember

For Module Four:

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

Return to Home or continue to Understanding the Assignment Documents.