Точку зрения нужно подбирать достаточно аккуратно, основой для выбора должна служить поставленная цель моделирования. Наименованием точки зрения может быть наименование должности, подразделения или роли (например, руководитель отдела или менеджер по продажам). Как и в случае с определением цели моделирования, четкое определение точки зрения необходимо для обеспечения внутренней целостности модели и предотвращения постоянного изменения ее структуры. Может оказаться необходимым построение моделей с разных точек зрения для детального отражения всех особенностей выделенных в системе функциональных блоков.

Границы моделирования

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

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

Чтобы облегчить правильное определение границ моделирования при разработке моделей IDEF0, существенные усилия затрачиваются на разработку и рецензирование контекстной диаграммы IDEF0 (диаграммы "самого верхнего" уровня). Иногда даже прибегают к построению дополнительной диаграммы для отображения уровня, более высокого, чем контекстный, для данной модели, что позволяет обозначить систему, внутри которой располагается объект для моделирования. Существенные затраты на разработку контекстной диаграммы вполне оправданы, поскольку она является своего рода "точкой отсчета" для остальных диаграмм модели и вносимые в нее изменения каскадом отражаются на все лежащие ниже уровни.

Когда границы моделирования понятны, становятся ясными и причины, по которым некоторые объекты системы не вошли в модель.

Выбор наименования контекстного блока

Рекомендуемой последовательностью действий при построении модели "с нуля" являются: формулирование цели моделирования, выбор точки зрения, определение границ моделирования. Наименование контекстного блока – функционального блока самого высокого уровня – обобщает определение границ моделирования.

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

Определение стрелок на контекстной диаграмме

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

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

Определение входов. Входы можно рассматривать как особым образом преобразуемые функциональными блоками для производства выхода сырье или информацию. В производственных отраслях определить, как входное сырье преобразуется в готовую продукцию, обычно довольно просто. Однако при моделировании информационных потоков входной поток данных может представляться не потребляемым и не обрабатываемым вообще. Случаи, когда входящие и исходящие стрелки называются в точности одинаково, крайне редки и в основном указывают на бесполезность данного блока для системы в целом или на некорректный выбор имени для исходящей стрелки. Решением может служить применение более подробного описания для входящих и исходящих потоков данных. Например, вход может иметь название "Предварительный диагноз пациента", а выход – "Уточненный диагноз пациента".

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

Определение управления. Должно быть определено управление, контролирующее ход работы функционального блока. Все функциональные блоки в IDEF0 должны иметь хотя бы одно управление. В случаях, когда не ясно, относить ли стрелку к входу или к управлению, следует ее рисовать как управление. Важно помнить, что управление можно рассматривать как особую форму входа функционального блока.

Когда контекстная диаграмма представляется завершенной, попробуйте задать следующие вопросы:

• Обобщает ли диаграмма моделируемый бизнес-процесс?

• Согласуется ли диаграмма с границами моделирования, точкой зрения и целью моделирования?

• Подходит ли выбранный уровень детализации стрелок для контекстного блока? (Обычно на контекстной диаграмме рекомендуется рисовать не более шести стрелок каждого типа.)

Нумерация блоков и диаграмм

Все функциональные блоки IDEF0 нумеруются. В номерах допускается использование префиксов произвольной длины, но в подавляющем большинстве моделей используется префикс А. Номер блока проставляется за префиксом. Контекстный блок всегда имеет номер АО.

Префикс повторяется для каждого блока модели. Номера используются для отражения уровня декомпозиции, на котором находится блок. Блок АО декомпозируется в блоки А1, А2, A3 и т.д. А1 декомпозируется в A11, A12, А13 и т.д. АН декомпозируется в A111, A112, А113 и т.д. Для каждого уровня декомпозиции в конец номера добавляется одна цифра.

Связь между диаграммой и ее родительским функциональным блоком

Функциональный блок декомпозируется, если необходимо детально описать его работу. При декомпозиции блока полезно рассмотреть его жизненный цикл, это поможет определить функциональные блоки получающейся "детской" диаграммы. Например, жизненный цикл1 блока "Поджарить бифштекс" может выглядеть как следующая последовательность: "Подготовить продукты", "Отбить мясо", "Разогреть масло" и т.д.

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

На концах граничных стрелок (начинающихся или заканчивающихся за пределами диаграммы) детских диаграмм помещаются коды ICOM, чтобы показать, где находится соответствующая стрелка на родительской диаграмме (Рис. 2 .48). Они нужны для проверки целостности модели и могут быть полезны, когда порядок расположения стрелок на детской диаграмме отличается от порядка их расположения на родительской диаграмме. Код ICOM состоит из латинской буквы I, С, О или М и числа, показывающего расположение стрелки на родительской диаграмме в порядке сверху вниз или слева направо.

Рис. 2.48. ICOM-коды на граничных стрелках

Два подхода к началу моделирования ("в ширину" и "в глубину")

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

3.Анализ требований и их формализация

3.1.Методы определения требований

3.1.1.Интервьюирование

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

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

3.1.1.1.Этапы проведения интервью

Процесс проведения интервью состоит из следующих этапов:

• Разработка вопросов (Образец вопросов интервью представлен в таблицу 4.1).

• Выбор опрашиваемых пользователей. Существует несколько групп пользователей: персонал начального уровня, организаторы проекта среднего уровня, менеджеры и другие заказчики особого рода – генеральные директоры и вице-президенты, научные сотрудники, обычные пользователи системы.

• Планирование контактов.

• Непосредственное проведение интервью. Интервью можно провести по телефону, персонально или с помощью Internet (видеоконференция, чат, электронная почта), однако лучшим способом осуществления интервью является непосредственное общение, "лицом к лицу".

• Завершение встречи и определение последующих действий.

Таблица 3.16

Обобщенное практически контекстно-свободное интервью

3.1.2.Мозговой штурм и отбор идей

«Мозговой штурм» – это метод проведения собрания, при котором группа людей пытается найти решение специфической проблемы посредством накопления всех спонтанно возникающих идей.

Данный процесс имеет ряд очевидных преимуществ.

• Поддерживает участие всех присутствующих.

• Позволяет участникам развивать идеи друг друга.

• Ведущий или секретарь ведет запись всего хода обсуждения.

• Его можно применять при различных обстоятельствах.

• Как правило, в результате получаем множество возможных решений для любой поставленной проблемы.

• Метод способствует свободному мышлению, не ограниченному обычными рамками.

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

3.1.2.1.Генерация идей

Мозговой штурм можно производить различными способами. Ниже описывается один из простых процессов. Все основные участники собираются в одной комнате, и им раздаются материалы для заметок. Это может быть просто стопка бумаги и черный толстый маркер. Листы бумаги должны быть не менее 7х12см и не более 12х17см. Каждому участнику нужно выдать не менее 25 листов на каждый сеанс мозгового штурма.

Каждый участник сеанса «мозгового штурма» исполняет одну из трёх ролей: лидер, секретарь, или член команды. Лидер отвечает за направление процесса в правильное русло, за порядок и помогает секретарю делать записи. Секретарь записывает все идеи таким образом, чтобы каждый человек, находящийся в комнате, мог видеть эти записи. Участники генерируют идеи.

Ведущий объясняет правила проведения мозгового штурма (Рис. 3 .49) и определяется цель заседания.

Правила проведения мозгового штурма Не допускается критика или дебаты. Дайте свободу фантазии. Генерируйте как можно больше идей. Переделывайте и комбинируйте идеи.

Рис. 3.49. Правила проведения мозгового штурма

По мере создания идей секретарь просто собирает их и прикрепляет к стене комнаты заседаний. Большинство заседаний по генерации идей длится около часа (иногда 2-3 часа).

3.1.2.2.Отбор идей

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

1. Отсечение. Заключается в отсечении тех идей, которые не достойны внимания. Если обнаруживается две одинаковые идеи, эти идеи объединяются.

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

3. Определение функций. Ведущий перечисляет все оставшиеся идеи, и просит авторов дать их описание, состоящее из одного предложения (Таблица 3 .17).

4. Расстановка приоритетов.