Я как программист участвую в разработке программного инструмента/среды для внутреннего использования (этот инструмент – это часть системы создания UWB чипов как целевой системы). Инструмент используется дизайнерами аналоговых цепей, которые дизайнили чип, чтобы исследовать функционирование различных цепей на “живом” чипе, экспериментировать, отлаживать, находить баги в железе, делать замеры производительности, и находить хорошие настройки цепей чипа, чтобы использовать эти настройки в продукте (целевой системе).
В какой-то момент возникла неясность насчет того, кто за что отвечает, и кто какие рабочие продукты выпускает (а также когда, как и кто проводит приёмку этих продуктов). Возникли закольцованные зависимости. Например, дизайнеры чипа хотели регулярно получать новые версии программных библиотек для чипа, при этом, чтобы ничего из их старых тестов не ломалось, или как минимум хотели знать, что изменилось в новой версии. Софтверные инженеры ожидали что дизайнеры будут выпускать/“релизить” таблицы настроек чипа (в виде констант/массивов на Си) и мелкие функции на Си для управления блоками чипа, чтобы поместить в те же библиотеки.
На одном из созвонов, где обсуждались “релизы”, я заметил, что разные участники говорили о совершенно разных объектах, которые должны “релизиться”.
Также возник конфликт ролевых предпочтений. Дизайнеры железа не эксперты в программировании, поэтому их код вызывает боль у программистов. Значит использовать их код напрямую нельзя, каждый раз когда они релизят какой-то код, его нужно переписать. А раз переписать, то и потом интегрировать в их (дизайнеров) тесты, прогнать эти тесты ещё раз; то есть возникают какие-то нетривиальные завихрения “процессов”, где каждое завихрение включает время ожидания, координацию, а тем временем “паровоз” разработки мчится вперёд так как другие инженеры тоже меняют/добавляют код. С учетом того, что никто это заранее не планировал, и все заняты “своими задачами”, это всё вызывает много стресса и непонимания.
Я написал текст (в основном размышление письмом, так как его никто не принял всерьёз), где попытался разложить ситуацию на роли, их рабочие продукты, кто за что отвечает, кто что кому релизит.
Этот текст (эпистема) точно является описанием, так как явно выделяет объекты. Он также является не очень детальной моделью, так как позволяет делать предсказания о том, что происходило бы и когда, если бы это предложение было воплощено. Впрочем, не факт что эта модель реализуема в текущем виде.
Анализ LLM с FPF
LLM выдала простыню на птичьем языке, в целом понятную. Польза “аналитической части” ответа для меня: 1) образовательная – знакомлюсь с FPF, 2) контрольная – что LLM правильно выделила объекты и определила типы.
LLM согласна с моей оценкой, что текст это U.Episteme и Description Episteme. Отчасти U.MethodDescription и Specification.
Чтобы текст стал спецификацией, LLM рекомендует следующее.
The document currently mixes mandatory rules, recommendations, provisional proposals, explanations, and examples, procedural instructions.
For specification use this should be clearly labeled so that the reader can tell what is binding, optional provisional or merely explanatory.
Missing content that should be added: the exact scope of each release class, which rules are mandatory for each class, which checks must be performed, what counts passing each check, the resulting decision, who is authorized to make the decision, what evidence must be recorded.
Рекомендации в целом соответствуют моим ожиданиям, приятно/полезно получить подтверждение. Ожидаю очень большой помощи от LLM в переписывании этого документа, чтобы он стал спецификацией. Даже зная, чего именно не хватает в изначальной версии, превратить её в структурированный текст спецификации потребовало бы от меня очень много усилий.