Семен, руководитель проектов 1С
В современном мире разработки программного обеспечения одной из важнейших частей является создание качественной технической документации. Она служит мостом между разработчиками, заказчиками и конечными пользователями.
Основной целью такой документации является формализация требований, чтобы избежать недоразумений и ошибок в дальнейшей работе.
Частые проблемы в проектной документации
Однако существует и обратная сторона медали — сложности, связанные с тем, что существует множество видов документов, понятий и технологий.
Рассмотрим ключевые аспекты этой проблематики:
1. Терминологическая путаница. Один и тот же документ может иметь разные названия в разных методологиях или даже в рамках одной компании. Например, «техническое задание» и «спецификация требований» могут означать одно и то же или, наоборот, нечто совершенно разное, в зависимости от контекста.
2. Индивидуальное понимание документации. Разные люди могут по-разному воспринимать и интерпретировать содержание документов, особенно в случае сложной или многозначной терминологии. Это может привести к недопониманию и ошибкам в реализации требований. Например, когда у разных специалистов может быт свое понимание документа «техническое задание».
3. Перекрытие содержания. Некоторые документы могут дублировать друг друга по содержанию, что может привести к неконсистентности данных и потере актуальности одной из версий.
4. Специфичные корпоративные стандарты клиентов. Нередко компании-заказчики имеют собственные, уникальные стандарты документации, которые разработчику приходится учитывать. Это может усложнить процесс, так как потребуется время на изучение и применение этих стандартов.
5. Несоответствие стандартов. Когда стандарты разработчика и клиента не соответствуют друг другу, это может привести к дополнительным затратам времени на приведение документации в соответствие, пересмотру процессов и потенциальным конфликтам.
6. Проблемы с обучением новых сотрудников. Новые члены команды могут испытывать затруднения в адаптации из-за необходимости освоения большого количества документов и понимания специфической терминологии.
Основные документы для фиксации требований
Чтобы немного разобраться в этой проблеме, приведем ниже перечень и краткую характеристику часто используемых проектных документов для фиксации требований:
Техническое задание
- Содержание: ТЗ на АС является основным документом, определяющим требования и порядок создания автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка. При составлении документа рекомендуется учитывать ГОСТ 34.602—2020.
- Назначение: определение и формализация основных требований заказчика к проекту.
- Оглавление: общие сведения; цели и назначение создания автоматизированной системы; характеристика объектов автоматизации; требования к автоматизированной системе; состав и содержание работ по созданию автоматизированной системы; порядок разработки автоматизированной системы; порядок контроля и приемки автоматизированной системы; требования к составу и содержанию работ по подготовке объекта автоматизации к вводу автоматизированной системы в действие; требования к документированию; источники разработки.
- Проектные технологии: широко используется в классической водопадной модели разработки.
Частное техническое задание (ЧТЗ)
- Содержание: в известных стандартах такого понятия нет, но близкое к нему существует в ГОСТ 34.602—2020 и называется техническое задание на составные части. Согласно этому документу, в АС могут выделяться составные части (СЧ), для которых могут разрабатываться ТЗ на составные части (далее — ТЗ на СЧ). ТЗ на СЧ могут разрабатываться следующие составные части: на подсистемы АС, комплексы задач АС, функции АС; на отдельные объекты АС, подлежащие автоматизации в рамках создания АС; на комплектующие изделия, средства технического обеспечения и программно-технические комплексы.
- Назначение: конкретизация и уточнение требований к определенным частям системы. Как правило являются дополнениями к общему ТЗ.
- Оглавление: введение, функциональные требования к части системы, нефункциональные требования, критерии приемки.
- Проектные технологии: применяется в крупных проектах, где необходимо детализировать определенные блоки или функции.
Лист требований
- Содержание: список специфических требований к системе или ее части.
- Назначение: фиксация и отслеживание выполнения конкретных требований.
- Оглавление: общие данные, список требований, способ реализации требований, порядок тестирования, комментарии.
Функциональная спецификация
- Содержание: описание функционала продукта без учета технической реализации.
- Назначение: предоставление полного понимания функций системы.
- Оглавление: введение, список функций, детальное описание каждой функции, ограничения.
- Проектные технологии: широко используется в классической водопадной модели и RUP.
Техническая спецификация
- Содержание: архитектурные и технологические решения для реализации функций.
- Назначение: руководство по технической реализации проекта.
- Оглавление: введение, архитектурные решения, описание технологий, детальная спецификация компонентов.
Функциональный дизайн разработки
- Содержание: визуализация и описание процесса и структуры функций системы.
- Назначение: предоставление четкого понимания того, как будут работать функции.
- Оглавление: введение, диаграммы потоков данных, макеты интерфейсов, описание процессов.
- Проектные технологии: RUP, UML.
Функционально-технические требования
- Содержание: комбинирование функциональных и технических требований.
- Назначение: установление связей между функционалом и технологиями его реализации.
- Оглавление: введение, функциональные требования, технические требования, связи между ними.
Журнал продукта (Product Backlog)
- Содержание: список функций, улучшений, ошибок и других элементов, которые необходимо реализовать в продукте.
- Назначение: планирование разработки продукта, учет и отслеживание задач.
- Оглавление: введение, список задач (приоритет, статус, ответственный), история изменений.
- Проектные технологии: чаще всего применяется в Agile-методологиях, включая Scrum, где журнал продукта является ключевым элементом для планирования итераций.
Пользовательские истории (User Stories)
- Содержание: краткие описания функций с точки зрения пользователя.
- Назначение: описание ожиданий пользователя от системы.
- Оглавление: описание пользователя, его задачи, критерии приемки.
Сценарии использования (Use Cases)
- Содержание: детальное описание взаимодействия пользователя с системой.
- Назначение: визуализация процесса использования системы.
- Оглавление: актеры, предусловия, основной поток, альтернативные потоки, постусловия.
- Проектные технологии: UML, RUP.
Этот перечень не является исчерпывающим, и в зависимости от специфики проекта, требований заказчика и команды разработчиков, может быть свой состав документации. Важно, что в каждом методологическом подходе ценится определенный уровень детализации, формат представления и структура документов. Это служит, с одной стороны, инструментом для достижения эффективности, а с другой — барьером для потенциальной путаницы и неоднозначности.
Вспомогательные документы
Разные технологии и методологии предлагают свои инструменты и документы. Scrum, например, может оперировать такими понятиями как «Журнал продукта» и «Пользовательские истории», которые могут взаимодействовать с традиционными документами по-своему.
К тому же, не стоит забывать о корпоративных стандартах различных компаний. В некоторых организациях могут существовать свои внутренние требования к документированию, которые формировались на основе их опыта и специфики выполненных проектов.
В зарубежных технологиях встречается еще ряд документов, которые описывают требования локально, либо по назначению:
Бизнес-требования
- Содержание: определение потребностей бизнеса, которые должна решить система.
- Назначение: формализация ожиданий бизнес-стейкхолдеров от системы.
Требования к системным интерфейсам
- Содержание: описание взаимодействия разрабатываемой системы с другими системами.
- Назначение: учет и документирование способов и параметров интеграции между системами.
Требования к данным
- Содержание: описание структуры данных, их хранения, обработки и передачи.
- Назначение: обеспечение корректной работы с данными в системе.
Документ ограничений системы
- Содержание: описание ограничений на программное и аппаратное обеспечение.
- Назначение: учет ограничений при разработке системы.
Критерии приемки
- Содержание: условия и критерии, при которых продукт считается соответствующим требованиям.
- Назначение: определение того, что система готова к внедрению и эксплуатации.
Дорожная карта продукта
- Содержание: план развития продукта на определенный период времени.
- Назначение: визуализация плана разработки и предоставление перспективы развития для стейкхолдеров.
Отчеты о трассировке требований
- Содержание: таблица, отображающая связь между требованиями и элементами продукта (кодом, тестами и т. д.).
- Назначение: обеспечение отслеживания реализации требований на протяжении всего жизненного цикла продукта.
Заключение
Таким образом, перед специалистами и командами по разработке ПО часто стоит задача не только выбрать наиболее подходящий набор документов для текущего проекта, но и адаптировать их содержание, формат и структуру, чтобы они соответствовали реальным потребностям и условиям работы. Эта задача требует гибкости, знаний и опыта, чтобы обеспечивать качественное и эффективное проектирование и разработку программного продукта.
Понимание различных видов документации и их правильное применение позволяет обеспечить качественное взаимодействие команды на всех этапах проекта. Такая документация становится неотъемлемой частью успешного проекта и ключом к созданию продукта, соответствующего ожиданиям и требованиям.
Понравилась статья?
Ставьте «палец вверх» и подписывайтесь на канал, если статья оказалась полезной.
Больше интересных тем — на нашем ✈️ Telegram-канале.
