Glossary

Glossary

Activity — A piece of work in an iteration (Define the Vision). Has a discipline, owner, assignees, deadline and state.

Ad-hoc scenario — A test scenario a tester discovers during a run and adds to it (AH-01). Can be promoted to a test case.

Artifact — A unit of engineering knowledge: requirement, use case, business rule, decision, risk… Has a key, a lifecycle and revisions.

Baseline — A snapshot of the exact revisions of the baselined records of a Development at a point in time. Immutable.

Business model — How the business works, independent of software: business actors, workers, use cases and rules.

Change request (CR) — A governed request to change something: submitted, triaged, decided with a rationale, scheduled, implemented, verified, closed.

Correction — A change to a recorded test result. Requires a reason; kept forever in the correction history.

Development — The effort of building or changing a system, run with the Unified Process. Studio's equivalent of a project.

Development case — The tailoring of the process for a Development: which disciplines, activities, work products and readiness criteria are required or recommended.

Discipline — An area of engineering concern (Requirements, Test…) active across phases.

Discussion — Messages and attachments on a record, like a chatter.

Evidence — Files attached to test executions and steps. Stored privately and append-only.

Execution — One test case inside a test run: a frozen copy of the case and its result.

Iteration — A short, time-boxed cycle of work inside a phase.

Knowledge article — A page of the knowledge base (KB-0001), possibly under a parent article and belonging to a Development.

Mention — A [[CODE]] link in a text. Records list the texts that mention them ("Mentioned in").

Milestone — The checkpoint that closes a phase: Lifecycle Objectives, Lifecycle Architecture, Initial Operational Capability, Product Release.

Pass rate — Passed ÷ (passed + failed), over executions of non-cancelled runs.

Phase — Inception, Elaboration, Construction or Transition.

Process role — A responsibility someone plays in a Development (Tester, Architect…). Grants no access by itself.

QA issue — A defect found by testing, linked to the executions that show it.

Project — A team's container of tasks, with a key (BILL) that prefixes task codes. Can have a parent project (subprojects).

Readiness — The advisory check of what a Development case asks for and what's still missing.

Recipe — Drupal's way to package a site's modules and configuration. Studio installs with one.

Repository (Code Source) — A local Git clone registered in a Development (SRC-0001).

Database (schemas) — A logical database of a Development (DB-0001), addressed by analyzers through its identifier.

Contract (database) — The JSON any analyzer sends to describe a schema; adapters turn other formats (SchemaSpy XML) into it.

Ref — A branch, tag or remote-tracking ref of a repository that Studio indexes.

Snapshot (Code Source) — An indexing of a ref at a commit; never changes.

Snapshot (database) — The schema of a database at a moment, as an analyzer saw it; never changes.

Implied relationship — A relationship an analyzer guessed from names and types, not enforced by the database.

Stage — A column of a project board (To Do, In Progress…), with a category: not started, in progress, done or cancelled.

Subtask — A task whose parent is another task of the same project.

Snapshot (test run) — The frozen copy of the plan's Ready test cases taken when a run is created.

Timesheet entry — Time someone spent on a project or task: date, description and hours. An adjustment entry corrects the total of a day in the weekly grid.

Task — A unit of work in a project (BILL-0001): type, stage, priority, assignees, deadline, subtasks, related tasks and comments.

Test case / plan / suite / step / run — See Test management.

Trace — An explicit, typed, directed link between two records (refines, verifies, impacts…).

Unified Process (UP) — An iterative software process with four phases, each closed by a milestone.

Verification — The status of a requirement, use case, change request or work product, derived from the results of the tests that verify it.

Work product — A governed deliverable (Vision, Architecture Description…).