Предмет данного исследования — процессы разработки и управления нормативными документами к проектируемым системам.
Целью данной работы является разработка рекомендации по оптимизации процессов управления нормативными документами к проектируемым системам.
Задачи:
– Произвести анализ процессов разработки нормативных документов в различных методологиях разработки информационных систем.
– Выявить проблемы, которые возникают при разработке нормативной документации.
– Разработать рекомендации по повышению эффективности процесса разработки и управления нормативной документацией.
Рассмотрим процесс разработки документации в двух основных методологиях разработки систем: Waterfall (Водопадная), Agile (гибкая).
Модель Waterfall относится к классическому пониманию разработки систем. Весь процесс является жестким и линейным, имеет четкие цели для каждого этапа, новая фаза начинается по завершению предыдущей, нет возврата назад.
При данной модели, выполняется полное документирование каждого этапа. Разработка документов в основном регламентируется ГОСТами и различными методологиями (ГОСТ 34, ГОСТ 19, IEEE STD 830–1998, ISO/IEC/ IEEE 29148–2011, SWEBOK, BABOK).
Определение перечня проектных документов, которые должны быть разработаны на каждом этапе жизненного цикла системы является одной из важных задач в процессе внедрения информационной системы.
Утвержденный перечень нормативных документов к каждому этапу жизненного цикла системы, позволяет при завершении каждого этапа, выполнять проверку полученных решений на их соответствие требованиям, которые определены в нормативных документах к текущему этапу [1].
Модель Agile подразумевает создание проекта в несколько итераций, в конце каждого виден конкретный результат, который позволяет понять, по какому пути двигаться дальше.
Разработка по Agile не перегружена излишней документацией — минимум документации. При этом принципы Agile не дают никаких четких принципов, указаний о том, как документировать, но Agile не отрицает разработку нормативных документов. Эта методика указывает, что разрабатывать документацию нужно только когда это необходимо и при условии высокого качества таковой. В Agile качество документации становится одним из решающих факторов успеха.
Существуют следующие проблемы документирования при разработке по Agile:
– Отсутствует предопределенный перечень документов, которые необходимо разработать в рамках проекта.
– Документация разрабатывается только для определённого спринта.
– Отсутствие поддержки актуальности документов.
– Отсутствует документ, описывающий систему в целом — это порождаем проблему долгосрочной адаптации новых сотрудников к проекту.
Во избежание ненужного документирования и решения первой проблемы, необходимо определить потребность документирования. Для определения потребности нужно выявить:
- Цели документации. Для решения каких задач она необходима?
- Целевую аудиторию документации и то, как она будет использовать документацию.
- Стоимость и время для разработки документации.
Выявив потребность в документировании, необходимо определить виды документов, которые нужно разработать, для этого необходимо:
- Определить с целевой аудиторией документацию, которую необходимо разработать, на каждом этапе проекта: перед началом проекта, во время проекта и когда продукт будет разработан и выпущен.
- Определить, доступный и постоянно обновляющийся репозитории, для хранения документации.
- Определить, при каких событиях должна создаваться документация. В отличие от каскадной структуры, в Agile нет отдельного этапа для документирования. Поэтому документация должна создаваться по мере того, как появляются новые разработанные функции.
После выявления потребности и определении перечня необходимых документов, получен план документирования проекта, который отражает:
– Перечень документации необходимой и достаточной для проекта.
– Виды документов.
– Доступ и хранение документации.
– Когда будет создаваться документация.
Выделим следующие виды документов, на которые можно ориентироваться при документировании, на каждом этапе проекта:
– Стартовая документация — может содержать несколько диаграмм высокоуровневой архитектуры. В функциональных требованиях достаточно обозначить эпиками главные характеристики разрабатываемого продукта.
– Проектная документация — во время разработки продукта, могут создаваться два вида документации:
– Необходимые и достаточные требования — как часть бэклога.
– Внедренные системные и бизнес-правила — на выходе каждого спринта.
– Функциональная документация — User story. По мере последовательного выполнения пользовательских историй создается документация, необходимая для целевой аудитории.
– Техническая документация — техническая документация, описывающая код, размещенная непосредственно в коде.
– Постпроектная документация — к концу цикла разработки вся документация — техническая и функциональная — должна описывать все реализованные характеристики.
Литература:
- Кузнецова М. А., Виды нормативной документации, разрабатываемой к информационной системе на различных этапах её жизненного цикла, Молодой ученый Международный научный журнал № 12 (250) / 2019 23 с.
- Всеев Л.В, Голяков С.М, Журавлева А. Ю., Проблемы применения Agile подходов по управлению проектами в Российских ИТ-компаниях и способы их решения, Журнал Наука и мир, 2016
- Пархимович Л. В., Методология разработки по Agile software development, Геология и нефтегазонность Западно-Сибирского мегабассейна Материалы Всероссийской научно-технической конференции, посвященной 100-летию Байбакова Николая Константиновича. 2011
