mirror of
https://github.com/azaion/gps-denied-onboard.git
synced 2026-04-23 02:46:36 +00:00
went through 4 iterations of solution draft. Right now it is more or less consistent and reliable
This commit is contained in:
Oleksandr Bezdieniezhnykh
@@ -2,29 +2,30 @@
|
||||
|
||||
|
||||
## 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:
|
||||
Discuss the problem and create in the `docs/00_problem` next files and folders:
|
||||
- `problem_description.md`: Our problem to solve with the end result we want to achieve.
|
||||
- `input_data`: Put to this folder all the necessary input data and expected results for the further tests. Analyze very thoroughly input data and form system's restrictions and acceptance ctiteria
|
||||
- `restrictions.md`: Restrictions we have in real world in the -dashed list format.
|
||||
- `acceptance_criteria.md`: Acceptance criteria for the solution in the -dashed list format.
|
||||
The most important part, determines how good the system should be.
|
||||
|
||||
### Example:
|
||||
- `problem_description.md`
|
||||
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.
|
||||
|
||||
- `docs/00_problem/input_data`: Put to this folder all the necessary input data and expected results for the further tests. For example:
|
||||
- `input_data`
|
||||
- orthophoto images from the UAV for the analysis
|
||||
- list of expected GPS for the centers for each picture in csv format: picture name, lat, lon
|
||||
- video from the UAV for the analysis
|
||||
- list of expected GPS for the centers of video per timeframe in csv format: timestamp, lat, lon for each 1-2 seconds
|
||||
- ...
|
||||
|
||||
Analyze very thoroughly input data and form system's restrictions and acceptance ctiteria
|
||||
|
||||
- `restrictions.md`: Restrictions we have in real world in the -dashed list format. For example:
|
||||
- `restrictions.md`
|
||||
- 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 in the -dashed list format.
|
||||
The most important part, determines how good the system should be. For example:
|
||||
- `acceptance_criteria.md`
|
||||
- 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
|
||||
@@ -32,11 +33,12 @@
|
||||
|
||||
|
||||
## 1.2 **✨AI Research**: Restrictions and Acceptance Criteria assesment
|
||||
In the new context form the next prompt:
|
||||
- Add *.md to the context
|
||||
- Add sample files to the prompt
|
||||
- Put proper sample filenames in the text of the prompt
|
||||
and run it in DeepResearch tool (Gemini, DeepSeek, or other)
|
||||
Put to the research context:
|
||||
- `problem_description.md`
|
||||
- `restrictions.md`
|
||||
- `acceptance_criteria.md`
|
||||
- Samples of the input data
|
||||
Run it in DeepResearch tool (Gemini, DeepSeek, or other)
|
||||
```
|
||||
We have the problem described in `problem_description.md`.
|
||||
- System should process data samples in the attached files (if any). They are for reference only.
|
||||
@@ -50,87 +52,76 @@ We have the problem described in `problem_description.md`.
|
||||
- Our values
|
||||
- Your researched criterion values
|
||||
- Status: Is the criterion added by your research to our system, modified, or removed
|
||||
Assess the restrictions we've put on the system. Are they realistic? Propose corrections in the next table:
|
||||
Assess the restrictions we've put on the system. Are they realistic? Should we add more strict restrictions, or vise versa, add more requirements in restrictions to use our system. Propose corrections in the next table:
|
||||
- Restriction name
|
||||
- Our values
|
||||
- Your researched restriction values
|
||||
- Status: Is a restriction added by your research to our system, modified, or removed
|
||||
```
|
||||
|
||||
**👨💻Developers**: Revise the result, discuss them and overwrite `docs/00_problem/acceptance_criteria.md`
|
||||
**👨💻Developers**: Revise the result, discuss them and overwrite `acceptance_criteria.md` and `restrictions.md`
|
||||
|
||||
|
||||
## 1.3 **✨AI Research**: Research the problem in great detail
|
||||
In the new context form the next prompt:
|
||||
- Add *.md to the context
|
||||
- Add sample files to the prompt
|
||||
- Put proper sample filenames in the text of the prompt
|
||||
and run it in DeepResearch tool (Gemini, DeepSeek, or other)
|
||||
Replace md files with actual data
|
||||
Put to the research context samples of the input data
|
||||
Run it in DeepResearch tool (Gemini, DeepSeek, or other)
|
||||
```
|
||||
Research this problem in `problem_description.md`.
|
||||
- The system should process data samples in attached files (if any). They are for reference only.
|
||||
- We have the next restrictions for the input data in `restrictions.md`.
|
||||
- Output of our system should meet these acceptance criteria in `acceptance_criteria.md`.
|
||||
Research this problem:
|
||||
|
||||
`problem_description.md`
|
||||
|
||||
The system should process data samples in the attached files (if any). They are for reference only.
|
||||
The system has next restrictions and conditions:
|
||||
|
||||
`restrictions.md`
|
||||
|
||||
- Output of our system should meet these acceptance criteria:
|
||||
|
||||
`acceptance_criteria.md`
|
||||
|
||||
- Find out all the state-of-the-art solutions for this problem and produce the resulting solution draft in the next format:
|
||||
- Short Product solution description. Brief component interaction diagram.
|
||||
- Architecture approach that meets restrictions and acceptance criteria. Tables to compare possible component decisions.
|
||||
- Testing strategy. Research the best approaches to cover all the acceptance criteria, functional, and non-functional tests
|
||||
Be concise in formulating, The less words the better, but do not miss any important details.
|
||||
```
|
||||
- Architecture approach that meets restrictions and acceptance criteria. For each component, analyze the best possible approaches to solve, and form a table comprising all approaches. Each new approach would be a row, and has the next columns:
|
||||
- Tools (library, platform) to solve component tasks
|
||||
- Advantages of this approach
|
||||
- Limitations of this approach
|
||||
- Requirements for this approach
|
||||
- How does it fit for the problem component that has to be solved, and the whole solution
|
||||
- Testing strategy. Research the best approaches to cover all the acceptance criteria. Form a list of integration functional tests and non-functional tests.
|
||||
|
||||
Be concise in formulating. The fewer words, the better, but do not miss any important details.
|
||||
```
|
||||
**👨💻Developer**: Revise the result from AI. Research the problem as well, and add/modify/remove some solution details in the draft.
|
||||
Store it to the `docs/01_solution/solution_draft_01.md`
|
||||
Store it to the `docs/01_solution/solution_draft.md`
|
||||
|
||||
|
||||
## 1.4 **✨AI Research**: Solution draft assessment
|
||||
Add *.md to the context and run it in DeepResearch tool (Gemini, DeepSeek, or other)
|
||||
Replace md files with actual data
|
||||
Run it in DeepResearch tool (Gemini, DeepSeek, or other)
|
||||
```
|
||||
We have a problem here in `problem_description.md` with restrictions `restrictions.md`. We've presented the solution here in `solution_draft_xx.md`.
|
||||
Identify all potential weak points and problems. Address them and find out ways to solve them. Based on your findings, form a new solution draft in the same format without mentioning or comparison with first solution draft. Also, in case of replacing some components with better one, do not just throw away the previous, form a table with comparison for the component.
|
||||
```
|
||||
Read carefully about the problem:
|
||||
|
||||
**👨💻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
|
||||
```
|
||||
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.
|
||||
`problem_description.md`
|
||||
|
||||
Generate draw.io components diagram shows relations between components.
|
||||
Do not put any code yet, only names, input and output.
|
||||
System has next restrictions and conditions:
|
||||
|
||||
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
|
||||
`restrictions.md`
|
||||
|
||||
Output of the system should address next acceptance criteria:
|
||||
|
||||
`acceptance_criteria.md`
|
||||
|
||||
Here is a solution draft:
|
||||
|
||||
`solution_draft.md`
|
||||
|
||||
## 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.
|
||||
```
|
||||
Identify all potential weak points and problems. Address them and find out ways to solve them. Based on your findings, form a new solution draft in the same format.
|
||||
|
||||
If your finding requires a complete reorganization of the flow and different components, state it.
|
||||
Put all the findings regarding what was weak and poor at the beginning of the report. Put here all new findings, what was updated, replaced, or removed from the previous solution.
|
||||
|
||||
Then form a new solution design without referencing the previous system. Remove Poor and Very Poor component choices from the component analysis tables, but leave Good and Excellent ones.
|
||||
In the updated report, do not put "new" marks, do not compare to the previous solution draft, just make a new solution as if from scratch
|
||||
|
||||
```
|
||||
**👨💻Developer**: Research by yourself as well - how to solve additional problems which AI figured out, and add them to the result. Rename previous `solution_draft.md` to `xx_solution_draft.md`. And then store the result draft to the `docs/01_solution/solution_draft.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`
|
||||
|
||||
@@ -0,0 +1,5 @@
|
||||
# 2. Planning phase
|
||||
|
||||
## 2.1 **🤖📋AI plan** /gen_components
|
||||
## 2.2 **🤖📋AI plan** /gen_tests
|
||||
## 2.3 **🤖📋AI plan** /gen_epics
|
||||
@@ -1,6 +1,6 @@
|
||||
# 2. Development phase
|
||||
# 3. Development phase
|
||||
|
||||
## 2.1 **🤖📋AI plan**: Component Decomposition
|
||||
## 3.1 **🤖📋AI plan**: Component Decomposition
|
||||
For each component in `docs/02_components` do next:
|
||||
```
|
||||
Decompose `@docs/02_components/[##]_[component_name]/spec.md` to the features. If component is simple enough, make only 1 feature, if complex - separate per features. Feature can contain 0 or more APIs. Create `docs/02_components/[##]_[component_name]/[##]_[feature_name]_feature.md` with the next structure:
|
||||
@@ -17,7 +17,7 @@
|
||||
```
|
||||
**👨💻Developer**: Answer the questions AI asked, put as many details as possible
|
||||
|
||||
## 2.2 **🤖AI agent**: Feature implementation
|
||||
## 3.2 **🤖AI agent**: Feature implementation
|
||||
For each component in `docs/02_components/[##]_[component_name]/` folder do next:
|
||||
```
|
||||
Read component description `@docs/02_components/[##]_[component_name]/spec.md`.
|
||||
@@ -29,7 +29,7 @@
|
||||
If integration tests are specified in component spec, then write them and run, and make sure that component working correctly
|
||||
```
|
||||
|
||||
## 2.3 **🤖AI agent**: Solution composition and integration tests
|
||||
## 3.3 **🤖AI agent**: Solution composition and integration tests
|
||||
```
|
||||
Read all the files here `docs/03_tests/` and for each file write down tests and run it.
|
||||
Compose a final test results in a csv with the next format:
|
||||
Reference in New Issue
Block a user