Сначала таблица соответствий — что есть, потом детально по каждому разделу о пробелах.
3.1 — Планирование подхода к бизнес-анализу
Что реализовано:suggest_ba_approach() принимает change_frequency, uncertainty, regulatory_need и по матрице APPROACH_MATRIX из common.py выдаёт Predictive / Agile / Hybrid с compliance override. Сохраняет методологию и набор техник в ba_plan.json.
Что не попало:
BABOK 3.1.4 описывает шесть элементов подхода к планированию. Инструмент закрывает элемент .1 Подход к планированию (выбор методологии) и частично .5 Сложность и риск (через uncertainty). Остальные четыре элемента отсутствуют:
.2 Формальность и уровень детализации результатов — BABOK требует явно определить, насколько формальной будет документация. В инструменте этого нет: нет параметра или логики, которая бы фиксировала, будут ли артефакты по шаблонам или в свободной форме.
.3 Действия бизнес-анализа — BABOK говорит о разбиении работы на конкретные действия и задачи с итерациями. suggest_ba_approach() возвращает список техник ([«Workshops», «User Stories»]), но не план действий — нет связи с конкретными задачами BABOK и нет понятия итерации или фазы.
.4 Определение сроков работ по бизнес-анализу — когда и в какой последовательности выполнять задачи BA. Полностью отсутствует.
.6 Приемка подхода — BABOK требует, чтобы подход был рассмотрен и согласован ключевыми стейкхолдерами. В системе нет механизма подтверждения подхода стейкхолдерами; save_ba_plan() финализирует документ без шага одобрения.
3.2 — Планирование вовлечения заинтересованных сторон
Что реализовано:plan_stakeholder_engagement() строит Power/Interest Grid, классифицирует по четырём квадрантам, назначает стратегию и частоту коммуникации.
Что не попало:
BABOK 3.2.4 описывает три элемента. Первый — анализ заинтересованных сторон — реализован хорошо: роли, influence, interest, attitude есть в модели Stakeholder. Но второй и третий элементы закрыты лишь частично:
.2 Определение сотрудничества с заинтересованными сторонами — BABOK требует планировать конкретные формы сотрудничества (воркшоп, интервью, wiki, лично или онлайн) для каждой группы. В инструменте определяется только квадрант и частота коммуникации («Еженедельно», «При вехах»), но не конкретные форматы взаимодействия.
.3 Потребности коммуникации с заинтересованными сторонами — BABOK перечисляет восемь параметров: что сообщать, метод доставки (письменный/устный), аудитория, когда, частота, географическое положение, уровень детализации, уровень формальности. В инструменте из этого восьмёрки присутствует только частота. Остальное отсутствует — нет плана коммуникации как такового, только матрица вовлечения.
Также принципиально: BABOK подчёркивает, что анализ заинтересованных сторон выполняется многократно в течение всей инициативы. В AInalyst plan_stakeholder_engagement() вызывается один раз при планировании. update_stakeholder_registry() из 4.2 добавляет стейкхолдеров итеративно — это правильно, но обновления реестра не перезапускают процесс анализа Power/Interest и не пересматривают стратегии вовлечения для уже известных участников.
3.3 — Планирование руководства бизнес-анализом
Что реализовано:plan_ba_governance() фиксирует decision_makers, процесс контроля изменений, критичность проекта.
Что не попало — наибольший пробел в главе 3.
BABOK 3.3.4 определяет четыре элемента. Инструмент покрывает .1 Принятие решений (кто принимает решения, пути эскалации) на базовом уровне. Остальные три — существенно не закрыты:
.2 Процесс управления изменениями — BABOK описывает семь конкретных вещей, которые нужно определить при проектировании процесса CR: как запрашивать изменения, элементы запроса (стоимость, выгоды, риски, приоритет), как приоритизировать, как документировать, как сообщать, кто анализирует влияние, кто санкционирует. plan_ba_governance() принимает change_control_process как свободный текст. Реальный процесс управления CR проектируется не здесь, а существует как факт в requirements_assess_changes_mcp.py — но без связи с решениями, принятыми на этапе планирования.
.3 Планирование подхода к приоритизации — BABOK требует заранее определить формальность процесса, участников, техники и критерии приоритизации. В планировании это не фиксируется. requirements_prioritize_mcp.py просто предлагает три метода на выбор, но это решение принимается на ходу, а не планируется в начале проекта.
.4 Планирование одобрения — BABOK требует заранее определить, что именно подлежит одобрению, в какие сроки, по какому процессу и кто одобряет. Это не планируется явно: requirements_approve_mcp.py работает по умолчанию, без связи с решениями, принятыми при governance-планировании.
3.4 — Планирование управления информацией бизнес-анализа
Что реализовано:plan_information_management() фиксирует инструменты хранения, уровень трассировки, типы артефактов, правила доступа.
Что не попало:
.2 Уровень абстракции — BABOK говорит о том, что разным стейкхолдерам нужны разные уровни детализации, и это нужно планировать заранее. В инструменте этого нет. Архитектура требований (сервер 7.4) создаёт представления для разных аудиторий позже, но без опоры на план, созданный здесь.
.4 Планирование повторного использования требований — BABOK выделяет это отдельным элементом: как структурировать требования, чтобы они были пригодны для будущих инициатив. В инструменте планирования этого нет. find_reusable_requirements() из 5.2 находит кандидатов реактивно, уже после создания требований, а не планирует повторное использование заранее.
.6 Атрибуты требований — BABOK перечисляет девять стандартных атрибутов: абсолютная ссылка, автор, сложность, владелец, приоритет, риски, источник, стабильность, статус, срочность. В plan_information_management() набор атрибутов не планируется. Фактические атрибуты в traceability_repo.json определены жёстко внутри серверов 7.1 и 5.1 — но решение о том, какие атрибуты использовать в проекте, на этапе планирования не принимается.
3.5 — Определение возможностей улучшения эффективности
Что реализовано:evaluate_ba_performance() фиксирует текущие проблемы, метрики и генерирует план улучшений.
Что не попало:
Здесь содержательный пробел меньше, чем в других разделах, но он есть.
.1 Анализ эффективности и .3 Анализ результатов — BABOK описывает мониторинг как непрерывный процесс на протяжении всей инициативы. В AInalyst evaluate_ba_performance() вызывается разово, как инструмент планирования. Нет механизма периодического повторения — хука или напоминания, который бы предлагал BA запустить оценку в середине проекта или в конце фазы.
.2 Оценочные показатели — BABOK описывает семь показателей: правильность и полнота, знание, эффективность, организационная поддержка, значимость, стратегический аспект, своевременность. Инструмент принимает metrics_json в свободной форме, но не предлагает эти стандартные BABOK-метрики как шаблон.
Системный пробел: мониторинг
В названии главы 3 — «Планирование и мониторинг бизнес-анализа». Слово «мониторинг» в коде практически отсутствует. BABOK явно говорит, что планы обновляются в ответ на изменяющиеся условия, эффективность отслеживается непрерывно, а подход к BA может меняться по ходу инициативы.
В AInalyst глава 3 работает как одноразовый setup — создал план, сохранил в ba_plan.json, перешёл к следующей фазе. Нет ни одного инструмента для:
сравнения запланированного с фактическим по ходу проекта,
обновления подхода при изменении условий,
периодических check-in на соответствие плана реальности.
По сути, ba_plan.json создаётся в начале и больше никем не читается — ни один из 21 остальных серверов не обращается к нему как к входящему контексту.
Анализ проекта AInalyst: соответствие лучшим практикам Claude Code
Изучил README, CLAUDE.md, CHANGELOG и структуру репозитория. Анализирую по двум осям: Skills и MCP.
✅ Что сделано правильно
Архитектурное мышление. Авторы реально поняли фундаментальную идею: контекстное окно — дефицитный ресурс. Система фаз (planning, elicitation, lifecycle, analysis, design, full) — это именно то, что нужно делать: загружать только нужные инструменты в нужный момент. В CHANGELOG даже указана экономия токенов как метрика.
CLAUDE.md как системный промпт агента. Файл написан грамотно — чёткая роль, пошаговый workflow, таблица фаз с примерами, инструкции про /restart. Это правильная практика: CLAUDE.md должен быть операционным руководством для агента, а не документацией для людей.
Разделение данных и артефактов.governance_plans/reports/ для Markdown-артефактов, governance_plans/data/ для JSON-состояния системы — чистое разделение между human-readable outputs и machine state.
Hooks (SessionStart, PostToolUse) упомянуты в CHANGELOG. Это продвинутый приём — автоматическое управление контекстом между вызовами инструментов.
Структура проекта (inputs/, governance_plans/, skills/, docs/) логична и предсказуема.
⚠️ Отклонения от канонических практик по Skills
Здесь ключевое расхождение. В стандарте Anthropic скилл — это самодостаточная папка с одним файлом SKILL.md, содержащим YAML frontmatter и инструкции GitHub. YAML-заголовок содержит поля name и description, по которым Claude Code решает, когда активировать скилл.
В ainalyst авторы описывают в README, что скиллы содержат «YAML-заголовок с триггерами». Это правильно по духу, но есть нюанс: скиллы лежат в skills/ в корне проекта, а не в .claude/skills/. Каноническое расположение для project-level скиллов — .claude/skills/. Из-за этого они не подхватываются автоматически Claude Code marketplace/plugin-системой. Авторы, судя по всему, задействуют их через CLAUDE.md вручную, а не через встроенный механизм <available_skills>.
Это не критическая ошибка — рабочий workaround — но если система масштабируется, интеграция со стандартным путём дала бы прогрессивную загрузку скиллов «из коробки».
⚠️ Отклонения по MCP
Нет mcp.json / .mcp.json в репозитории (или он в .claude/, которая не видна из-за robots.txt на деревья). Стандартная практика — хранить конфигурацию MCP-серверов в .mcp.json (для project-scope) или передавать через settings.json. Авторы управляют этим через phase.py, который, судя по всему, динамически переписывает конфигурацию при переключении фаз — нестандартный, но рабочий подход.
Ручной /restart при смене фазы — это UX-проблема. Стандарт предполагает, что смена набора MCP-серверов должна происходить прозрачно. Требование вручную вводить /restart — следствие архитектурного ограничения (Claude Code перезагружает MCP при старте сессии). Это известное ограничение платформы, авторы компенсируют его через явную инструкцию в CLAUDE.md — решение приемлемое, но неизящное.
22 MCP-сервера — впечатляющий масштаб. Идея разбить их на фазы вместо одной монолитной конфигурации — правильная инженерная интуиция.
🔴 Потенциальные проблемы
Нет settings.json для Claude Code с явным mcpServers блоком в репозитории (по крайней мере публично). Новый разработчик, клонирующий репо, не сразу понимает как именно подключаются MCP-серверы — только через README и phase.py.
export_pdf.py и phase.py в корне — утилиты уровня tooling лучше выносить в scripts/ или tools/, чтобы корень проекта не загромождался.
Тесты в tests/ есть, это хорошо. Но непонятно, покрывают ли они логику самих скиллов или только Python-утилиты — тестирование prompt-логики нетривиально.
Итоговая оценка
Аспект Оценка Комментарий Архитектурная идея★★★★★Фазовое управление контекстом — сильное решение CLAUDE.md★★★★☆Хорошо написан, операционален Skills (расположение)★★★☆☆Не в .claude/skills/, нестандартно MCP (конфигурация)★★★☆☆phase.py вместо mcp.json, работает но нестандартно UX смены фазы★★☆☆☆Ручной /restart — костыль Документация★★★★★README, use-cases, developer-guide — отличная
Резюме: проект демонстрирует нестандартное, но продуманное использование Claude Code. Главное расхождение с каноническими практиками — в физическом расположении скиллов и способе управления MCP-конфигурацией. Это не баги, а сознательные архитектурные компромиссы — авторы явно понимают ограничения платформы и работают вокруг них. Для production-use достаточно. Для примера «как делать правильно» — стоит перенести скиллы в .claude/skills/ и добавить явный .mcp.json.
Согласен. Под конечным автоматом я подразумеваю детерминированный конечный автомат.
Согласен, что недетерминированный конечный автомат может иметь несколько активных состояний. Однако у моего структурного автомата присутствует ещё и особое состояние "Точка сборки". Мой структурный автомат нельзя назвать НДКА.
Главная задача публикации - показать, что структурный автомат имеет относительно простую программную реализацию.
По функциональности структурный автомат, конечно же, уступает BPMN, но вполне подходит для описания определённого класса бизнес-процессов. В этот класс входят, например, процессы прохождения документов по своему жизненному циклу.
Отличное начало по ИИ-зации БА:
Что из главы 3 BABOK не попало в AInalyst
Сначала таблица соответствий — что есть, потом детально по каждому разделу о пробелах.
3.1 — Планирование подхода к бизнес-анализу
Что реализовано:
suggest_ba_approach()принимаетchange_frequency,uncertainty,regulatory_needи по матрицеAPPROACH_MATRIXизcommon.pyвыдаёт Predictive / Agile / Hybrid с compliance override. Сохраняет методологию и набор техник вba_plan.json.Что не попало:
BABOK 3.1.4 описывает шесть элементов подхода к планированию. Инструмент закрывает элемент
.1 Подход к планированию(выбор методологии) и частично.5 Сложность и риск(черезuncertainty). Остальные четыре элемента отсутствуют:.2 Формальность и уровень детализации результатов— BABOK требует явно определить, насколько формальной будет документация. В инструменте этого нет: нет параметра или логики, которая бы фиксировала, будут ли артефакты по шаблонам или в свободной форме..3 Действия бизнес-анализа— BABOK говорит о разбиении работы на конкретные действия и задачи с итерациями.suggest_ba_approach()возвращает список техник ([«Workshops», «User Stories»]), но не план действий — нет связи с конкретными задачами BABOK и нет понятия итерации или фазы..4 Определение сроков работ по бизнес-анализу— когда и в какой последовательности выполнять задачи BA. Полностью отсутствует..6 Приемка подхода— BABOK требует, чтобы подход был рассмотрен и согласован ключевыми стейкхолдерами. В системе нет механизма подтверждения подхода стейкхолдерами;save_ba_plan()финализирует документ без шага одобрения.3.2 — Планирование вовлечения заинтересованных сторон
Что реализовано:
plan_stakeholder_engagement()строит Power/Interest Grid, классифицирует по четырём квадрантам, назначает стратегию и частоту коммуникации.Что не попало:
BABOK 3.2.4 описывает три элемента. Первый — анализ заинтересованных сторон — реализован хорошо: роли, influence, interest, attitude есть в модели
Stakeholder. Но второй и третий элементы закрыты лишь частично:.2 Определение сотрудничества с заинтересованными сторонами— BABOK требует планировать конкретные формы сотрудничества (воркшоп, интервью, wiki, лично или онлайн) для каждой группы. В инструменте определяется только квадрант и частота коммуникации («Еженедельно»,«При вехах»), но не конкретные форматы взаимодействия..3 Потребности коммуникации с заинтересованными сторонами— BABOK перечисляет восемь параметров: что сообщать, метод доставки (письменный/устный), аудитория, когда, частота, географическое положение, уровень детализации, уровень формальности. В инструменте из этого восьмёрки присутствует только частота. Остальное отсутствует — нет плана коммуникации как такового, только матрица вовлечения.Также принципиально: BABOK подчёркивает, что анализ заинтересованных сторон выполняется многократно в течение всей инициативы. В AInalyst
plan_stakeholder_engagement()вызывается один раз при планировании.update_stakeholder_registry()из 4.2 добавляет стейкхолдеров итеративно — это правильно, но обновления реестра не перезапускают процесс анализа Power/Interest и не пересматривают стратегии вовлечения для уже известных участников.3.3 — Планирование руководства бизнес-анализом
Что реализовано:
plan_ba_governance()фиксируетdecision_makers, процесс контроля изменений, критичность проекта.Что не попало — наибольший пробел в главе 3.
BABOK 3.3.4 определяет четыре элемента. Инструмент покрывает
.1 Принятие решений(кто принимает решения, пути эскалации) на базовом уровне. Остальные три — существенно не закрыты:.2 Процесс управления изменениями— BABOK описывает семь конкретных вещей, которые нужно определить при проектировании процесса CR: как запрашивать изменения, элементы запроса (стоимость, выгоды, риски, приоритет), как приоритизировать, как документировать, как сообщать, кто анализирует влияние, кто санкционирует.plan_ba_governance()принимаетchange_control_processкак свободный текст. Реальный процесс управления CR проектируется не здесь, а существует как факт вrequirements_assess_changes_mcp.py— но без связи с решениями, принятыми на этапе планирования..3 Планирование подхода к приоритизации— BABOK требует заранее определить формальность процесса, участников, техники и критерии приоритизации. В планировании это не фиксируется.requirements_prioritize_mcp.pyпросто предлагает три метода на выбор, но это решение принимается на ходу, а не планируется в начале проекта..4 Планирование одобрения— BABOK требует заранее определить, что именно подлежит одобрению, в какие сроки, по какому процессу и кто одобряет. Это не планируется явно:requirements_approve_mcp.pyработает по умолчанию, без связи с решениями, принятыми при governance-планировании.3.4 — Планирование управления информацией бизнес-анализа
Что реализовано:
plan_information_management()фиксирует инструменты хранения, уровень трассировки, типы артефактов, правила доступа.Что не попало:
.2 Уровень абстракции— BABOK говорит о том, что разным стейкхолдерам нужны разные уровни детализации, и это нужно планировать заранее. В инструменте этого нет. Архитектура требований (сервер 7.4) создаёт представления для разных аудиторий позже, но без опоры на план, созданный здесь..4 Планирование повторного использования требований— BABOK выделяет это отдельным элементом: как структурировать требования, чтобы они были пригодны для будущих инициатив. В инструменте планирования этого нет.find_reusable_requirements()из 5.2 находит кандидатов реактивно, уже после создания требований, а не планирует повторное использование заранее..6 Атрибуты требований— BABOK перечисляет девять стандартных атрибутов: абсолютная ссылка, автор, сложность, владелец, приоритет, риски, источник, стабильность, статус, срочность. Вplan_information_management()набор атрибутов не планируется. Фактические атрибуты вtraceability_repo.jsonопределены жёстко внутри серверов 7.1 и 5.1 — но решение о том, какие атрибуты использовать в проекте, на этапе планирования не принимается.3.5 — Определение возможностей улучшения эффективности
Что реализовано:
evaluate_ba_performance()фиксирует текущие проблемы, метрики и генерирует план улучшений.Что не попало:
Здесь содержательный пробел меньше, чем в других разделах, но он есть.
.1 Анализ эффективностии.3 Анализ результатов— BABOK описывает мониторинг как непрерывный процесс на протяжении всей инициативы. В AInalystevaluate_ba_performance()вызывается разово, как инструмент планирования. Нет механизма периодического повторения — хука или напоминания, который бы предлагал BA запустить оценку в середине проекта или в конце фазы..2 Оценочные показатели— BABOK описывает семь показателей: правильность и полнота, знание, эффективность, организационная поддержка, значимость, стратегический аспект, своевременность. Инструмент принимаетmetrics_jsonв свободной форме, но не предлагает эти стандартные BABOK-метрики как шаблон.Системный пробел: мониторинг
В названии главы 3 — «Планирование и мониторинг бизнес-анализа». Слово «мониторинг» в коде практически отсутствует. BABOK явно говорит, что планы обновляются в ответ на изменяющиеся условия, эффективность отслеживается непрерывно, а подход к BA может меняться по ходу инициативы.
В AInalyst глава 3 работает как одноразовый setup — создал план, сохранил в
ba_plan.json, перешёл к следующей фазе. Нет ни одного инструмента для:сравнения запланированного с фактическим по ходу проекта,
обновления подхода при изменении условий,
периодических check-in на соответствие плана реальности.
По сути,
ba_plan.jsonсоздаётся в начале и больше никем не читается — ни один из 21 остальных серверов не обращается к нему как к входящему контексту.Sonnet 4.6:
Анализ проекта AInalyst: соответствие лучшим практикам Claude Code
Изучил README, CLAUDE.md, CHANGELOG и структуру репозитория. Анализирую по двум осям: Skills и MCP.
✅ Что сделано правильно
Архитектурное мышление. Авторы реально поняли фундаментальную идею: контекстное окно — дефицитный ресурс. Система фаз (
planning,elicitation,lifecycle,analysis,design,full) — это именно то, что нужно делать: загружать только нужные инструменты в нужный момент. В CHANGELOG даже указана экономия токенов как метрика.CLAUDE.md как системный промпт агента. Файл написан грамотно — чёткая роль, пошаговый workflow, таблица фаз с примерами, инструкции про
/restart. Это правильная практика: CLAUDE.md должен быть операционным руководством для агента, а не документацией для людей.Разделение данных и артефактов.
governance_plans/reports/для Markdown-артефактов,governance_plans/data/для JSON-состояния системы — чистое разделение между human-readable outputs и machine state.Hooks (SessionStart, PostToolUse) упомянуты в CHANGELOG. Это продвинутый приём — автоматическое управление контекстом между вызовами инструментов.
Структура проекта (
inputs/,governance_plans/,skills/,docs/) логична и предсказуема.⚠️ Отклонения от канонических практик по Skills
Здесь ключевое расхождение. В стандарте Anthropic скилл — это самодостаточная папка с одним файлом
SKILL.md, содержащим YAML frontmatter и инструкции GitHub. YAML-заголовок содержит поляnameиdescription, по которым Claude Code решает, когда активировать скилл.В ainalyst авторы описывают в README, что скиллы содержат «YAML-заголовок с триггерами». Это правильно по духу, но есть нюанс: скиллы лежат в
skills/в корне проекта, а не в.claude/skills/. Каноническое расположение для project-level скиллов —.claude/skills/. Из-за этого они не подхватываются автоматически Claude Code marketplace/plugin-системой. Авторы, судя по всему, задействуют их через CLAUDE.md вручную, а не через встроенный механизм<available_skills>.Это не критическая ошибка — рабочий workaround — но если система масштабируется, интеграция со стандартным путём дала бы прогрессивную загрузку скиллов «из коробки».
⚠️ Отклонения по MCP
Нет
mcp.json/.mcp.jsonв репозитории (или он в.claude/, которая не видна из-за robots.txt на деревья). Стандартная практика — хранить конфигурацию MCP-серверов в.mcp.json(для project-scope) или передавать черезsettings.json. Авторы управляют этим черезphase.py, который, судя по всему, динамически переписывает конфигурацию при переключении фаз — нестандартный, но рабочий подход.Ручной
/restartпри смене фазы — это UX-проблема. Стандарт предполагает, что смена набора MCP-серверов должна происходить прозрачно. Требование вручную вводить/restart— следствие архитектурного ограничения (Claude Code перезагружает MCP при старте сессии). Это известное ограничение платформы, авторы компенсируют его через явную инструкцию в CLAUDE.md — решение приемлемое, но неизящное.22 MCP-сервера — впечатляющий масштаб. Идея разбить их на фазы вместо одной монолитной конфигурации — правильная инженерная интуиция.
🔴 Потенциальные проблемы
Нет
settings.jsonдля Claude Code с явнымmcpServersблоком в репозитории (по крайней мере публично). Новый разработчик, клонирующий репо, не сразу понимает как именно подключаются MCP-серверы — только через README иphase.py.export_pdf.pyиphase.pyв корне — утилиты уровня tooling лучше выносить вscripts/илиtools/, чтобы корень проекта не загромождался.Тесты в
tests/есть, это хорошо. Но непонятно, покрывают ли они логику самих скиллов или только Python-утилиты — тестирование prompt-логики нетривиально.Итоговая оценка
Аспект Оценка Комментарий
Архитектурная идея★★★★★Фазовое управление контекстом — сильное решение CLAUDE.md★★★★☆Хорошо написан, операционален
Skills (расположение)★★★☆☆Не в
.claude/skills/, нестандартноMCP (конфигурация)★★★☆☆
phase.pyвместоmcp.json, работает но нестандартноUX смены фазы★★☆☆☆Ручной
/restart— костыльДокументация★★★★★README, use-cases, developer-guide — отличная
Резюме: проект демонстрирует нестандартное, но продуманное использование Claude Code. Главное расхождение с каноническими практиками — в физическом расположении скиллов и способе управления MCP-конфигурацией. Это не баги, а сознательные архитектурные компромиссы — авторы явно понимают ограничения платформы и работают вокруг них. Для production-use достаточно. Для примера «как делать правильно» — стоит перенести скиллы в
.claude/skills/и добавить явный.mcp.json.Не так много таких проектов на гитхабе. Интересно.
Автор забыл добавить пункт об установке Claude code и git и npm. :(
Расширение claude code для vs code не будет работать без самого claude code.
Claude code не будет работать без git и npm.
И vs code здесь совсем лишний. Питона хватит.
Здравствуйте!
Как сделать так, чтобы для каждого нового вопроса не надо было запускать программу заново?
Спасибо за комментарий.
Согласно https://ru.wikipedia.org/wiki/Сетевой_график
"в сетевом графике не должно быть замкнутых контуров",
что никак не подходит для описания бизнес-процессов.
Структурный автомат (его точка сборки), больше похож на примитивную сеть Петри (переходы) . О чём и указано в тексте.
Согласен. Под конечным автоматом я подразумеваю детерминированный конечный автомат.
Согласен, что недетерминированный конечный автомат может иметь несколько активных состояний. Однако у моего структурного автомата присутствует ещё и особое состояние "Точка сборки". Мой структурный автомат нельзя назвать НДКА.
Главная задача публикации - показать, что структурный автомат имеет относительно простую программную реализацию.
По функциональности структурный автомат, конечно же, уступает BPMN, но вполне подходит для описания определённого класса бизнес-процессов. В этот класс входят, например, процессы прохождения документов по своему жизненному циклу.