Часть 2: Упрощая реальность

Сущности и их связи
Очень редко удается столкнуться с заказчиком, который четко и ясно может объяснить (а обычно и представить) то, что он хочет от системы. Порой лицо, нанимающее нас в качестве разработчиков средств автоматизации, просто ставит нас перед некой проблемой, которую надо решить с помощью средств автоматизации. В таком случае, нужно все тщательно оценить и выявить подпроблемы (разбить основную проблему на несколько более мелких). Для этого нужно сделать две простые вещи, которые напрашиваются в такой ситуации сами собой:
1) Создать модель текущего состояния системы;
2) Создать модель идеального состояния системы.
Когда у нас будут эти две модели, мы сможет сразу увидеть что именно нам предстоит автоматизировать, да и заказчик сможет более детально рассмотреть текущее положение своей организации (и возможно даже приплатит за дополнительные функции в будущей системе).
Для построения этих моделей я придерживаюсь диаграмм "Сущность-связь". Идея их довольно проста: необходимо выделить основные действия в организации, и связать их по типу черного ящика, т.е. входные данные -> действие о котором известно только его имя -> результат. Для полноты картины помимо входа и выхода, действие дополняется действующими лицами и инструкциями для выполнения действия.
Разберем это на примере. Предположим нам необходимо автоматизировать складской учет. Так же предположим что на склад еженедельно поступают большие партии товаров вместе с накладными, каждую номенклатурную позицию которого необходимо сверить, занести в базу и установить на все цены. Модель этого будет выглядеть примерно так: новый товар->[распаковка и группировка]->группы однородных товаров->[сверка с накладной]->группы товаров по накладной->[внесение в базу]->группы товаров в базе->[переоценка]->группы переоцененных товаров. Здесь в квадратных скобках изображается действие, слева вход, справа результат. Так же можно дополнить эту модель такими элементами: новый товар->грузчики и заведующий складом:[распаковка и группировка]:инструкция по группировке товара при приемке->группы однородных товаров. Здесь слева от действия описаны действующие лица, справа инструкции по работе для них. Такая модель более детальна, так как содержит все необходимые для оценки данные, ее проще анализировать, а значит, проще строить на ее основе системы автоматизации.
Диаграмма "Сущность-связь" содержит следующие компоненты:
1) Действие - прямоугольник с вписанным в него глаголом или отглагольным существительным обозначающим действие;
2) Вход - стрелка, входящая слева в прямоугольник действия с надписью над ней. Используется для изображения входных данных;
3) Результат - стрелка, выходящая справа из прямоугольника действия с надписью над ней. Используется для изображения результатов действия;
4) Действующие лица - стрелка, входящая снизу в прямоугольник действия с надписью рядом с ней. Изображает людей, которые ответственны за выполнение действия;
5) Инструкции - стрелка, входящая сверху в прямоугольник действия с надписью рядом с ней. Изображает документы и инструкции, регламентирующие порядок выполнения действия.
Обычно изображение этой диаграммы начинается с самых общих действий: получение товара, учет товара, отпуск товара, продажа товара. Затем эти действия уточняются через разбиение на поддействия (на новых диаграммах): получение товара(группировка товара, сверка товара, внесение товара в базу и т.д.). Этот процесс уточнения называется декомпозицией модели и позволяет разбивать сложные действия на более простые и понятные.
Декомпозиция это очень важный инструмент. С одной стороны он позволяет на первом этапе посмотреть на задачу поверхностно (иначе можно ужаснуться ее сложности и вложенности), с другой стороны позволяет разделить сложные задачи на ряд более простых, выполнение которых приведет к решению этой сложной задачи. Именно поэтому я советую начинать проектирование с построение этой модели, это позволяет разобраться в задаче. Конечно этот пункт тесно связан с анализом требований (который я в цикле не рассматриваю), но я все же отношу его к проектированию.
После построения подробной модели организации (или любой другой системы) и достаточной декомпозиции ее частей, необходимо показать результаты специалистам, работающим в этой организации, чтобы убедится, что вы правильно смоделировали все и не допустили ошибок (в противном случае вы будете отталкиваться от неверной модели).
После этого вы оцениваете все слабые стороны модели и желания заказчика, и строите идеальную модель, в которой отражается та же организация, но (на ваш взгляд) более правильной структуры. Эта модель будет служить путеводной звездой на протяжении всего процесса проектирования, это ваша цель, то, ради чего все замышлялось (и за что вам платят деньги). Эту идеальную модель обязательно должен одобрить заказчик (иначе попадете в круговорот постоянных переделок готовой системы) и только после этого, можно приступать к дальнейшим пунктам.

Немного из практики
Пока не перешел к другой модели, хотелось бы рассказать о подводных камнях моделирования. Во время анализа системы и построения ее модели (особенно в крупных организациях), обязательно общайтесь с людьми, непосредственно работающие с этой системой! Попросите их рассказать вам о работе, проблемах связанных с системой и об организации в целом (обычно они охотно выльют вам все свои переживания). Дело в том, что заказчик (обычно менеджер высшего звена или директор организации) видит все несколько в ином свете, нежели это есть на самом деле, а непосредственные работники дадут вам более объективную информацию. Конечно если вы не проследуете цель реально автоматизировать систему, а только хотите выполнить заказ и получить деньги, то некоторые дельные советы работников, можно пропустить мимо ушей (иногда иначе никак, часто планы заказчика разнятся с реалиями в организации, а идти против заказчика.. лучше сделать неправильно).
После построения идеальной модели системы, лучше немножко ее поломать (сделать менее идеальной). Дело в том, что некоторые начинающие проектировщики ИС бросаются в задачу с головой и предлагают заказчику настолько идеальную систему, что только в процессе ее реализации понимают - кусают слишком большой кусок! Не надо преувеличивать свои силы, на этапе моделирования можно придумать многое, но не стоит забывать о том, что все это необходимо будет реализовать (так как заказчик никогда не откажется от великолепно спроектированной системы). Смоделируйте систему чуть хуже чем идеально, не подписывайте себе каторжные работы (заказчик все равно вряд ли заметит разницы)!

URL: https://visavi.net/articles/327