Концептуальное проектирование — процесс проработки верхнеуровневых идей о продукте в структурированный набор документов и артефактов, пригодный для использования в процессе дальнейшей разработки IT-продукта.
В процессе концептуального проектирование формируется подробное описание требований к информационной системе без учета технологической платформы, на которой система будет разрабатываться. Таким образом, результат концептуального проектирования подробно отвечает на вопросы «Что сделать?» и «Как сделать?», без подробностей технической реализации, детализация которой является частью разработки (в рамках технического проектирования).
Когда требуется проектирование
Управление проектом. Структурирование информации о продукте, декомпозиция требований для дальнейшей постановки задач на разработку, выявление и управление рисками.
Управление разработкой. Первичное понимание архитектуры проекта и основа для технического проектирования и дальнейшей разработки продукта.
Зачем нужно проектирование
Ценностью проектирования является как сам процесс, так и полученный в итоге результат. Процесс проектирования позволяет проработать существующие идеи и увидеть новые. Конечный результат позволяет сформировать и согласовать с командой подробное видение продукта и является основой для старта разработки.
Видение продукта. Формирование подробного видения и полноценного понимания продукта у всех заинтересованных лиц.
Выявление и проработка рисков. Концептуальное проектирование позволяет детально проанализировать продукт и внести необходимые коррективы до начала разработки, при минимальной стоимости изменений.
Документирование. Результат проектирования — набор документов, подробно описывающий IT-продукт. В процессе дальнейшей разработки он актуализируется и дополняется описанием технической реализации и тестовой документацией.
Необходимые ресурсы и бюджет. Декомпозированные требований к IT-продукту позволяют заранее определить необходимый состав проектной команды и рассчитать трудозатраты для реализации отдельных функций и проекта в целом.
Основные артефакты проектирования
Модель данных. Полный набор используемых в системе сущностей, справочников, классификаторов и связей между ними с привязкой к функциональным требованиям.
Прототипы UI. Экраны пользовательского интерфейса, с которыми взаимодействуют пользователи при работе с системой.
Бизнес-правила. Бизнес-правила описывают правила, условия и ограничения процедур и процессов, реализуемых в системе с привязкой к требованиям.
Нефункциональные требования. Требования и ограничения, определяющие свойства и характеристики системы.
Интеграционные требования. Требования, определяющие порядок взаимодействия с внешними системами.
Система управления требованиями
Формирование и структурирование требований осуществляется в специализированной системе управлениями требований к ПО. Это инструмент, позволяющий удобно работать со множеством связанных документов, описывающих различные требования к системе. Результат может быть выгружен в виде PDF файла или экспортирован в Atlassian Confluence.
Перечень требований со стороны разработчика концептуальной модели
Для всех требований предусмотрена сквозная классификация по предметным областям. В зависимости от типа требований, предусмотрена дополнительная классификация. Классификация функциональных требований: ➔ Тип функц. требования ➔ Компонент системы (приложение) ➔ Актор (пользователь или внешняя система) Классификация нефункциональных требований: ➔ Тип нефункционального требования ➔ Компонент системы (приложение) Классификация требований к UI: ➔ Компонент системы (приложение) Дополнительно любому требованию в системе может быть прикреплен произвольный лейбл для быстрой выборки требований по лейблу. Каждое требование имеет статус согласования, определяющий текущий процесс работы над требованием и приоритет, определяющий важность требования в контексте проекта.
Описание требований со стороны разработчика концептуальной модели
В зависимости от типа требования, для работы с ним доступен разный набор инструментов.
Для функциональных требований: ➔ Простое текстовое описание (с форматированием и таблицами) ➔ Файлы ➔ Диаграммы (интеграция с diagrams.net) ➔ Перечень критериев приемки и доп. требований ➔ Основной и альтернативные сценарии.
Для требований к данным: ➔ Перечень атрибутов с указанием типа и формированием связей вида один-один / один-много / много-много ➔ Файлы ➔ Для классификаторов указание значений.
Для требования можно указать связи с другими требованиями. Связи требований в дальнейшем могут использоваться для автоматической трассировки требований между собой (например, для выборки требований, зависимых от выбранной сущности или экрана пользовательского интерфейса). Для дальнейшей разработки проекта система предоставляет инструменты для формирования тест-кейсов и артефактов технического проекта, также с трассировкой от требований к тест-кейсам и артефактам.
Требования к данным со стороны разработчика концептуальной модели
Для описания требований к данным в системе должна быть реализована возможность систематизировано описывать атрибуты с указанием типа данных и других параметров. Атрибуты, определяющие связь с другими сущностями позволяют выбрать сущность и тип связи. Для удобства работы со множеством атрибутов должна быть предусмотрена возможность группировки атрибутов. На основе требований должна быть доступна функция визуализации в виде ER-диаграммы.
Визуализация модели данных разработчиком концептуальной модели
На основе описанных требований к данным система автоматически формирует ER-диаграмму. Диаграмма может быть сформирована для всего проекта или в контексте выбранной предметной области или одной сущности.
Документ спецификации требований
Информация, полученная в результате проектирования может быть выгружена в PDF документ, который может быть использован как подробное техническое задание для договора на разработку проекта. Документ содержит всю информацию о требованиях, включая связи требований между собой. В документе используется оглавление для формата PDF для быстрой навигации по документу
Прототип
Прототип пользовательского интерфейса разрабатывается для каждого экрана каждого компонента (приложения), взаимодействующего с пользователем. Прототипы разрабатываются итеративно, начиная с малой детализации. После промежуточного согласования прототип детализируется. Если для одного экрана предусмотрены различные состояния, зависимые от них части интерфейса также дополнительно прототипируются, чтобы иметь полную картину состояний интерфейса. Для разработки прототипов обычно используются Axure RP или аналогичные инструменты.
Процесс
Процесс формирования требований осуществляется итеративно, от меньшей детализации к большей с согласованием промежуточных результатов. Обычно общий срок работ составляет от 4 до 8 недель. Если проект объемный со сложной логикой, может потребоваться больше времени.
