Repository navigation
Understanding the Assignment Documents
The Module Two Assignment repository contains several kinds of software-development files.
You do not need to edit or submit every file you see.
Follow the repository README files for the current instructions. If an instruction does not tell you to edit a provided file, leave that file unchanged.
Top-level assignment README:
https://github.com/GC-STEM/it140-m2-assignment
Student work for this assignment is limited to three files:
-
Part-A/2-3_worksheet.md— Software Development Worksheet working notes -
Part-A/src/name_age.py— Part A Python program -
Part-B/ide_features.md— Part B IDE Features Reflection
The current repository submission workflow distinguishes them this way:
| File | Role | Current submission status |
|---|---|---|
Part-A/src/name_age.py |
Part A Python program | Graded |
Part-B/ide_features.md |
Part B IDE Features Reflection | Graded |
Part-A/2-3_worksheet.md |
Analysis/design working notes | Ungraded supporting file included in the submission |
Always confirm the current D2L Brightspace Guidelines and Rubric and the root README before submitting. D2L remains authoritative for the actual assignment submission.
File:
Part-A/2-3_worksheet.md
The Software Development Worksheet is where you record short notes during Analyze and Design.
It helps you:
- Summarize the program's purpose
- Identify Input → Processing → Output
- Put selected requirements into your own words
- Identify constraints and edge cases
- Connect requirements to the provided design
- Follow a test case through the planned solution
- Record questions or unclear information
The SDW is meant to support your thinking. It does not need to read like a polished report.
The SDW is not graded as a separate deliverable, but the current repository README includes it as an ungraded supporting file in the Brightspace submission.
Open the SDW:
https://github.com/GC-STEM/it140-m2-assignment/blob/main/Part-A/2-3_worksheet.md
File:
Part-A/analysis/2-3_requirements.md
The Software Requirements Specification defines what the name_age program must do.
Use it during Analyze and return to it whenever you need to verify required behavior.
The SRS includes information such as:
- General program description
- Functional requirements
- Nonfunctional requirements
- Technology constraints
- Quality constraints
- Sample input and output
- Acceptance test cases
For this assignment, treat the SRS as the primary Part A technical source for required program behavior.
Open the SRS:
https://github.com/GC-STEM/it140-m2-assignment/blob/main/Part-A/analysis/2-3_requirements.md
File:
Part-A/design/2-3_design.md
The Software Design Document describes the planned solution.
A useful distinction is:
SRS = what is required SDD = how the planned solution is designed to meet the requirements
Use the SDD with the flowchart and pseudocode during Design.
Open the SDD:
https://github.com/GC-STEM/it140-m2-assignment/blob/main/Part-A/design/2-3_design.md
File:
Part-A/design/2-3_flowchart.drawio
A flowchart represents a sequence visually.
In this assignment, follow the diagram from Start to End and identify where the planned program:
- Receives or obtains input
- Processes data
- Produces output
The course IDE includes Draw.io support so you can view the provided .drawio file in VS Code.
Open the flowchart from the local clone of your personal repository. Do not edit the public course template.
File:
Part-A/design/2-3_pseudocode.pseudo
Pseudocode describes the algorithm as ordered steps without requiring valid Python syntax.
It is intended to help you understand the logic before you write code.
During Construct, use the pseudocode as the primary step-by-step coding guide. Translate its ideas into Python using the concepts identified in the Construct instructions.
Pseudocode is not Python code. Do not expect it to run in the Python interpreter.
Open the pseudocode:
https://github.com/GC-STEM/it140-m2-assignment/blob/main/Part-A/design/2-3_pseudocode.pseudo
File:
Part-A/src/name_age.py
This is the Python source file you complete during Construct and test during the Test phase.
The file contains provided structure plus specific TODO: lines for you to complete. The starter file deliberately contains some Python structures you have not studied yet. You are not expected to rewrite those structures.
Follow the Construct README carefully:
https://github.com/GC-STEM/it140-m2-assignment/blob/main/Part-A/src/README.md
A test case describes conditions used to check a program.
For this assignment, the SRS contains the shared acceptance test cases. When reviewing an acceptance case, look for:
- Input values
- Expected output or behavior
- The requirement being checked
- Whether the case represents typical or unusual input
You use one acceptance case by hand during Design and use the cases again during Test.
File:
Part-A/tests/test_name_age.py
This provided file can run the shared acceptance cases automatically.
You have not studied Python testing yet, so:
- You are not expected to understand every line.
- You are not expected to modify it.
- Running it locally is optional.
- A failing test should normally lead you back to
name_age.py, not to editing the test.
Use the Test README for the current instructions:
https://github.com/GC-STEM/it140-m2-assignment/blob/main/Part-A/tests/README.md
When you push a changed name_age.py, the repository can run the IT 140 Checks workflow and its Python program check.
That automated feedback can check:
- Python syntax
- The provided acceptance tests
- Basic code style
GitHub Actions feedback is not a deliverable, not a grade, and not a Brightspace submission.
See Testing and Debugging for how it fits with manual testing, local tests, and the Instant Feedback Tool.
File:
Part-B/ide_features.md
This is the Part B graded deliverable.
You use it to describe three IDE features that you used or observed while completing Part A and explain how those features can make programming easier or more effective.
The reflection is about your own experience. The Part B README tells you when and how to use outside documentation to confirm feature names.
Part B instructions:
https://github.com/GC-STEM/it140-m2-assignment/blob/main/Part-B/README.md
The Part A artifacts form a chain:
SRS
│
│ What must the program do?
▼
SDD + Flowchart + Pseudocode
│
│ How is the solution planned?
▼
name_age.py
│
│ How is the plan implemented in Python?
▼
Acceptance Tests / Feedback
Does the result behave as required?
The SDW sits alongside this chain as your working notes.
A useful habit is to ask which document should answer your question:
| If your question is... | Start with... |
|---|---|
| What must the program do? | SRS |
| What input, output, or constraint is required? | SRS |
| How is the solution planned? | SDD, flowchart, or pseudocode |
| What step comes next while coding? | Pseudocode and Construct README |
| What Python file do I edit? |
name_age.py and Construct README |
| What result should a test produce? | SRS acceptance test cases |
| What should I submit? | D2L Guidelines and Rubric and the current root README |
2-3_worksheet.md supports your process. You edit it and the current repository instructions include it as an ungraded supporting upload.
Reference files provide information or tools you use without changing them unless a current instruction says otherwise.
Examples include:
- SRS
- SDD
- Flowchart
- Pseudocode
- Test file
- README files
For Module Two, the two graded deliverables are:
Part-A/src/name_age.pyPart-B/ide_features.md
Always confirm the current submission requirements in D2L Brightspace before submitting.
- SDLC overview: Understanding the SDLC
- Part A instructions: https://github.com/GC-STEM/it140-m2-assignment/blob/main/Part-A/README.md
- Part B instructions: https://github.com/GC-STEM/it140-m2-assignment/blob/main/Part-B/README.md
- IDE help: Working in Your Course IDE
- Testing help: Testing and Debugging