Технология CRUD-матрицы. Практический опыт

    Пример дублирования функционала
    Технология CRUD-матрицы — это хороший инструмент для каждого члена Agile-команды на протяжении всего жизненного цикла продукта. CRUD-матрица позволяет наладить адекватный диалог с клиентом и выявить дублирование функционала, а также устранить противоречивость модели. Что касается оценки времени, то в этом моменте CRUD-матрица значительно уступает такому инструменту, как “planning poker”, который позволяет провести адекватную оценку с учетом объективных причин.


    Немного теории: описание методики


    IIBA в компетенцию бизнес-аналитика в области Agile (далее Agile-аналитик) относит следующие технологии:
    — Определение критериев оценки и приёмки;
    — Мозговой штурм;
    — Различные методы оценки (метод Delphi, параметрический метод, метод аналогий, трёхточечный метод и т.п.);
    — Прототипирование;
    — Разработка сценариев и описание прецедентов;
    — Моделирование областей для анализа или поставки решений;
    — Пользовательские истории.

    IIBA не относит технологию моделирования данных к компетенции Agile-аналитика, а относит её к компетенции роли бизнес-архитектора. В то же время, в компетенцию бизнес-архитектора, также как и Agile-аналитика отнесена технология моделирования областей для анализа или поставки решений.
    В результате того, что моделированием данных в основном занимается бизнес-архитектор, то Agile-аналитик не видит актуальной взаимосвязи между процессами и данными в системе, что может порождать создание противоречивых сущностей или дублирование функционала в системе.
    Для решения этой проблемы Agile-аналитиком разрабатывается матрица, которая называется CRUD.

    Практическая часть: разработка CRUD-матрицы


    Разработка CRUD-матрицы помогает Agile-команде сконцентрироваться на существенных прецедентах, описывающих бизнес-процесс. CRUD-матрица формируется в виде таблицы, в которой в верхней части перечисляются все классы из диаграммы классов, а в левой части отражается список прецедентов. Задача Agile-аналитика заполнить пересечения между прецедентами и классами следующими комбинациями доступа к экземплярам классов: создание (Create), чтение (Read), обновление (Update) или удаление (Delete).
    Таким образом описываются все прецеденты, которые выполняют создание, чтение, обновление или удаление одного или нескольких экземпляров класса.
    В качестве примера приведу опыт построение CRUD-матрицы в 2007-2008гг. при планировании разработки автоматизированной библиотечной информационной системы для научно-технической библиотеки (далее АБИС НТБ).


    Анализ CRUD-матрицы производится в семь шагов:
    1.Проверка полноты построения модели
    2.Определение зависимостей
    3.Определение пакета типовых работ для разработки
    4.Оценка времени, необходимого для разработки
    5.Проверка модели на непротиворечивость
    6.Определение последующей работы и дополнений функционала
    7.Определение приоритетов для разработки и поставки

    Шаг 1. Проверка полноты построения модели

    На основе CRUD-матрицы проверяется полнота построения модели на предмет целесообразности использования классов или прецедентов в разрабатываемой системе.
    К примеру, в рамках перечисленных прецедентов не описано создание или удаление класса “Книжный формуляр”. Данный факт может конечно говорить о том, что “Книжный формуляр” создается и удаляется вне разрабатываемой системы или же о том, что Agile-аналитик не описал прецедент “регистрация книги” или “списание книги”, а для этого нужно ввести еще один класс “инвентарная книга”.

    Шаг 2. Определение зависимостей

    При планировании процесса разработки системы CRUD-матрица помогает определить перечень классов, которые разрабатываются в первую очередь, чтобы покрыть максимальное количество прецедентов. Например, для разработки АБИС НТБ прецедент “регистрация читателя” будет реализован первым, потому что класс читатель согласно CRUD-матрицы используется в 8 прецедентах, в отличие от класса “бронь”. Таким образом определяются нужные и актуальные данные.

    Шаг 3. Определение пакета типовых работ для разработки

    CRUD-матрица помогает определить типовую реализацию и выявить дублирование функционала в системе. К примеру, класс “книжный формуляр” реализуется по типу класса “библиотекарь” и соответственно времени на реализацию класса “книжный формуляр” потребуется меньше. Таким образом, сокращается время разработки системы.

    Шаг 4. Оценка времени, необходимого для разработки

    CRUD-матрица предоставляет Agile-команде простой механизм для оценки времени, необходимого для разработки и тестирования определенной части функциональности.
    В первом приближении производится оценка каждой комбинации доступа, а затем производится оценка каждого прецедента. К примеру, создание нового экземпляра класса требуется в 4 прецедентах, чтение информации об экземпляре класса в 7 случаях, в 16 случаях требуется обновлять информацию экземпляра класса, а в 6 случаях необходимо удалять экземпляр класса. Используя плановое время на разработку каждой комбинации доступа формируется таблица сложности реализации каждого класса, а также системы в целом:

    В случае необходимости, аналитик может ранжировать не только сложность реализации каждого класса, но и каждого прецедента.
    Что касается 53 дней, то этот срок уменьшается за счет типовых работ, а именно реализации классов “библиотекарь” и “книжный формуляр”. Для обеспечения более реалистичной оценки на будущее можно использовать фактические значения собранные на основе статистического анализа процессов реализации подобного функционала в предыдущих проектах. В любом случае, последнее слово должно быть за Agile-командой, ведь никакая статистика не поможет в разработке системы, а иногда даже мешает Agile-команде корректно оценить свои возможности.

    Шаг 5. Проверка модели на непротиворечивость

    В процессе итеративного развития CRUD-матрицы обеспечивается согласованность между прецедентами и теми моделями, которые являются основой разработки и поставки решений. Например, в рамках модели могут быть классы, которые не используются ни в одном прецеденте, что может являться снижением производительности системы, а следовательно это может напрямую повлиять на удовлетворённость клиента. Таким образом, решение, при разработке которого использовалась технология CRUD-матрицы, будет максимально непротиворечивым, что является хорошей основой для разработки.

    Шаг 6. Определение последующей работы и дополнений функционала

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

    Шаг 7. Определение приоритетов для разработки и поставки

    CRUD-матрица позволяет клиентам адекватно оценить приоритеты в реализации какой-либо функциональности, и не позволит переместить её реализацию на следующую итерацию. Например, прецеденты “выдача читательского билета” и “перерегистрация читателя” не могут быть поставлены полностью до тех пор пока не будут разработаны классы: читатель, читательский билет и библиотекарь.

    Итог


    Технология CRUD-матрицы — это хороший инструмент для каждого члена Agile-команды на протяжении всего жизненного цикла продукта. CRUD-матрица позволяет наладить адекватный диалог с клиентом (заказчиком) и выявить дублирование функционала, а также устранить противоречивость модели. Что касается оценки времени, то в этом моменте CRUD-матрица значительно уступает такому инструменту, как “planning poker”, который позволяет провести адекватную оценку с учетом объективных причин. Что касается комбинаций доступа к экземплярам класса, то тут не обязательно использовать именно CRUD-комбинацию, возможны и другие комбинации, например такие: REST, RESTful, GET-PUT-POST-DELETE и др.

    P.S.: Источники для вдохновения:
    1. James Cadle, Debra Paul and Paul Turner Business Analysis Techniques: 72 Essential Tools for Success, 2010
    2. International Institute of Business Analysis (2009) Business Analysis Body of Knowledge (Version 2.0). International Institute of Business Analysis, Toronto.
    3. International Institute of Business Analysis (2011 )Business Analysis Competency Model (Version 3.0). International Institute of Business Analysis, Toronto.
    4. unrealitymag.com/wp-content/uploads/2009/03/matrix.jpg
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 14

      +2
      Если вся система сводится к CRUD, то эта техника работает. Но лучше в этой ситуации работает access ;)

      Если система не сводится к CRUD, то такую матрицу нарисовать сложно. Есть способы получше. Например так:

      Для каждой функциональности можно посчитать количество «входов и выходов» (входы и выходы это необязательно сущности), потом умножить на коэффициент «сложности» для модуля. Например контроллер в веб-приложении сделать это один коэффициент, а windows-сервис — другой.
      Таким образом можно получать объективные и достаточно точные оценки объема.

        0
        Это называется state machine или «конечный автомат».
          0
          «Это» это что?
            0
            Если я вас правильно понял, то что вы предлагаете называется подходом «конечного автомата». Кроме входов и выходов еще составляется граф возможных состояний системы. Таким образом еще на этапе проектирования можно избавиться от дублирования и неточностей в требованиях. Имея на руках «автомат», гораздо проще оценивать объем работ, потому что задача формализована.
              0
              В том то и дело, что не составляется граф. Потому что внутренняя реализация может меняться довольно сильно, а потоки данных относительно стабильны. Кроме того не каждая задача хорошо описывается автоматом.
        0
        CRUD аналитика для CRUD задач! Да!

        А если задача выглядит так: «на вход поступает набор чисел, на выходе возвращается его разложение на множители или информация о том, что число простое»? С жёсткими требованиями по скорости? Что там наш CRUD-аналитик делать будет? Расписывать табличку «тут нам число вводят, а тут нам числа выводят»?
          0
          В вашем случае можно добавить новую комбинацию доступа: «вычисление», прецедент будет называться: «вычисление простого числа», а классом будет Int.
          0
          1. CRUD-матрицы — это старый инструмент для обеспечения полноты требований

          2. Планировать на матрицах ни чем не лучше, чем планировать на реестре способов применения, функциональных точках, пользовательских историях и т.д.

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

          4. Agile здесь совершенно не при чём.

          5. IIBA здесь совершенно не при чём.
            +1
            1. CRUD-матрицы в сущности похожи на матрицу RAСI, поэтому может и в правду казаться, что это где-то уже было.
            2. Если обратить внимание на таблицу, то я перечислил как раз способы применения или прецеденты или варианты использования или как вы говорите функциональные точки.
            3. Вы рассуждаете как настоящий аналитик, но макет интерфейса должен соотносится с моделью системы, а также с прецедентами, которые отражают функциональность продукта. Все это можно держать в голове, как и делает большинство аналитиков, но этой информацией будете владеть только вы. Если разрабатывается большая система, то в голове все не удержишь.
            4. Не хочу вас расстраивать, но в Business Analysis Competency Model (Version 3.0) описана компетенция Agile BA (стр.53-54).
            5. IIBA есть The Agile Extension to the BABOK® Guide.
              0
              1. CRUD-матрицы упоминаются по крайней мере в книге Карла Вигерса 2003-го года:
              books.google.ru/books?id=WcO3Ca9NuvQC&pg=PT202&lpg=PT202&dq=Wiegers+CRUD&source=bl&ots=d97cAhI5xe&sig=lAERvRdcTBrLIN-aARJkoeZyv-Q&hl=ru&sa=X&ei=1VFAUe3mO4aL4ASPuIHwAQ&ved=0CIQBEOgBMAk
              Это 10 лет назад, если что.

              4-5. ну понятно, что эти старпёры, чтобы продолжать продавать свои МЛМ-услуги впихивают новомодные техники в свои своды, так же как и PMBOK. Только их упоминание ничем вашей статье про МЕТОД не помогает.

              И это при том, что CRUD-матрица — это не новая, не модная и не agile-техника.
                0
                RACI-матрица упоминается Francis T. Hartman «Don't Park Your Brain Outside: A Practical Guide to Improving Shareholder Value with SMART Management», 2000г.
                books.google.ru/books?ei=CGBAUabxFsr34QT4rYDYCw&hl=ru&id=xQNZAAAAYAAJ&dq=inauthor%3A%22Francis+T.+Hartman%22&q=RACI#search_anchor
                В статье я ни разу не сказал, что это новый инструмент, просто его не применяли в Agile, и я попытался показать, что его применение позволит всем членам команды видеть картину целиком, а не кусочками в виде пользовательских историй.
                По крайней мере я попытался решить проблему:
                image
                Проблему, которую подняли в этой теме: habrahabr.ru/post/172073/
                  0
                  При чём тут вообще RACI? Им точно уже лет 30.
                    0
                    При том, что подход идентичный, только в RACI вместо классов, процедур и функций выступают люди, а вместо прецедентов их задачи.
            0
            Хорошая памятка по одной из менее популярных техник анализа требований, которая может оказать дополнительную помощь в мире разработки систем уровня Enteprise.

            На мой взгляд, основная проблема в части применение этого метода в Agile-мире — это то, что пользовательские истории зачастую будут объединять в себе более одной функции акронима CRUD для дружественных классов, что сделает матрицу значительно менее наглядной, а в пределе может привести к ее вырождению в обычные пересечения между функциями и данными без конкретизации методов обработки этих данных. Иметь такую картинку само по себе не плохо, но я предпочитаю прописывать не очевидные зависимости от данных в самих историях.

            Only users with full accounts can post comments. Log in, please.