Программная документация
Строго говоря, согласно ГОСТ 19.101, программной называется документация, перечисленная на рисунке. Как видите, ТЗ в неё не входит - это отдельный документ в составе техно-рабочего проекта. А вот руководства разных категорий пользователей - да. Также в её состав включают программу и методику испытаний (тест-кейсы), краткую характеристику продукта (описание программы) и ряд других артефактов.
Программная документация - по ГОСТ 34.201 и как правило - разрабатывается на стадиях эскизного и/или техно-рабочего проектов, после согласования ТЗ: нет смысла писать тесты и, тем более, пояснительную записку с мануалами, если вы ещё на этапе функционального моделирования.
Вы справедливо спросите - причём тут мы? Судя по составу пакета программной документации, её должен выкатывать кто угодно, кроме аналитиков. Если формально, действительно - более или менее за нами лишь пояснительная записка.
Однако посмотрим правде в глаза - как минимум, наши консультации понадобятся QA-инженерам для подготовки ПМИ, техписам - для описания программы, спецификации и руководств. Более того, писатели востребованы не часто, разве что в геймдеве, и многие по сути непрофильные задачи перекладывают на аналитиков - из экономии и нехватки желающих на относительно дешёвую в среднем позицию техписа.
Программная документация - по ГОСТ 34.201 и как правило - разрабатывается на стадиях эскизного и/или техно-рабочего проектов, после согласования ТЗ: нет смысла писать тесты и, тем более, пояснительную записку с мануалами, если вы ещё на этапе функционального моделирования.
Вы справедливо спросите - причём тут мы? Судя по составу пакета программной документации, её должен выкатывать кто угодно, кроме аналитиков. Если формально, действительно - более или менее за нами лишь пояснительная записка.
Однако посмотрим правде в глаза - как минимум, наши консультации понадобятся QA-инженерам для подготовки ПМИ, техписам - для описания программы, спецификации и руководств. Более того, писатели востребованы не часто, разве что в геймдеве, и многие по сути непрофильные задачи перекладывают на аналитиков - из экономии и нехватки желающих на относительно дешёвую в среднем позицию техписа.
Как организовать документооборот артефактов разработки?
Еще в далеком 2002 г. автор классического учебника "Проектирование программного обеспечения экономических информационных систем" Александр Вендров отмечал, что "в основе программной инженерии лежит одна фундаментальная идея: проектирование ПО является формальным процессом, который можно изучать и совершенствовать".
Попробуем представить один из возможных вариантов последовательности работ по документированию основных этапов разработки (см. рис.).
Еще в далеком 2002 г. автор классического учебника "Проектирование программного обеспечения экономических информационных систем" Александр Вендров отмечал, что "в основе программной инженерии лежит одна фундаментальная идея: проектирование ПО является формальным процессом, который можно изучать и совершенствовать".
Попробуем представить один из возможных вариантов последовательности работ по документированию основных этапов разработки (см. рис.).
Как видно на схеме, процесс разбит на 4 стадии: инициация, постановка, реализация и внедрение.
Описанный в схеме документооборот больше годится для продуктовой разработки, но может быть адаптирован и для других типов команд.
Каков порядок взаимодействия участников проекта разработки? Как выстраивается коммуникация в процессе работы над проектной документацией?
Рекомендую начать с источника требований - в зависимости от него подключаются те или иные роли и складывается последовательность артефактов. Затем определяем, кто собирает и кто обрабатывает входящие требования, что получаем в результате, с кем согласовываем, куда эскалируем и кто в итоге занимается реализацией постановки. Примерную матрицу процесса описал в таблице ниже.
- Инициация может включать подготовку заявок на участие в конкурсах, технико-коммерческих предложений, согласование условий и оформление контракта, уточнение бизнес-требований. В целом стадия соответствует 1 и частично 2 этапам создания АИС по ГОСТ Р 59793–2021.
- Постановка предполагает фиксацию собранных требований к системе, бизнес- и функциональное, инфологическое моделирование, подготовку бэклога и плана работ - это 2 и 3 стадии ГОСТа.
- Реализация - это про разработку архитектуры, описание подробных требований по компонентам, сценариев использования, интерфейсов, прочих особенностей технической реализации, тестирования и подготовку релизноутов, 4 - 6 стадии ГОСТа.
- Внедрение - про все артефакты для инсталляции, обучения пользователей и сопровождения системы, 7 и 8 стадии ГОСТа.
Описанный в схеме документооборот больше годится для продуктовой разработки, но может быть адаптирован и для других типов команд.
Каков порядок взаимодействия участников проекта разработки? Как выстраивается коммуникация в процессе работы над проектной документацией?
Рекомендую начать с источника требований - в зависимости от него подключаются те или иные роли и складывается последовательность артефактов. Затем определяем, кто собирает и кто обрабатывает входящие требования, что получаем в результате, с кем согласовываем, куда эскалируем и кто в итоге занимается реализацией постановки. Примерную матрицу процесса описал в таблице ниже.
Номера столбцов указывают направление цепи взаимодействия в процессе сбора, обработки, утверждения и реализации постановочных требований – по возрастанию, от меньшего к большему. Номера строк указывают на вид источника постановочных требований, название каждого вида источника содержится на пересечении соответствующей строки со столбцом 1.
Полученные результаты обработки требований (столбец 4) перед передачей на реализацию должны быть согласованы с указанными в столбце 5 лицами. При возникновении неразрешимых противоречий процесс эскалируется, и решение по конфликту принимается лицом, указанным в столбце 6.
Полученные результаты обработки требований (столбец 4) перед передачей на реализацию должны быть согласованы с указанными в столбце 5 лицами. При возникновении неразрешимых противоречий процесс эскалируется, и решение по конфликту принимается лицом, указанным в столбце 6.