Plan the Hirst painting project and review the plan documents
Add the Business Case (BC-001), Stakeholder Analysis (SA-001), Project Plan (PP-001) and two milestones: MIL-001 Colour Palette and MIL-002 Spot Painting. Record their reviews as RC-001 to RC-004 (all Go, self-review accepted by S01). The PO language is English and the domain is IT. The milestones and their 13 tasks are synced as Gitea milestones 68 and 69 and issues #1 to #13.
This commit is contained in:
@@ -0,0 +1,58 @@
|
||||
# Artifact Registry
|
||||
|
||||
This project's artifact state. Types, short names and `CrossReference
|
||||
Candidates` come from the framework catalog
|
||||
(`framework/registry/artifact-catalog.md`); this file only records where
|
||||
each document lives in *this* project and the next version to use.
|
||||
|
||||
Delete rows for types you don't use. Add a row the first time you create a
|
||||
document of a type. `Primary File` may contain a glob (e.g.
|
||||
`docs/uc-*/uc.md`); `framework/scripts/find-crossreferences.sh` reads it.
|
||||
|
||||
| Short Name | Artifact Type | Primary File | Next Available Version |
|
||||
| --- | --- | --- | --- |
|
||||
| BC | Business Case | docs/business-case.md | 002 |
|
||||
| SA | Stakeholder Analysis | docs/stakeholder-analysis.md | 002 |
|
||||
| PP | Project Plan | docs/project-plan.md | 002 |
|
||||
| MIL | Milestone / Gateway | docs/milestones/*.md | 003 |
|
||||
| RC | SQA Review Record | docs/sqa/reviews/rc-*.md | 005 |
|
||||
|
||||
## Languages
|
||||
|
||||
Set the PO language when the project starts; `project-planning` asks for it
|
||||
if it is missing. An artifact of a type marked "Written in the PO language"
|
||||
exists once, in that language, under its normal name (`business-case.md`); the
|
||||
`artifact` skill ("One file per artifact") has the rule.
|
||||
|
||||
| Setting | Value |
|
||||
| --- | --- |
|
||||
| PO language | en |
|
||||
| PO domain | it |
|
||||
| High-level register | IT Executive English |
|
||||
| Technical register | IT Professional English |
|
||||
|
||||
Every artifact of a type marked "Yes" below states its language and domain in
|
||||
its `Language` and `Domain` Metadata rows; `new-artifact.sh` fills them from
|
||||
`PO language` and `PO domain`. `Language` is a BCP 47 code (`da`, `en`).
|
||||
`Domain` is a value from this list; add a row to introduce a domain, so a
|
||||
reviewer can see at once which professional vocabulary a document uses.
|
||||
|
||||
| Domain | Meaning |
|
||||
| --- | --- |
|
||||
| it | Software and IT |
|
||||
| medical | Healthcare and medical devices |
|
||||
| construction | Construction and civil engineering |
|
||||
|
||||
| Artifact types | Register | Written in the PO language |
|
||||
| --- | --- | --- |
|
||||
| BC, KPI, PP, MIL | IT Executive English | Yes |
|
||||
| SA, BMC, BPMN, UCD, US, UC, SSD, DM, RA, GOV, DICT | IT Professional English | Yes |
|
||||
| OC, SD, DCD, ERD, ADR, TM, RC, QC, source code | IT Professional English | No |
|
||||
|
||||
## Notes
|
||||
|
||||
- "Next Available Version" is the zero-padded (3-digit) version to use the
|
||||
*next* time a new document of that type is created. Increment it only when
|
||||
a brand-new document is created, not when an existing document's
|
||||
`## Version History` gets a row.
|
||||
- `ADR` uses 4 digits (`0001`); `RC` is sequential across all artifact types.
|
||||
@@ -0,0 +1,169 @@
|
||||
# Business Case: Hirst Painting (Spot Painting with Turtle)
|
||||
|
||||
## Metadata
|
||||
| Key | Value |
|
||||
| --- | --- |
|
||||
| ID | BC-001 |
|
||||
| CrossReference | [SA-001] |
|
||||
| Language | en |
|
||||
| Domain | it |
|
||||
|
||||
## Version History
|
||||
| Date | Status | Author | Reviewer | Change | Commit |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| 2026-10-07 | Accepted | Jens Tirsvad Nielsen | S01 | Initial version | pending |
|
||||
|
||||
---
|
||||
|
||||
## Executive Summary
|
||||
|
||||
Day 18 of the 100 Days of Code course asks for a Python program that draws a
|
||||
Hirst-style spot painting with the standard `turtle` module: a 10 by 10 grid of
|
||||
round dots, each coloured at random from a palette taken from a reference image
|
||||
with the `colorgram` library. The work is small and self-contained. This
|
||||
business case proposes to deliver it as one script in two phases (palette, then
|
||||
painting) under the software quality assurance and quality control (SQA and QC) framework, so that the exercise doubles as a
|
||||
proportionate practice run of the plan-first workflow. The proposal is to
|
||||
proceed.
|
||||
|
||||
## Methodological and Standards Foundation
|
||||
|
||||
- **Method:** the framework's plan-first workflow (Business Case, Stakeholder
|
||||
Analysis, Project Plan, milestones, tasks as issues, code), with analysis and
|
||||
design artifacts in the style of Larman's *Applying UML and Patterns*; only
|
||||
the artifacts the work needs are created.
|
||||
- **Quality standards:** every quality criterion is tagged with an ISO/IEC
|
||||
25010:2023 characteristic. The code is reviewed against `qc-programming-python`
|
||||
before the pull request.
|
||||
- **Source requirements:** the course lecture "The Hirst Painting Project
|
||||
Part 2 - Drawing the Dots" (a written summary of the lecture is the only
|
||||
source supplied; the reference image is not).
|
||||
|
||||
## Problem Statement
|
||||
|
||||
The course exercise has no working implementation in this repository yet.
|
||||
Without one, the loops, the `turtle` positioning logic and the colour handling
|
||||
taught in the lecture stay theory. The lecture itself names the usual
|
||||
failures: a visible trail between dots, a missing last dot, white shades in
|
||||
the palette that make dots invisible, and a slow, visibly drawing turtle.
|
||||
|
||||
## Business Opportunity
|
||||
|
||||
A finished and reviewed implementation gives S01 verified
|
||||
practice of loops, `random`, third-party library use and `turtle` positioning,
|
||||
and it shows the plan-first workflow applied to a deliberately small project,
|
||||
so the effort the framework adds can be judged against the size of the work.
|
||||
|
||||
## Objectives
|
||||
|
||||
| # | Objective |
|
||||
| --- | --- |
|
||||
| O1 | Draw a 10 by 10 grid of 100 dots, each of size 20, with the centres of neighbouring dots 50 units apart. |
|
||||
| O2 | Build the colour palette from a reference image with `colorgram`, excluding white shades. |
|
||||
| O3 | Colour every dot by a random choice from that palette. |
|
||||
| O4 | Keep the finished painting on screen until the user clicks, and present it cleanly: turtle hidden, no trail between dots. |
|
||||
| O5 | Deliver the work through the framework: plan and issues first, then code reviewed against `qc-programming-python` (`RC-*` verdict `Go`) before the pull request. |
|
||||
|
||||
## Scope
|
||||
|
||||
### In Scope
|
||||
|
||||
- One Python program using the standard `turtle` module, the `random` module and the `colorgram` library.
|
||||
- Extraction of the palette from one reference image, with white shades removed.
|
||||
- Drawing of the 10 by 10 dot grid: dot size, spacing, row change and heading handling.
|
||||
- Screen handling: `exitonclick`, hiding the turtle, pen up between dots, drawing speed.
|
||||
- The framework documents the plan-first workflow requires for this work (Business Case, Stakeholder Analysis, Project Plan, milestones), and the review records for them and for the code.
|
||||
|
||||
### Out of Scope
|
||||
|
||||
- Any grid size, dot size or spacing other than the values in O1, and any user-configurable parameters.
|
||||
- A graphical interface, command-line options, or saving the painting to an image file.
|
||||
- Packaging or publishing the program as a library or application.
|
||||
- Painting any image other than the dot grid.
|
||||
- Use cases, domain models, class and database designs: the program has no persistent data and no user interaction beyond the exit click.
|
||||
|
||||
## Expected Benefits
|
||||
|
||||
### Tangible Benefits
|
||||
|
||||
- A working program that produces the painting described in O1 to O4.
|
||||
- A reviewed codebase with a recorded review (`RC-*`) against the Python checklist.
|
||||
- A traceable record from objective to milestone to issue to code.
|
||||
|
||||
### Intangible Benefits
|
||||
|
||||
- Practice with loops, random selection, library use and `turtle` positioning.
|
||||
- Experience of how much framework process a small project needs.
|
||||
|
||||
## Strategic Alignment
|
||||
|
||||
The project completes one exercise of the 100 Days of Code course, which is
|
||||
S01's learning goal for this repository, and it exercises the SQA and QC
|
||||
framework that the repository is built on.
|
||||
|
||||
## Success Criteria
|
||||
|
||||
| # | Criterion | Target | Measure |
|
||||
| --- | --- | --- | --- |
|
||||
| SC1 | Number and layout of dots (O1) | Exactly 100 dots, in 10 rows of 10 | Count of dot calls in a run, and visual check of the window |
|
||||
| SC2 | Dot size and spacing (O1) | Dot size 20; 50 units between neighbouring centres, in rows and in columns | Constants in the code, and visual check |
|
||||
| SC3 | Palette content (O2) | At least 2 colours, and 0 colours with red, green and blue all at 240 or above | Print of the extracted palette checked against the threshold (value confirmed by S01) |
|
||||
| SC4 | Colour choice (O3) | Every dot colour is a member of the palette | Check in code review |
|
||||
| SC5 | Clean result (O4) | Turtle hidden at the end; no line drawn between dots; window stays open until a click | Visual check of one full run |
|
||||
| SC6 | Run time (O4) | The full painting is drawn in 30 seconds or less | Timed run on the developer machine (value confirmed by S01) |
|
||||
| SC7 | Review gate (O5) | `RC-*` for the code has verdict `Go`; the pull request closes every issue it completes | Review record and pull request description |
|
||||
|
||||
## Risks
|
||||
|
||||
| Risk | Impact | Mitigation |
|
||||
| --- | --- | --- |
|
||||
| The reference image is not available to the project | Palette cannot be extracted from the source the lecture uses | Ask S01 for the image before the palette phase starts; if it stays unavailable, S01 decides on another image and the change is recorded in the milestone |
|
||||
| `colorgram` or the `turtle` graphical toolkit (Tk) cannot be installed or does not run on the developer machine | The program cannot be run or checked | Check both in the first task of the palette phase, before any other work depends on them |
|
||||
| White or near-white shades stay in the palette | Dots are invisible on the white background, so SC1 looks failed | SC3 sets an explicit threshold and is checked on the printed palette |
|
||||
| Off-by-one errors: last dot of a row or the last row missing, or a trail drawn | SC1 or SC5 fails | SC1 counts the dots and SC5 checks for a trail; both are verified in the code review |
|
||||
| Framework process outweighs the size of the work | Schedule slips and the exercise stops being a small one | Keep to two phases and plain tasks; no use cases or design artifacts (see Out of Scope) |
|
||||
| The only named reviewer is also the author | Reviews are not independent, as the review process requires | S01 accepted a documented self-review on 2026-10-07; each review record states it |
|
||||
|
||||
## Assumptions
|
||||
|
||||
- The Product Owner (S01) is the author, the owner of every phase, and the person who accepts the work.
|
||||
- Python 3 with Tk support is available on the developer machine, and `colorgram` can be installed with `pip`.
|
||||
- The reference image is supplied by S01 from the course material.
|
||||
- The lecture summary is a faithful statement of the required behaviour.
|
||||
- The phases are completed within one week of the start date, 2026-10-07 (confirmed by S01).
|
||||
|
||||
## Constraints
|
||||
|
||||
- Only the standard `turtle` and `random` modules plus `colorgram` are used.
|
||||
- The program is one source file under `src/`; its tests, if any, are under `tests/`.
|
||||
- No code is written until a milestone is `Accepted`, has a review record with verdict `Go`, and the task is a row in it (plan-first gate).
|
||||
- Nothing is committed, pushed or opened as a pull request unless S01 asks.
|
||||
- Project documents are written in English (PO language `en`, domain `it`).
|
||||
|
||||
## Cost–Benefit Assessment
|
||||
|
||||
The assessment is qualitative on purpose: this is a learning exercise with no
|
||||
revenue, so a monetary return would be invented. The cost is S01's
|
||||
time; the tools are free.
|
||||
|
||||
| Costs | Benefits |
|
||||
| --- | --- |
|
||||
| S01's time for the documents, reviews and code (hours, not tracked) | Working painting program meeting SC1 to SC6 |
|
||||
| No licence or infrastructure cost (Python, `turtle`, `colorgram`) | Verified practice of the lecture's techniques |
|
||||
| Overhead of the framework documents relative to a one-script program | Experience of the plan-first workflow at the smallest practical size |
|
||||
|
||||
## Stakeholders
|
||||
|
||||
Roles, power and interest are in [SA-001]; they are not repeated here.
|
||||
|
||||
| Stakeholder ID (SA) | Interest in this project |
|
||||
| --- | --- |
|
||||
| S01 | Owner of all objectives (O1 to O5); accepts the work and answers the open questions above |
|
||||
|
||||
## Recommendation
|
||||
|
||||
Proceed — the work is small, the cost is only S01's time, and every objective can be verified against an explicit target.
|
||||
|
||||
---
|
||||
|
||||
[SA-001]: ./stakeholder-analysis.md
|
||||
@@ -0,0 +1,83 @@
|
||||
# MIL-001: Colour Palette
|
||||
|
||||
## Metadata
|
||||
| Key | Value |
|
||||
| --- | --- |
|
||||
| ID | MIL-001 |
|
||||
| CrossReference | [BC-001] |
|
||||
| Language | en |
|
||||
| Domain | it |
|
||||
|
||||
## Version History
|
||||
| Date | Status | Author | Reviewer | Change | Commit |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| 2026-10-07 | Accepted | Jens Tirsvad Nielsen | S01 | Initial version | pending |
|
||||
|
||||
---
|
||||
|
||||
## Purpose
|
||||
|
||||
This gate decides whether the colour palette is usable, so that the painting
|
||||
phase can build on it. The palette must come from the reference image through
|
||||
`colorgram`, must contain no white shades, and the toolchain it depends on
|
||||
(`colorgram` and the `turtle` graphical toolkit) must work on the developer
|
||||
machine.
|
||||
|
||||
## Deliverable
|
||||
|
||||
A palette function in the program's source file under `src/` that reads the
|
||||
reference image with `colorgram`, drops white shades and returns the remaining
|
||||
colours as RGB tuples, together with the tests that check it and the printed
|
||||
palette of the real image.
|
||||
|
||||
## Go / No-Go Criteria
|
||||
|
||||
| # | Criterion (objectively checkable) | Go | No-Go |
|
||||
| --- | --- | --- | --- |
|
||||
| 1 | `import colorgram` and `import turtle` succeed and a `turtle` window opens on the developer machine | Both imports succeed and the window opens | An import fails or no window opens |
|
||||
| 2 | The palette of the reference image has at least 2 colours (SC3) | 2 or more colours printed | 0 or 1 colour |
|
||||
| 3 | The palette has no colour with red, green and blue all at 240 or above (SC3) | 0 such colours in the printed palette | 1 or more such colours |
|
||||
| 4 | The tests of the white-shade filter and of the palette pass | All tests pass | Any test fails |
|
||||
| 5 | The phase code has a review record against `qc-programming-python` with verdict `Go` (SC7) | `RC-*` verdict `Go` | `Go-with-conditions` or `No-Go`, or no record |
|
||||
|
||||
## Dependencies
|
||||
|
||||
| Depends on | Reason |
|
||||
| --- | --- |
|
||||
| None | The baseline documents are `Accepted`; this is the first gateway |
|
||||
|
||||
## Traceability
|
||||
|
||||
| Business Case objective / KPI / user story | Reference |
|
||||
| --- | --- |
|
||||
| O2: palette from a reference image with `colorgram`, without white shades | [BC-001]; criteria 1 to 4 and SC3 |
|
||||
| O5: delivery through the framework, code reviewed against `qc-programming-python` | [BC-001]; criterion 5 and SC7 |
|
||||
|
||||
No use case or user story applies: every task is a technical step, so the
|
||||
Tasks column "Needs its own Use Case/User Story?" says `No` throughout.
|
||||
|
||||
## Ownership
|
||||
|
||||
| Role | Stakeholder ID (SA) |
|
||||
| --- | --- |
|
||||
| Owner | S01 |
|
||||
| Approving reviewer | S01 |
|
||||
|
||||
## Target Date
|
||||
|
||||
2026-10-09 — inside the one-week limit of [BC-001] (2026-10-07 to 2026-10-14), and leaves five days for the painting phase.
|
||||
|
||||
## Tasks
|
||||
|
||||
| # | Task | Summary | Needs its own Use Case/User Story? | Reference |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 1 | Check the toolchain | Confirm that Python 3 with Tk (the graphical toolkit behind `turtle`) runs `import turtle` and opens a window, install `colorgram` with `pip`, and record the versions. The Business Case lists a missing toolchain as a risk, so this comes before any other work depends on it. | No | |
|
||||
| 2 | Write the white-shade filter | Write a function that drops every colour whose red, green and blue are all at or above 240; the threshold is a named constant (SC3 of the Business Case). It needs no image, so it can be written and tested first. | No | |
|
||||
| 3 | Add tests for the white-shade filter | Add tests under `tests/` that feed the filter synthetic colours (pure white, near-white, an ordinary colour) and check which are kept. They pin down the threshold before the real image is involved. | No | |
|
||||
| 4 | Get the reference image into the project | S01 supplies the reference image the lecture uses; store it in the repository and note its path. Without it the palette cannot be extracted, and the location is an open issue of the Project Plan. | No | |
|
||||
| 5 | Write the palette extraction and check the palette | Write a function that reads the image with `colorgram`, turns each extracted colour into a red-green-blue (RGB) tuple, applies the filter and returns the list (O2). Print the palette of the real image and check it against SC3: at least 2 colours and no white shade. The painting phase imports this function. | No | |
|
||||
| 6 | Review the phase code against qc-programming-python | Check the code of this phase against `framework/qc/qc-programming-python.md` and record the result as an `RC-*`; a `Go` verdict is Go criterion 5 (SC7). | No | |
|
||||
|
||||
---
|
||||
|
||||
[BC-001]: ../business-case.md
|
||||
@@ -0,0 +1,86 @@
|
||||
# MIL-002: Spot Painting
|
||||
|
||||
## Metadata
|
||||
| Key | Value |
|
||||
| --- | --- |
|
||||
| ID | MIL-002 |
|
||||
| CrossReference | [BC-001] |
|
||||
| Language | en |
|
||||
| Domain | it |
|
||||
|
||||
## Version History
|
||||
| Date | Status | Author | Reviewer | Change | Commit |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| 2026-10-07 | Accepted | Jens Tirsvad Nielsen | S01 | Initial version | pending |
|
||||
|
||||
---
|
||||
|
||||
## Purpose
|
||||
|
||||
This gate decides whether the program draws the finished painting as the
|
||||
Business Case requires: a 10 by 10 grid of 100 dots of size 20 spaced 50 units
|
||||
apart, each coloured at random from the palette, left on screen until a click,
|
||||
with the turtle hidden and no trail between dots, and drawn in 30 seconds or
|
||||
less.
|
||||
|
||||
## Deliverable
|
||||
|
||||
The runnable program in the single source file under `src/`, using the palette
|
||||
function of the colour palette phase, together with its tests and one timed run
|
||||
that shows the finished painting.
|
||||
|
||||
## Go / No-Go Criteria
|
||||
|
||||
| # | Criterion (objectively checkable) | Go | No-Go |
|
||||
| --- | --- | --- | --- |
|
||||
| 1 | The painting has exactly 100 dots in 10 rows of 10 (SC1) | 100 dots counted in the tests and in the window | Any other count, or a missing last dot or row |
|
||||
| 2 | Dot size is 20 and neighbouring centres are 50 units apart in rows and in columns (SC2) | Values match in the code, the tests and the window | Any other size or spacing |
|
||||
| 3 | Every dot colour is a member of the palette (SC4) | The test passes for all 100 dots | A colour outside the palette |
|
||||
| 4 | The turtle is hidden at the end, no line joins the dots, and the window stays open until a click (SC5) | All three seen in one full run | A visible turtle, a trail, or a window that closes by itself |
|
||||
| 5 | One full run draws the painting in 30 seconds or less (SC6) | 30 seconds or less by stopwatch | More than 30 seconds |
|
||||
| 6 | The phase code has a review record against `qc-programming-python` with verdict `Go` (SC7) | `RC-*` verdict `Go` | `Go-with-conditions` or `No-Go`, or no record |
|
||||
|
||||
## Dependencies
|
||||
|
||||
| Depends on | Reason |
|
||||
| --- | --- |
|
||||
| MIL-001 | The painting draws with the palette function that phase delivers, and starts only after it has a `Go` decision |
|
||||
|
||||
## Traceability
|
||||
|
||||
| Business Case objective / KPI / user story | Reference |
|
||||
| --- | --- |
|
||||
| O1: 10 by 10 grid of dots, size 20, spacing 50 | [BC-001]; criteria 1 and 2, SC1 and SC2 |
|
||||
| O3: random colour from the palette for every dot | [BC-001]; criterion 3, SC4 |
|
||||
| O4: painting kept on screen and presented cleanly | [BC-001]; criteria 4 and 5, SC5 and SC6 |
|
||||
| O5: delivery through the framework, code reviewed against `qc-programming-python` | [BC-001]; criterion 6, SC7 |
|
||||
|
||||
No use case or user story applies: every task is a technical step, so the
|
||||
Tasks column "Needs its own Use Case/User Story?" says `No` throughout.
|
||||
|
||||
## Ownership
|
||||
|
||||
| Role | Stakeholder ID (SA) |
|
||||
| --- | --- |
|
||||
| Owner | S01 |
|
||||
| Approving reviewer | S01 |
|
||||
|
||||
## Target Date
|
||||
|
||||
2026-10-14 — the last day of the one-week limit of [BC-001] (2026-10-07 to 2026-10-14).
|
||||
|
||||
## Tasks
|
||||
|
||||
| # | Task | Summary | Needs its own Use Case/User Story? | Reference |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 1 | Set up the screen and the turtle | Create the screen and the turtle, switch to the 255-level red-green-blue (RGB) colour mode so the palette tuples work, hide the turtle and lift the pen. This removes the cursor and the trail from the result (O4, SC5). | No | |
|
||||
| 2 | Compute the dot positions | Write a function that returns the 100 dot centres for 10 rows of 10 with 50 units between neighbours, starting from a corner chosen so the whole grid fits in the window. It draws nothing, so tests can check the count and the spacing without a window (O1, SC1, SC2). | No | |
|
||||
| 3 | Draw the dots with random palette colours | Move to each position with the pen up and draw a dot of size 20 coloured by `random.choice` over the palette from the colour palette phase (O1, O3). The last dot of every row and the last row must be drawn, which the lecture names as a common mistake. | No | |
|
||||
| 4 | Keep the window open until a click | End the program with `exitonclick` so the finished painting stays on screen until the user clicks (O4, SC5). | No | |
|
||||
| 5 | Speed up the drawing | Set the turtle speed, or turn off screen updates until the end, so the full painting is drawn in 30 seconds or less, and time one full run (SC6). | No | |
|
||||
| 6 | Add tests for the geometry and the colours | Add tests under `tests/` that check 100 positions in 10 rows of 10, a spacing of 50 in rows and in columns, and that every colour picked is in the palette (SC1, SC2, SC4). | No | |
|
||||
| 7 | Review the phase code and check the painting | Check the code of this phase against `framework/qc/qc-programming-python.md` and record the result as an `RC-*`; then run the program once and check criteria 1 to 5 against it (SC7). | No | |
|
||||
|
||||
---
|
||||
|
||||
[BC-001]: ../business-case.md
|
||||
@@ -0,0 +1,92 @@
|
||||
# Project Plan: Hirst Painting
|
||||
|
||||
## Metadata
|
||||
| Key | Value |
|
||||
| --- | --- |
|
||||
| ID | PP-001 |
|
||||
| CrossReference | [BC-001], [SA-001], [MIL-001], [MIL-002] |
|
||||
| Language | en |
|
||||
| Domain | it |
|
||||
|
||||
## Version History
|
||||
| Date | Status | Author | Reviewer | Change | Commit |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| 2026-10-07 | Accepted | Jens Tirsvad Nielsen | S01 | Initial version | pending |
|
||||
|
||||
---
|
||||
|
||||
## Purpose
|
||||
|
||||
This plan schedules the two phases of the Hirst painting project, the colour
|
||||
palette and the spot painting, inside the one-week limit that [BC-001] sets
|
||||
(2026-10-07 to 2026-10-14). Each phase is a gateway with its own milestone
|
||||
document, and each gateway ends with a Go/No-Go decision by S01.
|
||||
|
||||
## Planning Assumptions
|
||||
|
||||
- Week 1 starts 2026-10-07; the plan ends by 2026-10-14, per the Business Case assumption confirmed by S01.
|
||||
- The baseline documents ([BC-001], [SA-001] and their review records) are finished on 2026-10-07, before the first phase starts.
|
||||
- Phase length: two to five days, because the work is one small script. The palette phase is shorter because it is the smaller of the two.
|
||||
- S01 owns both phases and takes both Go/No-Go decisions; S01 is the only stakeholder in [SA-001], so communication follows the review gates in that document.
|
||||
- No user stories exist: the program has no user interaction beyond the exit click, so the Stories column is empty.
|
||||
|
||||
## Gateway Schedule
|
||||
|
||||
| Gateway | Document | Window | Decision date | Owner | Stories | Main deliverable | Milestone |
|
||||
| --- | --- | --- | --- | --- | --- | --- | --- |
|
||||
| Colour palette | [MIL-001] | 2026-10-07 to 2026-10-09 | 2026-10-09 | S01 | none | Palette function that returns the reference image's colours without white shades | [MIL-001 milestone] |
|
||||
| Spot painting | [MIL-002] | 2026-10-10 to 2026-10-14 | 2026-10-14 | S01 | none | Program that draws the 10 by 10 painting and meets SC1 to SC7 of [BC-001] | [MIL-002 milestone] |
|
||||
|
||||
```plantuml
|
||||
@startgantt
|
||||
Project starts 2026-10-07
|
||||
[Colour palette] starts 2026-10-07 and ends 2026-10-09
|
||||
[Colour palette Go/No-Go] happens 2026-10-09
|
||||
[Spot painting] starts 2026-10-10 and ends 2026-10-14
|
||||
[Spot painting Go/No-Go] happens 2026-10-14
|
||||
@endgantt
|
||||
```
|
||||
|
||||
## Scope Coverage
|
||||
|
||||
| Business Case scope item | Gateway |
|
||||
| --- | --- |
|
||||
| One Python program using `turtle`, `random` and `colorgram` | [MIL-001] (`colorgram` part), [MIL-002] (`turtle` and `random` part) |
|
||||
| Palette extracted from one reference image, white shades removed | [MIL-001] |
|
||||
| Drawing the 10 by 10 dot grid: size, spacing, row change, heading | [MIL-002] |
|
||||
| Screen handling: `exitonclick`, hidden turtle, pen up, drawing speed | [MIL-002] |
|
||||
| Framework documents and review records for the plan-first workflow | Finished before the first gateway ([BC-001], [SA-001], this plan, [MIL-001], [MIL-002] and their reviews); the review of each phase's code is a task in that phase |
|
||||
|
||||
## Dependencies
|
||||
|
||||
```
|
||||
Baseline documents → [MIL-001] Colour palette → [MIL-002] Spot painting
|
||||
```
|
||||
|
||||
[MIL-002] needs the palette function from [MIL-001]. A No-Go on [MIL-001] moves
|
||||
the start of [MIL-002] by the days needed to rework and re-review; the
|
||||
one-week limit then has no slack, so S01 decides whether to extend it.
|
||||
|
||||
## Plan Risks
|
||||
|
||||
| Risk | Impact | Mitigation |
|
||||
| --- | --- | --- |
|
||||
| The reference image is not supplied before the palette phase starts | [MIL-001] cannot start its extraction task; the window of two to three days is lost | The tasks that do not need the image (toolchain check, white filter and its tests) come first; S01 decides on another image if this one stays unavailable |
|
||||
| A No-Go on the palette phase | [MIL-002] starts late and the one-week limit is missed | The palette phase is the smaller one and ends 2026-10-09, leaving five days for the painting phase |
|
||||
| Review effort is large compared with the code | Time goes to documents instead of the program | Two phases, plain tasks, no use cases or design artifacts, as set out in [BC-001] |
|
||||
| The Project Plan has no quality checklist | The plan is accepted on S01's judgement alone | S01 checks the plan against the one-week limit of [BC-001] and the Go/No-Go criteria of both milestones |
|
||||
|
||||
## Open Issues
|
||||
|
||||
- **Reference image:** its location is still unknown. S01 supplies it before task 4 of [MIL-001].
|
||||
- **Project Plan review:** the Project Plan has no quality checklist yet, so it is `Accepted` when S01 says so in chat (done on 2026-10-07); no review record is written for it.
|
||||
- **Milestone links:** `sync-project.sh --apply` ran on 2026-10-07 and created the two Milestones and issues #1 to #13 on the git host; the Milestone column links to them.
|
||||
|
||||
---
|
||||
|
||||
[BC-001]: ./business-case.md
|
||||
[SA-001]: ./stakeholder-analysis.md
|
||||
[MIL-001]: ./milestones/mil-001-palette.md
|
||||
[MIL-002]: ./milestones/mil-002-painting.md
|
||||
[MIL-001 milestone]: https://git.tirsystem.com/Tirsvad-Udemy-100-days-of-code/018-hirst-painting/milestone/68
|
||||
[MIL-002 milestone]: https://git.tirsystem.com/Tirsvad-Udemy-100-days-of-code/018-hirst-painting/milestone/69
|
||||
@@ -0,0 +1,73 @@
|
||||
# Review Record: Business Case BC-001
|
||||
|
||||
## Metadata
|
||||
| Key | Value |
|
||||
| --- | --- |
|
||||
| ID | RC-001 |
|
||||
| CrossReference | [BC-001], [SA-001], [QC-BC-001], [QC-LANG-001] |
|
||||
|
||||
## Version History
|
||||
| Date | Status | Author | Reviewer | Change | Commit |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| 2026-10-07 | Accepted | Jens Tirsvad Nielsen | S01 | Initial version (draft prepared by the assistant for S01 to confirm)<br>Self-review and defaults confirmed by S01 | pending |
|
||||
|
||||
---
|
||||
|
||||
## Artifact Under Review
|
||||
|
||||
- Instance reviewed: [BC-001]
|
||||
- Checklist used: [QC-BC-001], together with [QC-LANG-001] because the Business Case is written in the PO language
|
||||
- Scope: full review
|
||||
- Language and domain: en / it (the artifact's Metadata rows)
|
||||
- Language reviewer: none. S01 reads English and knows the IT domain. S01 is also the author; S01 accepted a documented self-review on 2026-10-07 (Action Item 1)
|
||||
|
||||
**Status of this record:** final. The assistant read the document against
|
||||
every criterion and recorded what it found; S01 confirmed the open points on
|
||||
2026-10-07 and the verdict is `Go`.
|
||||
|
||||
## Checklist Results
|
||||
|
||||
| # | Criterion | Status | Evidence/Notes |
|
||||
| --- | --- | --- | --- |
|
||||
| 1 | ROI/Cost-Benefit analysis is quantitative, or where qualitative, is explicitly justified | Pass | Cost–Benefit Assessment states it is qualitative "on purpose: this is a learning exercise with no revenue, so a monetary return would be invented", and lists costs and benefits |
|
||||
| 2 | Risks are identified with documented impact and mitigation | Pass | Risks table has 6 rows; each has an Impact and a Mitigation |
|
||||
| 3 | Success criteria are measurable, stating explicit targets rather than vague aspirations | Pass | SC1 to SC7 each have a target and a measure. SC3 (colour threshold 240) and SC6 (30 seconds) were confirmed by S01 on 2026-10-07 (Action Item 3) |
|
||||
| 4 | Scope explicitly separates In Scope vs Out of Scope | Pass | `### In Scope` and `### Out of Scope` subsections, with distinct content |
|
||||
| 5 | Stakeholders are cross-referenced to Stakeholder Analysis IDs rather than re-described inline | Pass | Stakeholders table cites S01 and says roles are in [SA-001]. Prose refers to S01 by ID, not by role |
|
||||
| 6 | Methodology and quality-standard foundation are stated explicitly (e.g. ISO/IEC 25010, Larman) | Pass | "Methodological and Standards Foundation" names the plan-first workflow, Larman, ISO/IEC 25010:2023 and `qc-programming-python` |
|
||||
| 7 | Assumptions and constraints are explicit and clearly distinguished from one another | Pass | Separate `## Assumptions` and `## Constraints` lists. The one-week timeline is an assumption, confirmed by S01 on 2026-10-07 (Action Item 3) |
|
||||
| 8 | Document supports executive decision-making with a clear, unambiguous recommendation | Pass | Recommendation is a single "Proceed" with a one-sentence rationale |
|
||||
|
||||
## Language and Domain Results
|
||||
|
||||
| # | Criterion | Status | Evidence/Notes |
|
||||
| --- | --- | --- | --- |
|
||||
| 1 | The Metadata table has a `Language` row and a `Domain` row, and neither is a placeholder | Pass | The `Language` row says `en` and the `Domain` row says `it`; `check-languages.sh --list` reports both |
|
||||
| 2 | `Language` is a BCP 47 code and `Domain` is a value from the registry's domain list | Pass | `en` is a BCP 47 code; `it` is in the registry's domain list ("Software and IT") |
|
||||
| 3 | The content (prose and table cells) is written in the stated language | Pass | All prose and table cells are English; tool names (`turtle`, `colorgram`, `exitonclick`) are established technical terms |
|
||||
| 4 | The register matches the one the registry gives for the artifact type | Pass | Registry gives IT Executive English for BC. The text states decisions, targets and risks; implementation detail was removed from the risks table during drafting. Tool names stay where an objective needs them |
|
||||
| 5 | Domain terms are the PO terms of the domain's dictionary, with no synonyms | Pass | The project has no Domain Dictionary (`DICT`), so there is no list to check against; the terms *dot*, *palette*, *painting*, *grid* and *phase* are used consistently here and in [SA-001]. "Spot painting" is the name of the genre; the elements are always "dots". S01 confirmed on 2026-10-07 that a dictionary is not needed (Action Item 2) |
|
||||
| 6 | Metadata keys, section headings, IDs and statuses are in English | Pass | Headings follow the BC reference exactly |
|
||||
| 7 | No translated twin (`<name>.<language>.md`) exists beside the document | Pass | Only `docs/business-case.md` exists |
|
||||
| 8 | A change of language or domain since the previous accepted version has a Version History row and was reviewed again | N-A | First version; there is no previous accepted version |
|
||||
| 9 | A reviewer competent in the domain, and in the language, has confirmed that the domain terms are used correctly | Pass | S01 confirmed on 2026-10-07 that the domain terms are used correctly (Action Item 2). S01 is also the author; the self-review was accepted by S01 (Action Item 1) |
|
||||
| 10 | Abbreviations are spelled out on first use, in the stated language | Pass | SQA and QC are spelled out in the Executive Summary; ISO/IEC, SC and O numbering are defined where introduced |
|
||||
|
||||
## Overall Verdict
|
||||
|
||||
Go — every criterion of [QC-BC-001] and of [QC-LANG-001] passes (criterion 8 of [QC-LANG-001] is N-A for a first version). S01 accepted the documented self-review, confirmed the defaults and the stakeholder list, and confirmed on 2026-10-07 that the domain terms are used correctly and that no Domain Dictionary is needed. All action items are closed.
|
||||
|
||||
## Action Items
|
||||
|
||||
| # | Action | Owner | Due |
|
||||
| --- | --- | --- | --- |
|
||||
| 1 | Name a reviewer who is not the author, or record here that the review is a documented self-review accepted by S01. **Closed 2026-10-07:** S01 accepted a documented self-review | S01 | 2026-10-09 |
|
||||
| 2 | Confirm that the domain terms in [BC-001] are used correctly (QC-LANG-001 criterion 9), and that a Domain Dictionary is not needed for this project. **Closed 2026-10-07:** S01 confirmed both points | S01 | 2026-10-09 |
|
||||
| 3 | Confirm or change the defaults in [BC-001]: one-week timeline from 2026-10-07, colour threshold 240 (SC3), 30-second run time (SC6); say where the reference image is. **Closed 2026-10-07 for the defaults:** S01 confirmed all three. The reference image location is still open; it is a risk of [BC-001] and goes to the Open Issues of the Project Plan | S01 | 2026-10-09 |
|
||||
|
||||
---
|
||||
|
||||
[BC-001]: ../../business-case.md
|
||||
[SA-001]: ../../stakeholder-analysis.md
|
||||
[QC-BC-001]: ../../../framework/qc/qc-business-case.md
|
||||
[QC-LANG-001]: ../../../framework/qc/qc-language-domain.md
|
||||
@@ -0,0 +1,73 @@
|
||||
# Review Record: Stakeholder Analysis SA-001
|
||||
|
||||
## Metadata
|
||||
| Key | Value |
|
||||
| --- | --- |
|
||||
| ID | RC-002 |
|
||||
| CrossReference | [SA-001], [BC-001], [QC-SA-001], [QC-LANG-001] |
|
||||
|
||||
## Version History
|
||||
| Date | Status | Author | Reviewer | Change | Commit |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| 2026-10-07 | Accepted | Jens Tirsvad Nielsen | S01 | Initial version (draft prepared by the assistant for S01 to confirm)<br>S02 removed on S01's instruction; self-review confirmed by S01 | pending |
|
||||
|
||||
---
|
||||
|
||||
## Artifact Under Review
|
||||
|
||||
- Instance reviewed: [SA-001]
|
||||
- Checklist used: [QC-SA-001], together with [QC-LANG-001] because the Stakeholder Analysis is written in the PO language
|
||||
- Scope: full review
|
||||
- Language and domain: en / it (the artifact's Metadata rows)
|
||||
- Language reviewer: none. S01 reads English and knows the IT domain. S01 is also the author; S01 accepted a documented self-review on 2026-10-07 (Action Item 1)
|
||||
|
||||
**Status of this record:** final. The assistant read the document against
|
||||
every criterion and recorded what it found; S01 confirmed the open points on
|
||||
2026-10-07 and the verdict is `Go`.
|
||||
|
||||
## Checklist Results
|
||||
|
||||
| # | Criterion | Status | Evidence/Notes |
|
||||
| --- | --- | --- | --- |
|
||||
| 1 | Power/Interest grid is filled for every stakeholder, with no gaps or unclassified entries | Pass | S01, the only stakeholder, is classified HIGH/HIGH, Manage Closely; the quadrant follows the standard grid |
|
||||
| 2 | Each stakeholder is assigned a unique, stable ID (e.g. S01-S11 style) reusable for RACI assignments in other artifacts | Pass | S01, unique; [BC-001] and the review records already cite it. S02 was removed on S01's instruction before any review gave `Go`, so no ID was reused |
|
||||
| 3 | Roles and organizational context are defined with explicit Power and Interest levels, not just narrative description | Pass | Role and Organization columns filled, with explicit levels |
|
||||
| 4 | Communication needs (channel, frequency, deliverable type) are mapped to project phases or milestones | Pass | Mapped to the review gates of the workflow, since no milestone document exists yet. The mapping to `MIL-*` IDs can be added in a later version once they exist |
|
||||
| 5 | Conflicting stakeholder interests are identified with documented mitigation or resolution strategies | Pass | 3 conflicts, each with a mitigation. The reviewer-independence conflict is mitigated by S01's accepted self-review (Action Item 1) |
|
||||
| 6 | Stakeholder concerns are explicitly traced to Business Case objectives | Pass | Business Goal Alignment table traces S01's concerns to O1 to O5 of [BC-001]; the objective numbers match the Business Case |
|
||||
| 7 | Primary concerns are expressed in both business language and a recognized quality-attribute mapping (e.g. FURPS+) | Pass | Every concern has a FURPS+ attribute; the acronym is spelled out in the Purpose |
|
||||
| 8 | Document is understandable and navigable by non-technical stakeholders reviewing their own entry | Pass | Short, plain table entries; S01 has a single row to read |
|
||||
|
||||
## Language and Domain Results
|
||||
|
||||
| # | Criterion | Status | Evidence/Notes |
|
||||
| --- | --- | --- | --- |
|
||||
| 1 | The Metadata table has a `Language` row and a `Domain` row, and neither is a placeholder | Pass | The `Language` row says `en` and the `Domain` row says `it`; `check-languages.sh --list` reports both |
|
||||
| 2 | `Language` is a BCP 47 code and `Domain` is a value from the registry's domain list | Pass | `en` is a BCP 47 code; `it` is in the registry's domain list ("Software and IT") |
|
||||
| 3 | The content (prose and table cells) is written in the stated language | Pass | All prose and table cells are English; tool names are established technical terms |
|
||||
| 4 | The register matches the one the registry gives for the artifact type | Pass | Registry gives IT Professional English for SA; the text uses the grid, FURPS+ and RACI terms without over-explaining them |
|
||||
| 5 | Domain terms are the PO terms of the domain's dictionary, with no synonyms | Pass | The project has no Domain Dictionary (`DICT`), so there is no list to check against; the terms *dot*, *palette*, *painting*, *grid* and *phase* match [BC-001]. S01 confirmed on 2026-10-07 that a dictionary is not needed (Action Item 2) |
|
||||
| 6 | Metadata keys, section headings, IDs and statuses are in English | Pass | Headings follow the SA reference exactly |
|
||||
| 7 | No translated twin (`<name>.<language>.md`) exists beside the document | Pass | Only `docs/stakeholder-analysis.md` exists |
|
||||
| 8 | A change of language or domain since the previous accepted version has a Version History row and was reviewed again | N-A | First version; there is no previous accepted version |
|
||||
| 9 | A reviewer competent in the domain, and in the language, has confirmed that the domain terms are used correctly | Pass | S01 confirmed on 2026-10-07 that the domain terms are used correctly (Action Item 2). S01 is also the author; the self-review was accepted by S01 (Action Item 1) |
|
||||
| 10 | Abbreviations are spelled out on first use, in the stated language | Pass | FURPS+ and RACI are spelled out in the Purpose; S01 and BC-001 are IDs defined by the document set |
|
||||
|
||||
## Overall Verdict
|
||||
|
||||
Go — every criterion of [QC-SA-001] and of [QC-LANG-001] passes (criterion 8 of [QC-LANG-001] is N-A for a first version). S01 accepted the documented self-review, confirmed the defaults and the stakeholder list, and confirmed on 2026-10-07 that the domain terms are used correctly and that no Domain Dictionary is needed. All action items are closed.
|
||||
|
||||
## Action Items
|
||||
|
||||
| # | Action | Owner | Due |
|
||||
| --- | --- | --- | --- |
|
||||
| 1 | Name a reviewer who is not the author, or record here that the review is a documented self-review accepted by S01 (the same decision as RC-001 Action Item 1). **Closed 2026-10-07:** S01 accepted a documented self-review | S01 | 2026-10-09 |
|
||||
| 2 | Confirm that the domain terms in [SA-001] are used correctly (QC-LANG-001 criterion 9), and that a Domain Dictionary is not needed for this project. **Closed 2026-10-07:** S01 confirmed both points | S01 | 2026-10-09 |
|
||||
| 3 | Confirm that S01 and S02 are the only stakeholders, or name others (for example a second reviewer). **Closed 2026-10-07:** S01 is the only stakeholder; S02 was removed from [SA-001] and [BC-001] | S01 | 2026-10-09 |
|
||||
|
||||
---
|
||||
|
||||
[SA-001]: ../../stakeholder-analysis.md
|
||||
[BC-001]: ../../business-case.md
|
||||
[QC-SA-001]: ../../../framework/qc/qc-stakeholder-analysis.md
|
||||
[QC-LANG-001]: ../../../framework/qc/qc-language-domain.md
|
||||
@@ -0,0 +1,69 @@
|
||||
# Review Record: Milestone MIL-001
|
||||
|
||||
## Metadata
|
||||
| Key | Value |
|
||||
| --- | --- |
|
||||
| ID | RC-003 |
|
||||
| CrossReference | [MIL-001], [BC-001], [QC-MIL-001], [QC-LANG-001] |
|
||||
|
||||
## Version History
|
||||
| Date | Status | Author | Reviewer | Change | Commit |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| 2026-10-07 | Accepted | Jens Tirsvad Nielsen | S01 | Initial version (draft prepared by the assistant for S01 to confirm) | pending |
|
||||
|
||||
---
|
||||
|
||||
## Artifact Under Review
|
||||
|
||||
- Instance reviewed: [MIL-001]
|
||||
- Checklist used: [QC-MIL-001], together with [QC-LANG-001] because the milestone is written in the PO language
|
||||
- Scope: full review
|
||||
- Language and domain: en / it (the artifact's Metadata rows)
|
||||
- Language reviewer: none. S01 reads English and knows the IT domain. S01 is also the author; S01 accepted a documented self-review on 2026-10-07 (see [BC-001] review record, Action Item 1)
|
||||
|
||||
**Status of this record:** final. The assistant read the milestone against
|
||||
every criterion and recorded what it found; S01 confirmed the open point on
|
||||
2026-10-07 and the verdict is `Go`.
|
||||
|
||||
## Checklist Results
|
||||
|
||||
| # | Criterion | Status | Evidence/Notes |
|
||||
| --- | --- | --- | --- |
|
||||
| 1 | A concrete deliverable is defined for every gate | Pass | Deliverable: the palette function in the source file under `src/`, its tests and the printed palette of the real image. It is a tangible output, not a date |
|
||||
| 2 | Explicit Go/No-Go criteria are stated for each gate | Pass | Five criteria, each with a Go and a No-Go column and a check that can be run (imports, colour count, white threshold 240, tests, review record) |
|
||||
| 3 | Dependencies on other milestones are explicitly mapped | Pass | Dependencies table says "None" with the reason: it is the first gateway and the baseline documents are `Accepted` |
|
||||
| 4 | Each milestone is traceable to a Business Case objective or KPI | Pass | Traceability table maps O2 and O5 of [BC-001] to the criteria and to SC3 and SC7 |
|
||||
| 5 | Milestone owner and approving reviewer are identified | Pass | Ownership table gives S01 for both; the shared identity is the accepted self-review |
|
||||
| 6 | Milestone has a defined target date consistent with project constraints | Pass | 2026-10-09, inside the one-week limit of [BC-001] (2026-10-07 to 2026-10-14) |
|
||||
|
||||
## Language and Domain Results
|
||||
|
||||
| # | Criterion | Status | Evidence/Notes |
|
||||
| --- | --- | --- | --- |
|
||||
| 1 | The Metadata table has a `Language` row and a `Domain` row, and neither is a placeholder | Pass | The `Language` row says `en` and the `Domain` row says `it`; `check-languages.sh --list` reports both |
|
||||
| 2 | `Language` is a BCP 47 code and `Domain` is a value from the registry's domain list | Pass | `en` is a BCP 47 code; `it` is in the registry's domain list ("Software and IT") |
|
||||
| 3 | The content (prose and table cells) is written in the stated language | Pass | All prose and table cells are English; tool names are established technical terms |
|
||||
| 4 | The register matches the one the registry gives for the artifact type | Pass | Registry gives IT Executive English for MIL. Purpose, Deliverable and the Go/No-Go table state decisions and checks. The Tasks table is more technical (`import turtle`, `pip`) because the milestone reference requires each summary to be understood as an Issue without opening the file. S01 confirmed this reading on 2026-10-07 (Action Item 1) |
|
||||
| 5 | Domain terms are the PO terms of the domain's dictionary, with no synonyms | Pass | S01 confirmed on 2026-10-07 that no dictionary is needed; the terms *dot*, *palette*, *painting*, *grid* and *phase* match [BC-001] |
|
||||
| 6 | Metadata keys, section headings, IDs and statuses are in English | Pass | Headings follow the MIL reference exactly |
|
||||
| 7 | No translated twin (`<name>.<language>.md`) exists beside the document | Pass | Only `docs/milestones/mil-001-palette.md` exists |
|
||||
| 8 | A change of language or domain since the previous accepted version has a Version History row and was reviewed again | N-A | First version; there is no previous accepted version |
|
||||
| 9 | A reviewer competent in the domain, and in the language, has confirmed that the domain terms are used correctly | Pass | S01 confirmed on 2026-10-07 that the domain terms are used correctly (Action Item 1). S01 is also the author; the self-review was accepted by S01 |
|
||||
| 10 | Abbreviations are spelled out on first use, in the stated language | Pass | SC3, SC7, O2 and O5 are defined in [BC-001] and cited with it; RGB is spelled out at its first use in task 5, and Tk is explained in task 1 as the graphical toolkit behind `turtle` |
|
||||
|
||||
## Overall Verdict
|
||||
|
||||
Go — every criterion of [QC-MIL-001] and of [QC-LANG-001] passes (criterion 8 of [QC-LANG-001] is N-A for a first version). S01 accepted the documented self-review and confirmed on 2026-10-07 that the domain terms are used correctly and that the technical wording of the Tasks table is acceptable. The action item is closed. The milestone may now be synced to the git host and its tasks may start (plan-first gate).
|
||||
|
||||
## Action Items
|
||||
|
||||
| # | Action | Owner | Due |
|
||||
| --- | --- | --- | --- |
|
||||
| 1 | Confirm that the domain terms are used correctly (QC-LANG-001 criterion 9), and that the technical wording of the Tasks table is acceptable in a milestone of register IT Executive English. **Closed 2026-10-07:** S01 confirmed both points | S01 | 2026-10-08 |
|
||||
|
||||
---
|
||||
|
||||
[MIL-001]: ../../milestones/mil-001-palette.md
|
||||
[BC-001]: ../../business-case.md
|
||||
[QC-MIL-001]: ../../../framework/qc/qc-milestones-gateways.md
|
||||
[QC-LANG-001]: ../../../framework/qc/qc-language-domain.md
|
||||
@@ -0,0 +1,69 @@
|
||||
# Review Record: Milestone MIL-002
|
||||
|
||||
## Metadata
|
||||
| Key | Value |
|
||||
| --- | --- |
|
||||
| ID | RC-004 |
|
||||
| CrossReference | [MIL-002], [BC-001], [QC-MIL-001], [QC-LANG-001] |
|
||||
|
||||
## Version History
|
||||
| Date | Status | Author | Reviewer | Change | Commit |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| 2026-10-07 | Accepted | Jens Tirsvad Nielsen | S01 | Initial version (draft prepared by the assistant for S01 to confirm) | pending |
|
||||
|
||||
---
|
||||
|
||||
## Artifact Under Review
|
||||
|
||||
- Instance reviewed: [MIL-002]
|
||||
- Checklist used: [QC-MIL-001], together with [QC-LANG-001] because the milestone is written in the PO language
|
||||
- Scope: full review
|
||||
- Language and domain: en / it (the artifact's Metadata rows)
|
||||
- Language reviewer: none. S01 reads English and knows the IT domain. S01 is also the author; S01 accepted a documented self-review on 2026-10-07 (see [BC-001] review record, Action Item 1)
|
||||
|
||||
**Status of this record:** final. The assistant read the milestone against
|
||||
every criterion and recorded what it found; S01 confirmed the open point on
|
||||
2026-10-07 and the verdict is `Go`.
|
||||
|
||||
## Checklist Results
|
||||
|
||||
| # | Criterion | Status | Evidence/Notes |
|
||||
| --- | --- | --- | --- |
|
||||
| 1 | A concrete deliverable is defined for every gate | Pass | Deliverable: the runnable program in the source file under `src/`, its tests and one timed run showing the finished painting |
|
||||
| 2 | Explicit Go/No-Go criteria are stated for each gate | Pass | Six criteria, each with a Go and a No-Go column and a check that can be run (dot count, size and spacing, palette membership, clean result, 30 seconds, review record) |
|
||||
| 3 | Dependencies on other milestones are explicitly mapped | Pass | Dependencies table names MIL-001 and the reason: the painting draws with the palette function that phase delivers |
|
||||
| 4 | Each milestone is traceable to a Business Case objective or KPI | Pass | Traceability table maps O1, O3, O4 and O5 of [BC-001] to the criteria and to SC1, SC2 and SC4 to SC7; SC3 belongs to MIL-001 |
|
||||
| 5 | Milestone owner and approving reviewer are identified | Pass | Ownership table gives S01 for both; the shared identity is the accepted self-review |
|
||||
| 6 | Milestone has a defined target date consistent with project constraints | Pass | 2026-10-14, the last day of the one-week limit of [BC-001] (2026-10-07 to 2026-10-14). There is no slack; the Project Plan names this as a risk |
|
||||
|
||||
## Language and Domain Results
|
||||
|
||||
| # | Criterion | Status | Evidence/Notes |
|
||||
| --- | --- | --- | --- |
|
||||
| 1 | The Metadata table has a `Language` row and a `Domain` row, and neither is a placeholder | Pass | The `Language` row says `en` and the `Domain` row says `it`; `check-languages.sh --list` reports both |
|
||||
| 2 | `Language` is a BCP 47 code and `Domain` is a value from the registry's domain list | Pass | `en` is a BCP 47 code; `it` is in the registry's domain list ("Software and IT") |
|
||||
| 3 | The content (prose and table cells) is written in the stated language | Pass | All prose and table cells are English; tool names are established technical terms |
|
||||
| 4 | The register matches the one the registry gives for the artifact type | Pass | Registry gives IT Executive English for MIL. Purpose, Deliverable and the Go/No-Go table state decisions and checks. The Tasks table is more technical (`random.choice`, `exitonclick`) because the milestone reference requires each summary to be understood as an Issue without opening the file. S01 confirmed this reading on 2026-10-07 (Action Item 1) |
|
||||
| 5 | Domain terms are the PO terms of the domain's dictionary, with no synonyms | Pass | S01 confirmed on 2026-10-07 that no dictionary is needed; the terms *dot*, *palette*, *painting*, *grid* and *phase* match [BC-001] |
|
||||
| 6 | Metadata keys, section headings, IDs and statuses are in English | Pass | Headings follow the MIL reference exactly |
|
||||
| 7 | No translated twin (`<name>.<language>.md`) exists beside the document | Pass | Only `docs/milestones/mil-002-painting.md` exists |
|
||||
| 8 | A change of language or domain since the previous accepted version has a Version History row and was reviewed again | N-A | First version; there is no previous accepted version |
|
||||
| 9 | A reviewer competent in the domain, and in the language, has confirmed that the domain terms are used correctly | Pass | S01 confirmed on 2026-10-07 that the domain terms are used correctly (Action Item 1). S01 is also the author; the self-review was accepted by S01 |
|
||||
| 10 | Abbreviations are spelled out on first use, in the stated language | Pass | SC1 to SC7 and O1 to O5 are defined in [BC-001] and cited with it; RGB is spelled out at its first use in task 1 |
|
||||
|
||||
## Overall Verdict
|
||||
|
||||
Go — every criterion of [QC-MIL-001] and of [QC-LANG-001] passes (criterion 8 of [QC-LANG-001] is N-A for a first version). S01 accepted the documented self-review and confirmed on 2026-10-07 that the domain terms are used correctly and that the technical wording of the Tasks table is acceptable. The action item is closed. The milestone may now be synced to the git host and its tasks may start (plan-first gate).
|
||||
|
||||
## Action Items
|
||||
|
||||
| # | Action | Owner | Due |
|
||||
| --- | --- | --- | --- |
|
||||
| 1 | Confirm that the domain terms are used correctly (QC-LANG-001 criterion 9), and that the technical wording of the Tasks table is acceptable in a milestone of register IT Executive English. **Closed 2026-10-07:** S01 confirmed both points | S01 | 2026-10-08 |
|
||||
|
||||
---
|
||||
|
||||
[MIL-002]: ../../milestones/mil-002-painting.md
|
||||
[BC-001]: ../../business-case.md
|
||||
[QC-MIL-001]: ../../../framework/qc/qc-milestones-gateways.md
|
||||
[QC-LANG-001]: ../../../framework/qc/qc-language-domain.md
|
||||
@@ -0,0 +1,94 @@
|
||||
# Stakeholder Analysis: Hirst Painting
|
||||
|
||||
## Metadata
|
||||
| Key | Value |
|
||||
| --- | --- |
|
||||
| ID | SA-001 |
|
||||
| CrossReference | [BC-001] |
|
||||
| Language | en |
|
||||
| Domain | it |
|
||||
|
||||
## Version History
|
||||
| Date | Status | Author | Reviewer | Change | Commit |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| 2026-10-07 | Accepted | Jens Tirsvad Nielsen | S01 | Initial version | pending |
|
||||
|
||||
---
|
||||
|
||||
## Purpose
|
||||
|
||||
This analysis identifies who has a stake in the Hirst painting program and
|
||||
classifies each stakeholder by power and interest, so that other artifacts can
|
||||
cite stable stakeholder IDs for ownership, review and RACI (responsible,
|
||||
accountable, consulted, informed). It follows the power/interest grid and maps
|
||||
each concern to a FURPS+ attribute (functionality, usability, reliability,
|
||||
performance, supportability, plus further constraints). The project is a
|
||||
one-person learning exercise, so the list has a single entry on purpose; a
|
||||
stakeholder is added only when someone or something actually shapes the work.
|
||||
|
||||
## Stakeholder Summary Table
|
||||
|
||||
| ID | Name | Role/Title | Organization | Power Level | Interest Level | Quadrant | Primary Concern (Business Language) |
|
||||
| --- | --- | --- | --- | --- | --- | --- | --- |
|
||||
| S01 | Jens Tirsvad Nielsen | Product Owner, developer and reviewer | Tirsvad (individual) | HIGH | HIGH | Manage Closely | Finish the Day 18 exercise as a working, reviewed painting program that behaves as the lecture teaches, and learn from it without more process than the work needs |
|
||||
|
||||
## Power/Interest Classification Rationale
|
||||
|
||||
- **Manage Closely (S01):** S01 decides scope, accepts every artifact, owns
|
||||
every phase and is the only person who works on the project, so power and
|
||||
interest are both high. S01 is consulted at every review gate.
|
||||
- **Other quadrants:** no stakeholder falls in Keep Satisfied, Keep Informed or
|
||||
Monitor. The course lecture is the source of the required behaviour, but it
|
||||
is a document, not a stakeholder: it is cited as the requirements source in
|
||||
[BC-001] and takes no part in the project.
|
||||
|
||||
## Primary Concerns and FURPS+ Mapping
|
||||
|
||||
| ID | Concern | FURPS+ attribute |
|
||||
| --- | --- | --- |
|
||||
| S01 | The program draws the painting correctly and as the lecture teaches: 100 dots, right size and spacing, palette without white, random colours | Functionality |
|
||||
| S01 | The result looks clean and the window stays open until a click | Usability |
|
||||
| S01 | The drawing finishes quickly enough to not be tedious | Performance |
|
||||
| S01 | The code is readable and passes the Python checklist | Supportability |
|
||||
| S01 | The process stays proportionate to a one-script project | Supportability |
|
||||
|
||||
## Communication Requirements
|
||||
|
||||
| ID | Channel | Frequency | Deliverable | Phase / Milestone |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| S01 | Chat with the assistant, working-tree review | At each review gate: Business Case and Stakeholder Analysis, Project Plan, each milestone, the code | Documents in `docs/`, review records `RC-*`, dry-run output of `sync-project.sh` | Every review gate before the next step starts |
|
||||
| S01 | Pull request on the git host | Once, when S01 asks for it | Pull request closing the completed issues | Code review before the pull request |
|
||||
|
||||
## Conflicting Interests and Mitigations
|
||||
|
||||
With one stakeholder there is no conflict between people; the conflicts below
|
||||
are tensions inside S01's own interests, and one process conflict.
|
||||
|
||||
| Conflict | Stakeholders | Mitigation |
|
||||
| --- | --- | --- |
|
||||
| S01 wants to practise the full framework workflow but also to finish a small exercise quickly | S01 | Two phases only, plain technical tasks, no use cases or design artifacts; the Business Case names this as a risk and as Out of Scope |
|
||||
| S01 may want to change values from the lecture (dot size, spacing, thresholds) while the Business Case fixes them as targets | S01 | S01 owns the decision; a change is made through a new Version History row of [BC-001] and a re-review |
|
||||
| The framework asks for a reviewer who is not the author, but S01 is the only person on the project | S01 | S01 accepted a documented self-review on 2026-10-07, recorded in the review records of [BC-001] and this document; the assistant never marks a document `Accepted` itself |
|
||||
|
||||
## Traceability Analysis
|
||||
|
||||
### Business Goal Alignment
|
||||
|
||||
| Stakeholder | Concern | Business Case objective |
|
||||
| --- | --- | --- |
|
||||
| S01 | Correct painting, as the lecture teaches | O1, O2, O3 of [BC-001] |
|
||||
| S01 | Clean, quick result | O4 of [BC-001] |
|
||||
| S01 | Reviewed, proportionate delivery | O5 of [BC-001] |
|
||||
|
||||
Actor mapping: S01 is the only actor, as the person who runs the program and
|
||||
clicks the window to close it. The program has no other user, so no use cases
|
||||
are modelled; this is recorded as out of scope in [BC-001].
|
||||
|
||||
## Sign-Off
|
||||
|
||||
Pending. Sign-off is recorded by the review record (`RC-*`) of this document.
|
||||
The assistant does not mark the document `Accepted`.
|
||||
|
||||
---
|
||||
|
||||
[BC-001]: ./business-case.md
|
||||
Reference in New Issue
Block a user