Skip to content

Understanding the SDLC

Jump to bottom
mike-snhu edited this page Oct 2, 2026 · 4 revisions

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:

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/
├── 2-3_worksheet.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 technical source is the provided Software Requirements Specification (SRS):

https://github.com/GC-STEM/it140-m2-assignment/blob/main/Part-A/analysis/2-3_requirements.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 Analyze 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.

A useful distinction is:

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

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

The starter file includes course-provided structure and specific TODO: locations. Follow the current Construct README rather than rewriting unfamiliar provided code.

Construct-phase instructions:

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

A useful approach is to make one small change, save, run the program, and then continue. Small steps make new problems easier to locate.

Test

The Test phase asks whether the completed program behaves as required.

Testing may include:

  • Running the program yourself
  • Comparing actual output with expected behavior
  • Checking the SRS acceptance cases
  • Using the course Instant Feedback Tool
  • Optionally running the provided local automated tests
  • Reviewing the GitHub Actions Python program check after pushing your work

Test-phase instructions:

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

A failed test is information. It identifies behavior that needs investigation; it does not automatically tell you which line to change.

See Testing and Debugging for more detail.

The SDW Is a Working File and an Ungraded Supporting Upload

Part-A/2-3_worksheet.md supports your thinking during Analyze and Design. It is not one of the two graded deliverables.

However, the current repository submission instructions include the SDW as an ungraded supporting file in the Brightspace submission along with the two graded files.

Always follow the current repository README and D2L Brightspace instructions for the actual submission requirements.

Part B Is Related but Not an SDLC Phase

Part B asks you to reflect on IDE features you used or observed while completing Part A.

That reflection is not another phase of the Part A SDLC. It is a separate graded deliverable:

Part-B/ide_features.md

Git and GitHub Support the SDLC

Git and GitHub are tools that support your work across the phases. Saving, committing, pushing, and reviewing GitHub Actions feedback do not replace Analyze, Design, Construct, or Test.

See Git and GitHub During the Assignment for the repository workflow.

Where to Go Next

IT 140 Module Two Assignment

Assignment Links

Help and Course Resources

Clone this wiki locally