mirror of
https://github.com/azaion/gps-denied-desktop.git
synced 2026-04-22 11:36:36 +00:00
111 lines
6.4 KiB
Markdown
111 lines
6.4 KiB
Markdown
# 1. Research phase
|
|
|
|
|
|
## 1.1 **👨💻Developers**: Problem statement
|
|
Discuss the problem and create in the `docs/00_problem` next files:
|
|
- `problem_description.md`: Our problem to solve with the end result we want to achieve. For example:
|
|
We have wing type UAV (airplane). It should fly autonomously to predetermined GPS destination. During the flight it is relying on the signal form GPS module.
|
|
But when adversary jam or spoof GPS, then UAV either don't know where to fly, or fly to the wrong direction.
|
|
So, we need to achieve that UAV can fly correctly to the destination without GPS or when GPS is spoofed. We can use the camera pointing downward and other sensor data like altitude, available form the flight controller. Airplane is running Ardupliot.
|
|
- `restrictions.md`: Restrictions we have in real world. For example:
|
|
- We're limiting our solution to airplane type UAVs.
|
|
- Additional weight it could take is under 1 kg.
|
|
- The whole system should cost under $2000.
|
|
- The flying range is restricted by eastern and southern part of Ukraine. And so on.
|
|
- `acceptance_criteria.md`: Acceptance criteria for the solution. For example:
|
|
- UAV should fly without GPS for at least 30 km in the sunshine weather.
|
|
- UAV shoulf fly with maximum mistake no more than 40 meters from the real GPS
|
|
- UAV should fly correctly with little foggy weather with maximum mistake no more than 100 meters from the real GPS
|
|
- UAV should fly for minimum of 500 meters with missing inernal Satellite maps and the drifting error should be no more than 50 meters.
|
|
- `docs/00_problem/input_data`: Put to this folder all the necessary input data for the further tests. For example:
|
|
- orthophoto images from the UAV for the analysis
|
|
- initial gps
|
|
- ...
|
|
|
|
## 1.2 **✨AI Research**: Research acceptance criteria in great detail
|
|
Form the next prompt by replacing *.md with corresponding content and run it in DeepResearch tool (Gemini, ChatGPT, or other)
|
|
**📝prompt:**
|
|
For the problem:
|
|
`docs/00_problem/problem_description.md`
|
|
with restrictions:
|
|
`docs/00_problem/restrictions.md`
|
|
check how realistic these acceptance criteria are:
|
|
`docs/00_problem/acceptance_criteria.md`
|
|
Check how critical is each criteria. Also find out more acceptance criteria for this specific domain.
|
|
Research impact of each value in acceptance criteria to the whole system quality.
|
|
Assess acceptable ranges for each value in each acceptance criteria in the state of the art solutions, and propose corrections in form:
|
|
- state of the art solutions' value ranges : our value ranges
|
|
|
|
Form the new acceptance criteria based on your research.
|
|
|
|
**👨💻Developers**: Revise the result, discuss them and overwrite `docs/00_problem/acceptance_criteria.md`
|
|
|
|
|
|
## 1.3 **✨AI Research**: Research the problem in great detail
|
|
Form the next prompt by replacing *.md with corresponding content and run it in DeepResearch tool (Gemini, ChatGPT, or other)
|
|
**📝prompt:**
|
|
Research the problem:
|
|
`docs/00_problem/problem_description.md`
|
|
We need to achieve this goal:
|
|
`docs/00_problem/goal.md`
|
|
Final solution should meet the acceptance criteria:
|
|
`docs/00_problem/acceptance_criteria.md`
|
|
The whole system has following limitations:
|
|
`docs/00_problem/restrictions.md`
|
|
Find out all the state of the art solutions for this problem and produce the resulting solution draft in the next format:
|
|
- Product solution description
|
|
- Architecture approach that meet restrictions and acceptance criteria
|
|
- Testing strategy. Research the best approaches to cover all the acceptance criteria, functional and non-functional tests
|
|
|
|
**👨💻Developer**: Research the problem as well, and add solution details to the draft. Store it to the `docs/01_solution/solution_draft_01.md`
|
|
|
|
|
|
## 1.4 **✨AI Research**: Solution draft assessment
|
|
Form the next prompt by replacing *.md with corresponding content and run it in DeepResearch tool (Gemini, ChatGPT, or other)
|
|
**📝prompt:**
|
|
In the solution here:
|
|
`docs/01_solution/solution_draft_xx.md`
|
|
find out all the possible weak points and problems. Address them and find out ways to solve them. Based on your findings, form new solution draft in the same format.
|
|
|
|
**👨💻Developer**: Research by yourself as well - how to solve additional problems which AI figured out, and add them to the result. Store the result draft to the `docs/01_solution/solution_draft_xx+1.md`, and repeat the process. When the next solution wouldn't differ much from the previous one, store the last draft as `docs/01_solution/solution.md`
|
|
|
|
## 1.5 **🤖📋AI plan**: Solution Decomposition
|
|
**📝prompt:**
|
|
Decompose the solution `@docs/01_solution/solution.md` to the components.
|
|
Store description of each component to the file `docs/02_components/[##]_[component_name]/spec.md` with the next structure:
|
|
- Component Name
|
|
- Detailed description
|
|
- API methods, for each method:
|
|
- Name
|
|
- Input
|
|
- Output
|
|
- Description
|
|
- Test cases for the method
|
|
- Integration tests for the component if needed.
|
|
|
|
Generate draw.io components diagram shows relations between components.
|
|
Do not put any code yet, only names, input and output.
|
|
|
|
Also read `@docs/00_initial/acceptance_criteria.md` and compose tests according to test strategy to cover all the criteria and store them to the files
|
|
`docs/03_tests/[##]_[test_name]_spec.md` with the next structure:
|
|
- Summary
|
|
- Detailed description
|
|
- Preconditions for tests
|
|
- Steps:
|
|
- Step1 - Expected result1
|
|
- Step2 - Expected result2
|
|
...
|
|
- StepN - Expected resultN
|
|
|
|
Do not put any code yet. Ask as many questions as needed.
|
|
|
|
**👨💻Developer**: Answer the questions AI asked, put as many details as possible
|
|
|
|
## 1.6 **🤖📋AI plan**: Business Requirement generation
|
|
From the initial requirements above generate Jira epics:
|
|
- Ask the Jira project key and latest created jira task number. For example AZ-412
|
|
- Access the solution `@docs/01_solution/solution.md` and description of each component in the files `docs/02_components/[##]_[component_name]/spec.md`
|
|
- Generate Jira Epics from the Components
|
|
- Ensure each epic has clear goal and acceptance criteria, verify the criteria with `@docs/00_initial/acceptance_criteria.md`
|
|
- Generate draw.io components diagram based on previous diagram shows relations between components and Jira Epic numbers corresponding to each component.
|