Моделирование требований
«Пойду» по порядку: что такое эта модель данных в общем и в контексте ИТ-системы? Как следует из этого словосочетания, это данные, которые замоделированы для определенной системы. На данных строится абсолютно любая сущность в нашем мире. Любые данные состоят всего из трёх типов сущностей: это объекты, их свойства и связи (типы связей) между объектами. Возьмем простейшую модель данных – обычная книга. В модель данных входят объекты (я пишу вот прямо сейчас и генерирую мысли-примеры из головы): лист книги, сама книга, обложка, клей для склейки обложки и листов, краска для нанесения текста, сам текст. У объектов есть свойства, берем, например, обложку и ее свойства: это – тип материала, цвет, толщина/жесткость, вес. И обязательно между объектами одной системы должны быть связи (типы связей) – текст обязательно связан с листом и обложкой и не может существовать без них. Этот тип связи простым языком называется «отец-ребенок», так как текст/ребенок не может существовать сам по себе как часть книги без листа или обложки/отца. Вот такая модель данных книги у нас получилась. Формат, в котором я это описал, также называется объектно-ориентированным моделированием (которое логично перетекает в объектно-ориентированное программирование).
Почему наличие или создание модели данных важно при подготовке такой вещи, как книга или любой системы? На примере книги я бы построил такую логическую цепочку, и всё выглядит довольно прозрачно:
1.Цель создания почти любой сущности в нашем мире – это её использование человеком.
2.Использование человеком означает использование функций предмета или системы.
3.Функции предмета или системы – это как раз та функциональность, которую мы также опишем для системы или для книги. Для книги главная функция – это «читать книгу».
4.Но чтобы читать что-то, нужно иметь этот предмет или систему физически, то есть должно быть описание и модель того, как будет выглядеть книга и из каких объектов она будет состоять.
5.К тому же, все части книги должны иметь правильные свойства. Представьте, если из нашего примера мы укажем свойство «вес» для объекта обложки равное 30 кг? Вряд ли такую книгу будет возможно читать!
6.Также все объекты должны быть связаны между собой правильными связями. Мы ведь не хотим, чтобы страницы были склеены между собой, а текст указан только на обложке, а не на листах книги.
Из этого примера, я думаю, становится видно, что невозможно планировать детальное описание функций чего-либо без создания модели данных. От модели данных зависит корректность создания функционального дизайна, дизайна пользовательского интерфейса, разработки кода и возможностей системы для конечного пользователя. От согласованности и логичности созданной модели данных в дальнейшем будет зависеть расширяемость системы и её адаптивность к изменениям. Именно с помощью создания модели данных можно корректно оценить интеграционные возможности между разными системами, ведь в любой интеграции основную роль играет правильная синхронизация информации между двумя системами. Информация равна данным.
Какие инструменты я использовал для создания модели данных? Я использовал профессиональную программу для моделирования/проектирования, Архитектор Корпорации (EA = Enterprise Architect), для создания модели. В настоящее время доступно множество более простых программ, о которых я расскажу позже. В EA я создавал всю модель, а затем экспортировал её в обычный документ Word, который можно было переслать кому нужно – БА, разработчикам или клиенту для ознакомления. Также функциональность EA позволяет автоматически генерировать этот документ, который является частью дизайна системы. Что интересно, EA позволяет выгружать созданную модель непосредственно в код, создавая необходимые объекты, связи и их свойства прямо в нужном месте в кодовой базе у разработчиков.
Вот как выглядел процесс создания модели в общих чертах: я пересмотрел функциональные требования и начал проектирование объектов адресной системы. Естественно, основным объектом был «адрес». От этого объекта, например, наследовались такие объекты, как «адрес офиса» и «юридический/биллинговый адрес». «Наследовались» здесь означает тип связи между объектами, при которой нижестоящий объект наследует все свойства вышестоящего объекта и дополняется своими уникальными свойствами.
Если объект «адрес» включал атрибуты, такие как «улица» и «номер дома», то я предполагал, что «адрес офиса» также будет иметь эти атрибуты. Для атрибутов я также определял свойства, например, тип атрибута (число, текст или список значений) и его обязательность для заполнения, то есть он не мог быть пустым.
В процессе проектирования модели я сверялся с требованиями и делал пометки в черновом функциональном дизайне. Например, если я описал заполнение какого-то поля как текстовое, а при создании модели понял, что это будет список значений. В итоге у меня был готов документ по модели данных, который я также отправил на проверку своему БА, как и функциональный дизайн, созданный на основе этой модели.
Дизайн модели данных я также проверял на логические связи с матрицей требований. Этот артефакт был так же важен для подписания с клиентом, как и функциональный дизайн: все необходимые функции должны быть указаны, а также все необходимые объекты, их связи и свойства. Некоторые изменения в модели могли быть очень дорогими и значительно сложнее, чем изменение какой-либо функции системы. В своей дальнейшей работе, особенно при создании систем с нуля, я почти всегда создаю модель данных – и даже если модель данных не является официально требуемым артефактом, я создаю её для себя, чтобы быть на сто процентов уверенным, что я ничего не упустил.
И в заключение темы модели данных хочу поделиться примером простейшей модели по системе «книга», которая, например, могла бы пригодится при создании системы по управлению публикацией книг.
Примечание автора: названия в диаграмме даны на английском языке. Перевод: Book – книга ; Weight – вес ; Size – размер; Carton type – тип картона; Cover – обложка; Picture – изображение; Title – заголовок; Subtitle – подзаголовок; Pages – страницы ; Number of page -номер страницы.
Это только короткий пример, который визуализирует то, о чем я рассказывал несколько страниц назад. Я показал три основных объекта: книгу, обложку и страницу. Книга связана с объектами обложка и страница связью "родитель-ребенок", что означает, что эти нижележащие элементы всегда будут созданы именно под "родителем". Также объекты содержат базовые атрибуты, такие как вес или размер книги, и название обложки.
Вот так я и закончу описание первых двух шагов своего становления как БА. Да, было много разноплановых активностей, но как я всегда рекомендую и ожидаю от БА, самая главная и всегда востребованная черта любого начинающего БА – это его способность писать высококачественные требования и дизайны к ним. Именно эти артефакты прямолинейно связаны с нуждами команды разработчиков и от них зависит успех создаваемой системы. За прошедшие около 6 месяцев, что я проработал впервые в жизни как БА, я получил опыт и освоил навыки написания требований и дизайна к ним, создания модели данных, подготовки структуры требований, базовых навыков выявления требований, основ отслеживаемости и подходов к утверждению требований, основ методологии и жизненного цикла разработки, а также важные мягкие навыки, такие как командная работа, управление временем и вопросник.