Гибкое управление требованиями, часть 3. Модель данных для совместной работы

В этой статье я хочу изучить, как интегрировать требования к данным с функциями продукта и пользовательскими историями; результатом является некоторая очень полезная прослеживаемость того, где конкретный объект данных или атрибут используется в продукте.

Концептуальная модель данных является неотъемлемой частью процесса анализа, она позволяет аналитику лучше понять общее требование и то, как различные элементы связаны друг с другом. Это позволяет определить правильные функции для поддержки требования и может выявить некоторые пробелы в требовании, где данные не готовятся к сбору и использованию в следующем процессе.

Затем модель данных, естественно, послужит отправной точкой для проектирования базы данных и гарантирует, что все функции и связанные с ними пользовательские истории будут воспроизведены с одного и того же листа гимнов. Спринтерские команды выиграют от общего понимания данных, которыми им поручено управлять.

Первоначально я думал, что нужен настоящий инструмент моделирования данных со встроенным словарем, поскольку я использовал такие инструменты в предыдущих проектах.

Поскольку выбор инструмента был ограничен, мы исследовали, может ли Confluence стать полезным решением; мы уже использовали Confluence для управления требованиями и пользовательскими историями, так что это выглядело как естественный плагин к нашей существующей вики Confluence.

Для удобства было настроено отдельное пространство моделирования данных для хранения всех диаграмм и содержимого страниц для модели данных, на которые затем можно было ссылаться на страницах Wiki, чтобы лучше понять требования.

Используемый нами сервис Confluence поставлялся с инструментом построения диаграмм Gliffy; это позволило нам создать диаграммы отношений сущностей (модели классов). Поскольку модель была довольно большой, она была разделена на отдельные домены данных, этим легко управлять, создавая представление (диаграмму) для каждого домена.

Чтобы сделать модель данных Confluence более похожей на настоящую модель, основанную на инструментах, в диаграммы, прикрепленные к объектам рисования, таким как объект или домен, были включены гиперссылки; щелкните домен высокого уровня в представлении схемы, и прикрепленный URL-адрес затем запустит связанную диаграмму представления домена, что позволит перейти к подробному уровню сущности.

Опустившись на уровень сущности, следующим шагом будет настройка каждой сущности как отдельной страницы Confluence; последний щелчок на уровне объекта приведет к переходу на страницу, которую можно дополнить контентом для совместной работы с командой.

Каждый объект данных загружается как отдельная страница Confluence; этот подход также означает, что вы можете ссылаться на отдельные функции и пользовательские истории, используя URL-адрес страницы, но также предоставляет готовую папку для хранения соответствующего контента, такого как атрибуты данных.

Реклама

Совет — настройте домены данных

Настройте иерархию доменов в Confluence для надлежащего хранения объектов, это облегчит создание представлений подмножеств модели с использованием параметра фильтра предков в макросе отчетов.

Теперь у нас есть модель, доступная в Confluence с каждой сущностью, загруженной как отдельная страница, требования к данным могут быть интегрированы в вики требований, отслежены до функций продукта и включены в пользовательские истории в виде URL-ссылок на соответствующие страницы.

Совет — определите использование данных

Чем более всеобъемлющим будет применение этого подхода, тем большая ценность будет реализована; если вы перейдете к страницам атрибутов, то можно будет перейти к тому, где обрабатываются элементы данных.

Определение атрибутов данных является полезным действием, позволяющим гарантировать, что система будет включать все необходимые данные и управлять ими согласованным образом.

Атрибуты данных могут быть простыми и не требующими пояснений элементами, одного названия может быть достаточно, чтобы понять предназначение; однако часто бывает так, что значение может быть очень тонким, и наличие страницы атрибутов, доступной для записи объяснения, очень полезно.

Атрибуты данных настраиваются как дочерние страницы для родительской страницы объекта данных, чтобы обеспечить естественный план хранения, но на них можно ссылаться где угодно и делиться ими в беседах с членами команды, чтобы прояснить их цель и обеспечить согласованное использование данных.

Совет — имена атрибутов

Имена страниц должны быть уникальными в пространстве Confluence, поэтому рекомендуется полностью уточнять имя страницы с именем объекта в качестве префикса, чтобы избежать проблем с дублированием в разных объектах.

Именно здесь модель данных становится интегрированной и совместной, что является большим преимуществом по сравнению с отдельными инструментами моделирования.

Всякий раз, когда пользовательская история ссылается на требование к данным, URL-адрес страницы объекта может быть включен в историю как часть повествования. Например, описательная часть «Создайте запись о клиенте для полученного заказа» может заменить обычный текст «клиент» URL-адресом страницы сущности клиента. Как только этот подход будет принят, использование данных может быть легко обнаружено; начиная со страницы объекта под сведениями о странице будут показаны все входящие и исходящие ссылки на страницу, показывающие, где используются данные, и одним щелчком мыши читатель может перейти прямо на страницу истории.

Совет — бизнес-правила

Включение ссылок на атрибуты в бизнес-правила гарантирует, что команды спринта будут искать в нужном месте при реализации пользовательских историй. Например, проверить, не пропущена ли «дата доставки заказа»; в противном случае необходимо активировать оповещение для отслеживания задержки с клиентом.

Confluence может показаться не самым очевидным инструментом для управления требованиями к данным; однако тот факт, что его можно интегрировать с функциями продукта и пользовательскими историями, является весьма мощным. Возможность увидеть, где используются отдельные атрибуты данных, облегчает анализ воздействия и поддержку; бизнес-правила могут быть точно выражены и облегчают разработку интегрированной системы.

Это потребует тщательного управления, чтобы гарантировать, что изменения могут проходить через процесс и могут быть легко идентифицированы, но это верно для всех этих видов инструментов.

И последнее, но не менее важное — это запись отзывов и комментариев, добавленных на страницы в Confluence, объясняющая, почему были приняты определенные решения и как введенные атрибуты данных используются системой. Эта запись будет иметь неоценимое значение для проверки и запросов поддержки, чтобы понять, как и почему часть данных используется системой.

Взгляды: 0