Skip to content

Understanding the SDLC

Jump to bottom
mike-snhu edited this page Aug 15, 2026 · 1 revision

Understanding the SDLC

Part A of the Module Two Assignment uses a simplified Software Development Life Cycle (SDLC):

Analyze → Design → Construct → Test

The purpose of this sequence is to help you separate four different kinds of programming work: understanding the problem, planning a solution, writing the program, and checking the result.

Follow the Part A README and phase READMEs for the required steps. This page explains the ideas behind those steps.

Part A instructions:

https://github.com/GC-STEM/it140-m2-assignment/blob/main/Part-A/README.md

What Is a Software Development Life Cycle?

A software development life cycle is an organized way to move from a problem or need to working software.

Different organizations and projects use different development processes. For this introductory assignment, you use four phases that are easy to see in a small Python program:

  1. Analyze
  2. Design
  3. Construct
  4. Test

Each phase answers a different question.

Phase Main Question
Analyze What must the program do?
Design How is the program planned to do it?
Construct How do I translate the plan into Python?
Test Does the completed program behave as required?

The SDLC in This Assignment

The repository separates the phases into folders and documents so you can see how software-development artifacts connect.

Part-A/
├── name_age_sdw.md
├── analysis/
├── design/
├── src/
└── tests/

The folders do not mean that software development always moves in only one direction. They provide a clear learning sequence for this assignment.

If testing reveals a problem, you may return to your code. If coding reveals that you misunderstood the design, you may return to the design. If the design seems unclear, you may return to the requirements.

Analyze

The Analyze phase focuses on what the program must do.

Your primary source is the provided Software Requirements Specification (SRS):

https://github.com/GC-STEM/it140-m2-assignment/blob/main/Part-A/analysis/name_age_srs.md

During Analyze, you identify ideas such as:

  • The program's purpose
  • Inputs
  • Processing
  • Outputs
  • Functional requirements
  • Constraints
  • Expected results
  • Edge cases
  • Acceptance test cases

You record brief working notes in the Software Development Worksheet (SDW).

Analyze-phase instructions:

https://github.com/GC-STEM/it140-m2-assignment/blob/main/Part-A/analysis/README.md

Requirements Are Not the Same as Code

A requirement describes a result or behavior the software must provide.

It usually does not tell you the exact Python statement to write.

That distinction matters because the Analyze phase is about understanding the problem before deciding how to implement it.

Design

The Design phase focuses on how the program is planned to meet the requirements.

The design has already been provided for this assignment. You review:

  • The Software Design Document (SDD)
  • The flowchart
  • The pseudocode

Design-phase instructions:

https://github.com/GC-STEM/it140-m2-assignment/blob/main/Part-A/design/README.md

Three Views of the Same Planned Solution

The design artifacts present related information in different forms:

  • The SDD explains the planned solution in technical documentation.
  • The flowchart represents the sequence visually.
  • The pseudocode represents the sequence as written steps without requiring Python syntax.

You should be able to move among these views and recognize the same basic Input → Processing → Output plan.

SRS Versus SDD

A useful distinction is:

SRS = what the program must do
SDD, flowchart, and pseudocode = how the program is planned to do it

If the design and requirements appear to disagree, return to the SRS and the assignment instructions rather than inventing a new requirement.

Construct

The Construct phase is where you write the Python program.

For this assignment, you do not begin with an empty file. You complete the provided starter file:

Part-A/src/name_age.py

Construct-phase instructions:

https://github.com/GC-STEM/it140-m2-assignment/blob/main/Part-A/src/README.md

The starter file contains course-provided structure. Some of it uses Python concepts that appear later in IT 140.

You are not expected to rewrite or fully understand all of that structure during Module Two.

Use the Pseudocode as Your Coding Guide

Pseudocode describes the algorithm without requiring valid Python syntax.

During Construct, your job is to translate the planned steps into the Python concepts identified by the assignment instructions and zyBooks references.

A useful approach is:

  1. Read the next planned step.
  2. Write the corresponding Python statement.
  3. Run the program.
  4. Correct any immediate error.
  5. Continue to the next step.

This is called incremental development. You change a small amount at a time so a new problem is easier to locate.

Test

The Test phase asks:

Does the program behave as required?

Test-phase instructions:

https://github.com/GC-STEM/it140-m2-assignment/blob/main/Part-A/tests/README.md

Testing in this assignment includes several forms:

  • Running the program yourself
  • Comparing actual behavior with requirements and expected results
  • Using the course Instant Feedback Tool when available
  • Optionally running the provided local automated acceptance tests

The test file is provided. You do not need to understand or modify its internal testing code.

See Testing and Debugging for more explanation.

Moving Backward Is Normal

The phase sequence gives you an organized path, but correcting software often requires moving backward.

For example:

Test → problem found → return to Construct → correct code → Test again

You may also discover during Construct that you need to reread the pseudocode, or during Design that you need to reread a requirement.

Returning to an earlier artifact is not starting over. It is using the development information to find where your understanding or implementation needs correction.

Traceability: Connecting the Pieces

A useful software-development habit is being able to connect a result back to the information that required it.

For this assignment, you can trace ideas through artifacts:

Requirement → Design → Code → Test

For example, when a test result is wrong:

  1. Identify which expected behavior failed.
  2. Find that behavior in the SRS.
  3. Review the related design step.
  4. Inspect the code that implements that step.
  5. Correct the code.
  6. Test again.

You do not need to use the word traceability to complete the assignment. The important skill is learning to connect what the software should do with how it was planned, written, and checked.

Why the SDW Is Useful

The Software Development Worksheet (SDW) gives you one place to record your understanding while you Analyze and Design.

It is intentionally a working document rather than a polished report.

Use it to:

  • Put requirements into your own words
  • Record Input → Processing → Output
  • Identify constraints and edge cases
  • Connect requirements to the provided design
  • Trace a test case through the plan
  • Record questions before you begin coding

The SDW is not a grading deliverable for this assignment.

See Understanding the Assignment Documents for the role of each file.

Where to Go Next

IT 140 Module Two Assignment

Assignment Links

Help and Course Resources

Clone this wiki locally