Lab-04: Software Development Processes

1. Tools. Git; a Markdown editor with Mermaid preview (VS Code with the extension Markdown Preview Mermaid Support, or mermaid.live in the browser); CMake 3.28 or later; a C++20 compiler (GCC 13, Clang 17 or Visual Studio 2022 or later); internet access for the first CMake configure, because FetchContent downloads the dependencies.

   git --version
   cmake --version            # 3.28 or later
   g++ --version              # GCC 13+ (or: clang++ --version, or cl in a VS prompt)
   cd clubhub                 # your team repository from Lab-01
   git switch main && git pull
   git switch -c lab-04
   mkdir -p lab04/scores

2. Inputs from earlier labs. This lab reuses Lab-01 and Lab-02 (and the licence chosen in Lab-03). If an earlier deliverable is incomplete or named differently, use the fallback; do not stop to repair the earlier lab.

   Input	Typical file	What you need from it	Fallback if missing
   Team charter (Lab-01)	lab01/team-charter.md	Members, roles (Product Owner, first Scrum Master), hours each member can give per week, meeting times, how you communicate	5 members, one Product Owner, Scrum Master rotating each sprint, about 6 hours per person per week, one team meeting a week plus a chat group
   Problem statement (Lab-01)	lab01/problem-statement.md	Who has which problem today, what success looks like	Clubs announce events on social media and collect sign-ups on paper; seats are overbooked, nobody knows who attended, the administration has no overview
   Application type (Lab-02)	lab02/application-type.md	Chosen application type, top quality attributes, CSV or JSON storage	Analysed as a web and mobile application; core implemented in C++20 as a command-line program with CSV files; top attributes: correctness of the registration rules, usability, privacy
   Repository licence (Lab-03)	LICENSE	Licence to check the dependencies against	MIT
   Build file	CMakeLists.txt	Existing targets, whether GoogleTest is already fetched	Use the complete starter in Task 5

3. Case-study brief. The box below contains every product fact this lab needs. Wherever a step says "the case-study brief", it means this box.
   Case-study brief: ITC Club Hub

   Purpose

   An application for student clubs at the Institute of Technology of Cambodia. Teams analyse and model it as a web and mobile application and implement its core in C++20: domain model, business rules and a command-line front end, with CSV or JSON file storage.

   Users

   Club leader registers a club and publishes events. Administrator approves clubs and sees a monthly activity report. Student browses events, registers, cancels and receives a reminder. Organiser checks students in at the door and sees attendance.

   Features

   Club registration and approval · events with title, date and time, location, capacity, description · browse, register, cancel · reminder · check-in and attendance · monthly report. A waiting list is a Should feature.

   Business rules

   Capacity cannot be exceeded · a student cannot register twice for the same event · cancellation closes 24 hours before the start · events in the past cannot be registered for · only approved clubs can publish events.

   Personal data

   Student ID, name, email, phone (optional), club membership, attendance records.

   Code names

   Namespace clubhub; classes Club, Event, Student, Registration, RegistrationService (registerStudent, cancel, checkIn), interfaces EventRepository, RegistrationRepository with CSV implementations. Layout: CMakeLists.txt, src/, include/clubhub/, tests/, .github/workflows/ci.yml.

   Semester

   15 weeks. Week 4: this lab. Weeks 5–6: requirements (Lab-05, interview, SRS, backlog). Week 7: UML models (Lab-06). Week 8: midterm exam and project checkpoint 1 (requirements and models reviewed). Weeks 9–10: Sprint 1. Weeks 11–12: Sprint 2. Week 13: hardening. Week 14: project submission and demo. Week 15: final exam.

   Team roles

   One Product Owner who liaises with the client (the instructor or a teaching assistant plays the client, available about 30 minutes a week), a Scrum Master rotating each sprint, the others Developers.

4. Deliverable folder. By the end of the lab your repository contains:

   clubhub/
   ├── lab01/ lab02/ lab03/              # earlier labs, read-only here
   ├── lab04/
   │   ├── fundamental-activities.md     # Task 1
   │   ├── scores/<github-username>.md   # Task 2, one file per member
   │   ├── process-comparison.md         # Task 2
   │   ├── process-decision.md           # Task 3 (PDR-001 + diagram)
   │   ├── process.mmd                   # Task 3 (Mermaid source)
   │   ├── iteration-plan.md             # Task 4 (Gantt + goals)
   │   ├── reuse-inventory.md            # Task 5
   │   ├── v-model-trace.md              # Challenge
   │   ├── cmmi-reflection.md            # Challenge
   │   └── README.md                     # Task 5: record what changed
   ├── CMakeLists.txt                    # Task 5: FetchContent dependencies
   └── tests/
       ├── data/events.csv               # Task 5
       └── csv_smoke_test.cpp            # Task 5

5. Commit convention. One commit (or more) per task, message Lab-04 task N: <what>, made by the member who did the work. Pairing is fine: add Co-authored-by: lines for the partner.

Goal

Describe how specification, design and implementation, validation and evolution will actually happen in your Club Hub project: who leads each one, in which weeks, and which artifact in the repository proves it happened.

Steps

1. Create lab04/fundamental-activities.md from the starter below and fill the header (team name, version v1.0, date).
2. Fill the main table with one row per activity. The column What happens in Club Hub names at least two concrete actions with Club Hub features, rules or classes (for example "write user stories for register and cancel", "implement RegistrationService::cancel").
3. In Who leads write a role and a member name from your team charter; in Weeks use the semester schedule from the case-study brief; in Artifact give a repository path (lab05/srs.md, tests/, CHANGELOG.md).
4. Add a Done when column with an observable criterion (for example "the TA approved the SRS by email", "all GoogleTest tests green in CI").
5. Under the table, list 2–4 sub-activities per activity (specification: elicitation, analysis, specification, validation of requirements) and map each activity to one or two ISO/IEC/IEEE 12207 technical processes (for example validation → "Verification" and "Validation").
6. Write a section Overlaps and loops with at least two concrete loops in your semester, such as "Sprint 1 review (week 10) produces new stories → specification again in week 11".
7. Commit as the Product Owner: Lab-04 task 1: fundamental activities for Club Hub.

Starter (Markdown)

# Fundamental activities · Team <name> · v1.0 (<date>)

| Activity                  | What happens in Club Hub | Who leads (role, name) | Weeks | Artifact | Done when |
|---------------------------|--------------------------|------------------------|-------|----------|-----------|
| Specification             | TODO                     | Product Owner, TODO    | 5-6   | TODO     | TODO      |
| Design and implementation | TODO                     | TODO                   | TODO  | TODO     | TODO      |
| Validation                | TODO                     | TODO                   | TODO  | TODO     | TODO      |
| Evolution                 | TODO                     | TODO                   | TODO  | TODO     | TODO      |

## Sub-activities and ISO/IEC/IEEE 12207 processes
- Specification: elicitation, ... · 12207: Stakeholder needs and requirements definition, ...
- Design and implementation: ...
- Validation: ...
- Evolution: ...

## Overlaps and loops
1. TODO
2. TODO

Expected output (one row, for comparison)

| Validation | Unit tests for capacity, duplicate and 24 h rules with
GoogleTest; peer review of every pull request; demo of the CLI at
each sprint review | Developers, test lead Dara (rotates) | 9-14 |
tests/, CI run history, lab09/review-notes.md | every Must story
has passing tests in CI and the TA accepted it at the review |

## Overlaps and loops
1. Week 10: the Sprint 1 review shows the client wants "seats left"
   in the event list -> new story US-21 -> specification in week 11.
2. Weeks 9-12: design and validation interleave daily: each pull
   request contains code and its tests, reviewed before merge.

Show hints

Acceptance checklist

Goal

Compare waterfall, incremental delivery and Scrum-style iterative development for Club Hub on five weighted criteria, first individually and then as a team, and compute a weighted score for each.

Steps

1. Individually, before any discussion: every member copies the starter to lab04/scores/<github-username>.md, scores each model from 1 to 5 on each criterion (5 = fits Club Hub very well on this criterion) and commits it. Scoring alone first avoids everybody copying the loudest opinion.
2. As a team, agree on weights that sum to 100 for the five criteria: requirements stability, client availability, team experience, deadline, risk. Justify each weight with one fact from the case-study brief or your team charter.
3. Create lab04/process-comparison.md. For each cell, discuss where individual scores differ by 2 or more, agree on a team score, and write a one-line justification per criterion.
4. Compute the weighted score of each model: Σ (weight × score) / 100, giving a value between 1.0 and 5.0. Show the full calculation for one model.
5. Add a sensitivity check: move 10 points from your heaviest criterion to your lightest and recompute. Does the winner change? One sentence.
6. End with a 3–5 sentence conclusion: which model scores best, which weakness of it you must manage, and whether a hybrid would score better. The Scrum Master commits: Lab-04 task 2: scored process comparison.

Starter (Markdown)

# Process comparison · Team <name> · v1.0

Scale: 1 = fits Club Hub badly on this criterion, 5 = fits very well.

| Criterion               | Weight | Waterfall | Incremental | Scrum-style | Justification (one line each) |
|-------------------------|-------:|----------:|------------:|------------:|-------------------------------|
| Requirements stability  |     __ |        __ |          __ |          __ | __                            |
| Client availability     |     __ |        __ |          __ |          __ | __                            |
| Team experience         |     __ |        __ |          __ |          __ | __                            |
| Deadline (week 14)      |     __ |        __ |          __ |          __ | __                            |
| Risk                    |     __ |        __ |          __ |          __ | __                            |
| **Weighted score**      |    100 |        __ |          __ |          __ |                               |

## Why these weights
- Requirements stability (__): ...

## Calculation for one model
## Sensitivity check
## Conclusion

Expected output (format of one row and one calculation; your numbers will differ)

| Client availability | 20 | 2 | 3 | 4 | The TA is available 30 min every
Friday: enough for a review every two weeks, not for daily questions. |

Calculation, Scrum-style:
(25×5 + 20×4 + 15×3 + 25×4 + 15×4) / 100 = 410 / 100 = 4.10

Show hints

Acceptance checklist

Goal

Record the team's process choice as a short decision record (context, options, decision, consequences) including a tailoring table, and draw the chosen process as a Mermaid flowchart that the whole team will follow from week 5.

Steps

1. Create lab04/process-decision.md from the starter as PDR-001, status Proposed, with the date and all members as deciders.
2. Context: at least five facts that drive the choice, each with its source: team size and weekly hours (charter), client availability (brief), fixed milestones in weeks 8 and 14 (brief), how clear the requirements are today (problem statement), the team's experience with C++, CMake and sprints.
3. Options considered: the three models from Task 2 with their weighted scores and one pro and one con each, plus option D "no defined process" so that the record shows why doing nothing is worse.
4. Decision: name the model (a hybrid is allowed and common) and add a tailoring table with at least six elements (up-front work, iteration length, meetings, roles, documents, Definition of Done, hardening), each with the reference practice and your tailoring. If the decision is not the Task 2 winner, explain why.
5. Consequences: at least three positive consequences and three negative ones or risks, each negative one with a mitigation.
6. Draw the process in lab04/process.mmd as a Mermaid flowchart and paste the same source into the record. It must show the requirements phase (weeks 5–6), modelling (week 7), checkpoint 1 (week 8), the sprint loop (planning → development and testing → review → retrospective) with a decision node that repeats it, hardening (week 13) and submission (week 14), plus a dashed feedback arrow from the review to the product backlog. Put the responsible role in each node label.
7. Every member reviews the pull request or the file and adds an approval line; the Product Owner sets the status to Accepted and commits: Lab-04 task 3: PDR-001 process decision and diagram.

Starter (Markdown with Mermaid)

# PDR-001 · Development process for ITC Club Hub
Status: Proposed | Accepted | Superseded by PDR-00_
Date: 2026-__-__        Deciders: <all members>

## Context
1. <fact> (source: lab01/team-charter.md)
2. ...

## Options considered
| Option                       | Weighted score (Task 2) | Pro | Con |
|------------------------------|------------------------:|-----|-----|
| A. Waterfall                 | __                      |     |     |
| B. Incremental delivery      | __                      |     |     |
| C. Scrum-style iterative     | __                      |     |     |
| D. No defined process        | n/a                     |     |     |

## Decision
We will use ...  because ...

| Element | Reference practice | Our tailoring | Reason |
|---------|--------------------|---------------|--------|

## Consequences
Positive: ...
Negative / risks (with mitigation): ...

## Process diagram (source: lab04/process.mmd)
```mermaid
flowchart TD
  %% TODO: requirements (wk 5-6), models (wk 7), checkpoint (wk 8)
  %% TODO: sprint loop with a decision node, hardening, submission
  %% TODO: dashed feedback arrow from review to the product backlog
```

## Approvals
- <member>, <date>: approved

Expected output (the sprint loop part only; your diagram adds the phases before and after it)

flowchart TD
  B[(Product backlog · PO)] --> P[Sprint planning · whole team]
  P --> D[Develop and test · developers]
  D --> R[Sprint review · client and PO]
  R --> RE[Retrospective · Scrum Master]
  RE --> Q{Another sprint?}
  Q -- yes --> P
  Q -- no --> H[Hardening · week 13]
  R -. new or changed stories .-> B

Show hints

Acceptance checklist

Goal

Turn the decision into a calendar: a Mermaid Gantt chart for weeks 5 to 14 aligned with the semester schedule, with milestones, sprint goals and a capacity estimate for each sprint.

Steps

1. Create lab04/iteration-plan.md. Find the Monday of week 5 of your semester and replace 2026-10-05 in the starter with it; shift every other date by the same amount.
2. Fill the sections Requirements (week 5 elicitation, week 6 SRS and backlog), Models (week 7), Checkpoint (week 8: midterm exam bar marked crit and a milestone Checkpoint 1 on Friday), Sprint 1 (weeks 9–10), Sprint 2 (weeks 11–12), Hardening (week 13) and Submission (week 14, milestone Submission and demo).
3. Each sprint has a planning milestone on its first Monday, a development bar of 10 working days and a review and retrospective milestone on its last Friday.
4. Add a section Labs with one bar per lab from Lab-05 (weeks 5–6) to Lab-11 (week 13), so the team sees when lab work and sprint work compete.
5. Below the chart add an iteration goals table: iteration, weeks, goal in one sentence, candidate features from the case-study brief, exit criterion.
6. Compute the capacity of each sprint as on the chapter slide: members × hours per week × 2 weeks × 0.8, and write it in the goals table. Check that the candidate features are plausible for that number of hours.
7. Render the chart (VS Code preview or mermaid.live), check that no sprint bar overlaps the exam week and that the plan ends in week 14, then commit: Lab-04 task 4: iteration plan weeks 5-14.

Starter (Mermaid Gantt)

gantt
  title ITC Club Hub · iteration plan weeks 5 to 14
  dateFormat YYYY-MM-DD
  axisFormat %d %b
  tickInterval 1week
  weekday monday
  excludes weekends
  section Requirements
    Elicitation interview with the client :req1, 2026-10-05, 5d
    SRS and product backlog               :req2, after req1, 5d
  section Models
    UML diagrams                          :mod1, 2026-10-19, 5d
  section Checkpoint
    Midterm exam week                     :crit, exam, 2026-10-26, 5d
    Checkpoint 1                          :milestone, cp1, 2026-10-30, 0d
  section Sprint 1
    %% TODO planning milestone (Mon of week 9), development 10d,
    %% review and retrospective milestone (Fri of week 10)
  section Sprint 2
    %% TODO same pattern in weeks 11 and 12
  section Hardening
    %% TODO week 13, bug fixes only, feature freeze
  section Submission
    %% TODO milestone "Submission and demo" in week 14
  section Labs
    %% TODO Lab-05 (weeks 5-6) ... Lab-11 (week 13)

Expected output (excerpt up to Sprint 1; your chart continues to week 14 and adds the labs)

gantt
  title ITC Club Hub · iteration plan (excerpt, weeks 5 to 10)
  dateFormat YYYY-MM-DD
  axisFormat %d %b
  tickInterval 1week
  weekday monday
  excludes weekends
  section Requirements
    Elicitation interview with the client :req1, 2026-10-05, 5d
    SRS and product backlog               :req2, after req1, 5d
  section Models
    UML diagrams                          :mod1, 2026-10-19, 5d
  section Checkpoint
    Midterm exam week                     :crit, exam, 2026-10-26, 5d
    Checkpoint 1                          :milestone, cp1, 2026-10-30, 0d
  section Sprint 1
    Sprint 1 planning                     :milestone, s1p, 2026-11-02, 0d
    Sprint 1 development                  :s1, 2026-11-02, 10d
    Sprint 1 review and retrospective     :milestone, s1r, 2026-11-13, 0d

| Iteration | Weeks | Goal | Candidate features | Capacity | Exit criterion |
|-----------|-------|------|--------------------|----------|----------------|
| Sprint 1  | 9-10  | A student can browse upcoming events and register from the CLI | browse, register (capacity, no duplicates) | 5 × 6 × 2 × 0.8 = 48 h | stories demoed to the TA, tests green in CI |

Show hints

Acceptance checklist

Goal

Decide, for each technical need of the Club Hub core, whether to reuse, build or defer; add the reused libraries to CMakeLists.txt with FetchContent and pinned versions; prove with a small GoogleTest smoke test that they build and link; then record what changed in lab04/README.md.

Steps

1. Create lab04/reuse-inventory.md with a make-or-reuse table of at least eight needs: unit testing, file storage (CSV or JSON, as decided in Lab-02), date and time (24-hour rule), CLI input handling, the registration rules, reminders, the monthly report, logging. Columns: need, options considered, decision (Reuse, Build, Defer), reason, licence, pinned version, evidence the project is maintained (date of the last release).
2. Add a licence check: for each reused library state whether its licence is compatible with your repository licence from Lab-03 (for example BSD-3-Clause and MIT libraries are fine in an MIT repository; explain what a GPL library would require).
3. Update CMakeLists.txt using the starter: FetchContent_Declare for GoogleTest (keep it if an earlier lab added it) and for your storage library, pinned to a release tag or archive URL, then FetchContent_MakeAvailable, enable_testing() and gtest_discover_tests.
4. Add tests/data/events.csv and tests/csv_smoke_test.cpp from the starters (JSON teams: see the hints). The test reads two events through the reused library and checks a title and a capacity.
5. Build from a clean build folder and run the tests: cmake -S . -B build && cmake --build build && ctest --test-dir build --output-on-failure. Paste the CTest summary into a Verification section of the inventory, with the compiler and CMake versions.
6. Commit the build changes as the developer who made them: Lab-04 task 5: FetchContent GoogleTest and rapidcsv, smoke test.
7. Record what changed: the Product Owner creates lab04/README.md from the starter with the table of every Lab-04 file (task and one-line description), the table Inputs reused listing lab01/team-charter.md, lab01/problem-statement.md, lab02/application-type.md and LICENSE with the commit hash you used (git log -1 --format=%h -- <file>), the dependencies added with their versions, and a change-log row. Commit Lab-04 task 5: record what changed, push the branch and open the pull request.

Starter: CMakeLists.txt (complete; merge with yours if it exists)

cmake_minimum_required(VERSION 3.28)
project(ClubHub VERSION 0.4.0 LANGUAGES CXX)

set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF)

include(FetchContent)

# Reuse 1: GoogleTest (BSD-3-Clause), unit-test framework.
FetchContent_Declare(googletest
  URL https://github.com/google/googletest/archive/refs/tags/v1.17.0.zip
  DOWNLOAD_EXTRACT_TIMESTAMP TRUE)
# MSVC: link GoogleTest with the same C runtime as our code
set(gtest_force_shared_crt ON CACHE BOOL "" FORCE)

# Reuse 2: rapidcsv (BSD-3-Clause), header-only CSV reader.
# TODO: check the newest release tag on the project page and pin it.
FetchContent_Declare(rapidcsv
  GIT_REPOSITORY https://github.com/d99kris/rapidcsv.git
  GIT_TAG        v8.84
  GIT_SHALLOW    TRUE)

FetchContent_MakeAvailable(googletest rapidcsv)

enable_testing()
include(GoogleTest)

# Smoke test: proves that the reused library is fetched, built and linked
add_executable(csv_smoke_test tests/csv_smoke_test.cpp)
target_link_libraries(csv_smoke_test PRIVATE rapidcsv GTest::gtest_main)
gtest_discover_tests(csv_smoke_test
  WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR})

# Later labs: add_library(clubhub_core ...) and add_executable(clubhub ...)

Starter: tests/csv_smoke_test.cpp and tests/data/events.csv

// tests/csv_smoke_test.cpp
// Proves that the reused CSV library is fetched, built and linked.
#include <gtest/gtest.h>
#include <rapidcsv.h>

#include <string>
#include <vector>

TEST(CsvSmokeTest, ReadsEventTitlesAndCapacities) {
    // the path is relative to WORKING_DIRECTORY (the repository root)
    rapidcsv::Document doc("tests/data/events.csv");

    const std::vector<std::string> titles =
        doc.GetColumn<std::string>("title");
    const std::vector<int> capacities = doc.GetColumn<int>("capacity");

    ASSERT_EQ(titles.size(), 2U);
    EXPECT_EQ(titles.at(0), "Robotics Workshop");
    EXPECT_EQ(capacities.at(1), 30);
}

id,title,start,location,capacity,club_id
E001,Robotics Workshop,2026-11-07T14:00,Building I room 201,25,C01
E002,Hackathon Night,2026-11-13T18:00,Innovation Lab,30,C02

Starter: lab04/README.md

# Lab-04 · Software Development Processes · Team <name>

## Files of this lab
| File                          | Task | Description                          |
|-------------------------------|------|--------------------------------------|
| fundamental-activities.md     | 1    | ...                                  |
| scores/*.md                   | 2    | individual scores, one per member    |
| process-comparison.md         | 2    | ...                                  |
| process-decision.md, process.mmd | 3 | PDR-001 and the process diagram     |
| iteration-plan.md             | 4    | ...                                  |
| reuse-inventory.md            | 5    | ...                                  |
| ../CMakeLists.txt             | 5    | FetchContent: googletest v1.17.0, rapidcsv v8.84 |
| ../tests/csv_smoke_test.cpp, ../tests/data/events.csv | 5 | smoke test |

## Inputs reused
| Input               | File                       | Version (commit) |
|---------------------|----------------------------|------------------|
| Team charter        | lab01/team-charter.md      | ______           |
| Problem statement   | lab01/problem-statement.md | ______           |
| Application type    | lab02/application-type.md  | ______           |
| Repository licence  | LICENSE                    | ______           |

## Change log
| Date       | Change                                               | By     |
|------------|------------------------------------------------------|--------|
| 2026-__-__ | Lab-04: PDR-001 accepted, iteration plan, reuse ...  | <name> |

Expected output

$ cmake -S . -B build && cmake --build build && ctest --test-dir build --output-on-failure
-- Populating googletest ... rapidcsv ...
[100%] Built target csv_smoke_test
Test project C:/Users/dara/clubhub/build
    Start 1: CsvSmokeTest.ReadsEventTitlesAndCapacities
1/1 Test #1: CsvSmokeTest.ReadsEventTitlesAndCapacities ...   Passed    0.01 sec

100% tests passed, 0 tests failed out of 1

| Need               | Options                    | Decision | Reason                                  | Licence      | Version | Last release |
|--------------------|----------------------------|----------|-----------------------------------------|--------------|---------|--------------|
| Registration rules | none fits our rules        | Build    | unique to Club Hub, graded, must be tested | ours (MIT) | -       | -            |

Show hints

Acceptance checklist

1. Repository layout after this lab:

   clubhub/
   ├── CMakeLists.txt              # FetchContent: googletest, rapidcsv (or nlohmann_json)
   ├── LICENSE
   ├── include/clubhub/            # (CancellationPolicy.hpp if you did the challenge)
   ├── src/
   ├── tests/
   │   ├── csv_smoke_test.cpp
   │   └── data/events.csv
   ├── lab01/ lab02/ lab03/
   └── lab04/
       ├── README.md
       ├── fundamental-activities.md
       ├── scores/*.md
       ├── process-comparison.md
       ├── process-decision.md
       ├── process.mmd
       ├── iteration-plan.md
       ├── reuse-inventory.md
       ├── v-model-trace.md        # challenge
       └── cmmi-reflection.md      # challenge

2. Self-check from a clean checkout (the build must pass and at least one test must run):

   git clone <your-repo-url> check && cd check && git switch lab-04
   cmake -S . -B build && cmake --build build && ctest --test-dir build
   git log --format='%an' lab-04 -- lab04 | sort | uniq -c   # every member listed?

3. Also check on GitHub that the Mermaid diagrams in process-decision.md and iteration-plan.md render in the file view.
4. Branch lab-04, pull request titled Lab-04 – <team name>, reviewed by at least one other member before the deadline; add the instructor or teaching assistant as reviewer.