Development Case - The Goat

Tangye Holistic Engineering Global Online Advanced Technology

Author:	David Tangye
Contact:	DavidTangye@gmail.com
Revision date:	19/11/2025
HTML generator:	docutils.core.publish_file (python)
Published URL:	Get The Goat
Copywrite:	Tangye Engineering 2025
License:	🅭 🄎 Creative Commons Attribution by ShareAlike
Process:	OpenUP as adopted

Purpose

The purpose of this document is to describe the development of the TheGoat application, refined as per its major headings. This is an OpenUP artifact, cut down / simplified.

Scope

This development case applies to the development of version 1 of the THEGOAT software product, beginning October 2025

Definitions, Acronyms, and Abbreviations

OpenUP: Open Unified Process from The Eclipse Foundation
OpenUP as adopted: A copy of a version of OpenUP which is currently the latest released version as of October 2025.
TheGoat: Tangye Holistic Engineering Global Online Advanced Technology (Also occasionally encoded as "The Goat" or THEGOAT)

Overview

The development process adopted (OpenUP as adopted) for the THEGOAT project is based on a version of the “Open Unified Process” (OpenUP) from The Eclipse Foundation. Any version of OpenUP that is published in future might or might not be adopted.

The key principles of the process are defined in OpenUP as adopted as follows:

→ Delivery Processes → OpenUP life-cycle,

→ Practices, and

→ Roles.

The guidance therein is followed to a great extent. However some significant simplifications have been made, as further described below. As a result, the formal list of Work Products for this project is minimised, especially the document artifacts. Some OpenUP as adopted documents are effectively combined. Some visual models are produced, and are embedded into these documents.

Life-cycle Model

The development life-cycle is as per OpenUP as adopted, following its concepts closely, eg adopting the Phases (Inception, Elaboration, Construction and Transition) and recognising the purpose and need to define Milestones for each Phase. In addition, objectives suggested in the early incarnations of OpenUP, including the Rational Unified Process from the 1990’s, and best practices of business startups, are recognised, namely:

Inception:: OpenUP as adopted: Define the scope, and so estimate the total project effort / cost, and identify the key risk items.

For this project, refer to the System Requirements document, "Scope" for the specification details.
Elaboration:: OpenUP as adopted: Eliminate / mitigate the key risk items, mainly by building system components.

For this project, refer to the System Requirements document, "Key Risks".
Construction:: OpenUP as adopted: Build a minimum viable product (MVP)
Transition:: OpenUP as adopted: Seamlessly integrate the system into the business

Milestones

See the Project Plan for the specification details of milestones within each phase.

Work Products

See the OpenUP as adopted section → 'Work Products'

System Artifacts

Infrastructure

A minimalistic set of components, including:

Software for Development:
- Main editor: vim
- Source code version control: git
- Virtual environment and package management: uv.
Software for Development and Production Deployment: linux servers, python 3, nginx, django.
Server hosting: Commerically hosted VPS servers: currently using Hostinger.

"The Goat" deployed system

OpenUP "Releases" are delivered as a web-based application, accessible at Get The Goat.
Product Documentation: as below. Product and User Documentation are included online at Get The Goat
Release Communications: TBD (if/when there is anyone to communicate to!)

Documents

Developed as distinct documents

These are listed in the order that each would usually be started.
Each document broadly follows as suggested by OpenUP as adopted, with refinements as indicated below.

Document Title	Purpose / Notes
Development Case	This document. See its Purpose, above
Vision	Describes the vision for what facility of value the project will deliver.
System Requirements	Includes various OpenUP documents, with embedded UML visual model artifacts.
Project Plan	Initially in Google Notes, then moved to its own doc?
System Design	Includes the OpenUP “Architecture Notebook`_ and embedded UML visual model artifacts.
System Administration Guide	A single point of reference and guidance for system operational / technical support
Document Skeleton	Used to create the above documents

Sequence and Dependencies of Document Creation

This Development Case Document is the first created. It specifies all the other key artifacts of the project, their main content, the order they are created (This specification).
The System Administration Guide document would normally be one of the last documents to be created. However for this project, it was created even before the System Requirements document, to document the UV tool and the rst2html tools. It will be deployed online at Get The Goat as a relatively small section of web pages, containing guidance with links on technical aspects of the system and its maintenance.
The System Requirements document is started next.
After the key requirements and constrains are defined, the Project Plan can be started, to define and sequence the main tasks of development, mainly key milestones. The milestones include setting up the development and production environments, and delivery of key functionality into production.
When the System Requirements are sufficiently defined and understood, the System Design document is started. The design of the system is defined, and then the bulk of the System Administration Guide is documented. The System Requirements and System Design documents are refined in sync with each other continually, during the course of the project.

Unlikely to be developed as distinct documents

The key content expected in each of these will be included as sections of other documents above.

Document Title	Reason / Notes
Risk List	An initial risk list is included in the System Requirements document.
Iteration Plan	In Google Notes as a ToDo list. There is a very high cadence of releases.
Work Items List	In the Iteration Plan in Google Notes
Glossary	Initially in here and later more fully defined in System Requirements
Use Cases	Mostly included in System Requirements. Some use cases might have their own document.
Use Case Models	Included in System Requirements
Architecture Notebook	Included in System Design

Reports

Developer Reports: None, until delivered to any other stakeholders some time in the future.
Application Admin Reports: None. "Reports" are implemented as live screens of data.
Adhoc Reports: Occasional "one-off" on-demand adhoc reports might be generated directly from the database.

Stakeholder Roles

Role	Purpose
Owner, Developer, SysAdmin	I own and develop the TheGoat application
System User	Registered users with authenticated access to the system
The public	Browser access to public pars of the system.