Моделирование бизнес-процессов / Моделирование бизнес-процессов / ! Функционально-структурный анализ

Чтение диаграмм экспертом/читателем обязательно сопровождается комментированием. КОММЕНТИРОВАНИЕ – запись возникающих проблем возникающих во время чтения диаграммы. Методология IDEF рассматривает комментарии как самостоятельные понятия, не являющиеся частью исходной диаграммы, но накладываемые поверх исходной графики и текста, и имеющие позитивный и конструктивный стиль комментирования, направленный на исправление диаграммы. Для маркировки комментариев используется шрифт красного цвета с тем, чтобы они отличались от самой диаграммы. Для комментариев лучше всего использовать графическую но-тацию IDEF0, что облегчает процесс комментирования и позволяет быстро исправить синтаксис (например, предложить другие метки, направление дуг к другим блокам или рекомендовать другие декомпозиции). Процесс документирования комментариев производится согласно алгоритму:

1. Проверить правильность заполнения полей бланка IDEF: -фамилию автора, название проекта, дату создания и исправления, а также С-номер, чтобы отличить эту диаграмму от других; -контекстный блок, название и номер узла, чтобы определить место диаграммы в модели; -поле статуса, чтобы определить уровень полученной диаграммы; -поместить свои инициалы и дату рецензирования в поле "Читатель";

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

3. Использовать поля "Замечания" для записи комментариев в виде замечаний "с кружком". Порядок выполнения замечаний: -жирно перечеркнуть очередной номер замечаний. Присвоение замечаниям номера означает соответствие каждому из них уникального идентификатора; -записать этот номер и обвести его кружком. Помещение номера в кружок позволяет отличить замечания читателя от замечаний автора, которые тоже могут быть на этой странице; -около обведенного номера записать содержание замечания. В IDEF используются замечания "с кружком" и "с квадратом". Замечания "с кружком" записываются на диаграмме авторами и читателями во время цикла автор/читатель. Поэтому они могут быть как красными, так и синими. Замечания "с квадратом" вводятся в исходную диаграмму автором обычно для того, чтобы что-то подчеркнуть на ней. Поэтому замечания "с квадратом" являются неотъемлемой частью диаграммы. Они всегда пишутся черным цветом и редко встречаются в модели. - при необходимости соединить зигзагом свое замечание с соответствующей частью диаграммы. Соединение зигзагом замечания с соответствующей частью диаграммы, позволяет точно указать, к чему они относятся.

4. Упростить замечания с помощью языка ссылок IDEF0. Если избыток замечаний затрудняет чтение диаграммы и понимание ее смысла, то язык ссылок помогает идентифицировать конкретный блок, дугу или замечание. Код ссылки составляется из номера узла диаграммы или буквенного обозначения страницы папки и ICOM-кода или номера замечаний. ICOM-коды используются для ссылок на определенные дуги конкретного блока. Язык ссылок полезен также при написании текста к диаграмме.

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

РЕАГИРОВАНИЕ - процесс разработки автором ответов на комментарии читателей, записывая рядом с каждым из них свой ответ синим цветом, после получения от отрецензированной IDEF-папки. В IDEF ответы автора не являются частью диаграммы, а рассматриваются как самостоятельные понятия, отличные как от диаграммы, так и от замечаний эксперта. Ответы автора как бы накладываются на откомментированную диаграмму. В IDEF0 используется для ответов синий цвет, чтобы они отличались как от самой диаграммы, так и от читательских замечаний. Авторы должны быть внимательны к мнению каждого читателя, и реагировать на замеча-ния, приводя при необходимости объяснения и обоснования. При записи ответов или дополнительных замечаний необходимо помнить о том, что каждый читатель смотрит на работу со своей точки зрения. Алгоритм изучения автором комментариев эксперта:

1. Изучить каждое замечание читателя и ответить на него.

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

3. Для получения оценки трудности процесса комментирования папки определить, сколько времени затратил читатель на ее рецензирование.

4. На титульном листе отметить продолжительность своей работы.

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

6. Сделать выводы – при согласии ставиться галочка, если несогласие – крестик.

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

8. В случае возникновения серьезных разногласий или существенных взаимных непониманий, принять решение о необходимости диалога автор/читатель для обсуждения основных вопросов.

9. Возникшие проблемы записываются на титульном листе в форме замечания, которое со-провождается словами «ДАВАЙТЕ ПОБЕСЕДУЕМ». написанными заглавными буквами.

10. До начала диалога подготовить список вопросов, которые следует обсудить в ходе беседы автор/читатель.

11. Провести встречу и последовательно рассмотреть все вопросы один за другим. Во время встречи необходимо придерживаться запланированной тематики и время обсуждения (обычно один час). Если во время диалога появятся вопросы, требующие дополнительного обдумывания, то возникшие новые проблемы должны быть записаны для обсуждения во время следующего диалога.

12. Выработанное решение каждой проблемы записывается в папке в виде замечания "с кружком".

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

14. Каждое согласованное замечание приводит к изменениям в исходной диаграмме, которые должны документироваться с помощью замечания "с кружком" на авторском экземпляре папки. При подаче экспертами взаимно исключающих замечаний, автор должен выбрать то из них, которое больше согласуется с целью и точкой зрения модели. Если это вызывает затруднения, то автор должен провести беседу автор/ читатель с обоими читателями одновременно для разрешения противоречия. Окончательное решение, которое, как правило, является компромиссом, записывается в авторском экземпляре папки.

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

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

17. При серьезных изменениях рекомендуется начертить диаграмму заново. При перечерчивании необходимо отметить заменяемую диаграмму, указав ее С-номер в скобках сразу же после С-номера новой диаграммы. Таким образом с помощью набора указателей, направленных назад, метод IDEF связывает между собой различные версии одной и той же диаграммы, чтобы всегда можно было проследить изменения в ходе аналитического проекта.

18. По выполнении корректировки диаграммы требуется подготовить новую папку, содержащую переделанную диаграмму для повторного рецензирования.

Для построения системы должны использоваться модели, созданные по заказу пользователей и одобренные ими, в ином случае использованные для построения модели будут неверными или их будет не хватать, а формат отчетов не будет удовлетворять информационные потребности. Адекватное описание системы, может быть разработано только на основе информации, полученной от будущих пользователей этой системы. Входящий в цикл автор/читатель формализованный набор процедур дает возможность разрешить любую ситуацию, которая может возникнуть в ходе одновременного рецензирования материала несколькими экспертами. Формализованным набор называется потому, что он предписывает правила координации работы многих людей для достижения ими консенсуса. Эти процедуры легко модифицируются, поэтому с их помощью в любом проекте можно осуществить рецензирование, не смотря на то, что каждый проект предъявляет свои требования к полноте и формализованности этого процесса. Следует отметить, что не необходимости в использовании цикла автор/читатель в полном объеме в каждом проекте по системному анализу. Необходимо всегда учитывать, в какой степени этот процесс соответствует авторам, читательской аудитории, величине и сложности системы, цели аналитического проекта. Сбор информации начинается в момент определения требований, т.е. на первом этапе создания системы, однако потребуется несколько итераций, прежде чем исходные идеи приведут к результату, удовлетворяющему пользователей. Цикл автор/читатель выделяется, как отдельный этап в создании модели системы:

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

• облегчает асинхронное и альтернативное рецензирование работы нескольких аналитиков

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

В цикле автор/читатель принимают участие специалисты с разными обязанностями:

• авторы создают модели

• читатели читают и комментируют работу авторов

• Комитет технического контроля утверждает результаты

• библиотекарь организует хранение и распространение материалов.

Этапы цикла автор/читатель. Составление исходной документации. Создания модели является деятельностью, связанной как с получением знаний, так и с их представлением. Знания получают при чтении сответствующих документов, опросе экспертов, наблюдением за функционированием реальной системы или придумывая сценарии. Документирование (фиксация) знаний с помощью графического языка IDEF и с добавлением текстовых записей является базой для построения IDEF-диаграмм и моделей. Аналитик должен документально зафиксировать свое понимание системы путем создания нескольких IDEF-диаграмм, в совокупности составляющих модель, являю-щейся в свою очередь, составной частью взаимосвязанных моделей. В определенный момент автор составляет из своих рабочих материалов папку, которая является основной единицей хранения и обработки рецензируемого материала (диаграммы и модели). Автор записывает в соответствующие поля титульного листа папки список адресатов, дату возврата и другую необходимую информацию. Папка посылается библиотекарю. Комментирование работы. Библиотекарь полученные папки регистрирует и копирует, одну из копий помещает в архив моделей проекта, остальные копии распространяет среди участников проекта, в соответствии со списком адресатов на титульном листе папки, и одну из копий библиотекарь посылает автору. Библиотекарем записываются дата рассылки папки и срок ответа автору, что позволяет ему контролировать документооборот - знать, кто и когда получил папку, а также дату ее возврата. В обязанности библиотекаря входит библиотекарь напоминание опаздывающим читателям о необходимости вернуть задержанные папки, что обеспечивает своевременную обратную связь между аналитиком и экспертами. Папки с комментариями, полученные библиотекарем, опять регистрируются и немедленно отсылаются автору. Чтение материалов. После получения папки от библиотекаря читатель должен не просто изучить включенные в нее материал, а обязательно записать все свои комментарии. При появлении вопроса вопрос или предложение, эксперт записывает его красным цветом в форме замечания. С этих записей начинается письменный диалог между читателем и автором, в ходе которого немедленно фиксируются все сомнения читателя. Немедленная запись замечаний является гарантией, что ни одна идея, возникшая в ходе проектирования, не пропадет. Детали беседы часто забываются, а к диалогу в письменной форме всегда можно обратиться при решении проблем или повторном просмотре материалов. Читатель согласился помочь автору, сделав соответствующую пометку на титульном листе, помес-тив комментарии на диаграмме, проставив дату комментирования и указав срок ответа для ав-тора. После внесения всех необходимых замечаний и комментариев читатель обязан вернуть папку библиотекарю. Ответы на комментарии. Автор просматривает папки с комментариями и пишет ответы на них. Папки с ответами передаются библиотекарю для регистрации и возврата читателям. После этого каждый экземпляр папки остается у своего владельца и библиотекарь никогда больше не обрабатывает их. Просматривая папку с комментариями, автор синим цветом пишет ответ рядом с каждым замечанием. По ходу чтения автор может добавить еще какую-либо информацию для пояснения своих ответов или для указания на свое намерение переделать диаграмму в соответствии с рецензией. Комментарии всех читателей объединяются аналитиком в своем авторском экземпляре папки для дальнейшего анализа и обобщения различных и, возможно, противоречивых мнений экспертов. На основании обобщенного мнения экспертов и аналитика создается улучшенная версия разрабатываемой модели, которые также поступают к библиотекарю, для их помещения в архивы модели. После этого данный цикл рецензирования считается завершенным, и автор может начинать новый цикл на основе переработанного материала. Совершенствование моделей. После нескольких циклов автор/читатель участники проекта обычно начинает приходить к консенсусу относительно содержания конкретной модели - появляется общее понимание того, как работает или должна работать данная система. Степень понимание диаграмм характеризуется стандартными ключевыми выражениями. Значения терминов: "рабочая версия", "эскиз", "рекомендовано", "публикация", составляющих каркас IDEF-диаграммы, определяются на начальной стадии проектирования, что дает возможность для каждого аналитического проекта вырабатывать свои критерии документального контроля за уровнем достижения консенсуса. Например, термин "рабочая версия" может относиться к первому, черновому варианту диаграммы, "эскиз" может относиться к следующим ее версиям, которые нуждаются в уточнениях, "рекомендовано" может означать, что диаграмма готова для окончательного утверждения, а "публикация что диаграмма окончательно утверждена. Автор делает на диаграммах пометки, соответствующие степени их принятия читателями, а затем посылает диаграммы библиотекарю, который вносит изменения в архивной модели. Если набор диаграмм, представляющий собой хорошо проработанную часть модели, достиг уровня "рекомендовано", он отправляется на окончательное утверждение в Комитет технического контроля. Комитет технического контроля представляет письменно свои замечания, автор отвечает на них и переделывает диаграммы в соответствии с замечаниями Комитета технического контроля, а библиотекарь обеспечивает своевременность рецензирования, рассылая напоминания. Когда Комитет технического контроля сочтет, что данный набор диаграмм мож-но утвердить, решение об утверждении поступает к библиотекарю, который сообщает о нем автору. Утвержденные диаграммы печатаются и распространяются как среди участников проекта, так и среди других специалистов. Утвержденные модели печатаются также в виде документов для использования на более поздних стадиях проекта.

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

Управление проектом «Моделирование информационной системы» представляет процесс, в ходе которого координируется работа авторов, экспертов и тех, кто принимает окончательную версию модели системы или ее части. Процесс моделирования иллюстрируется. Диаграмма отражает тот факт, что этот процесс - итеративная процедура, приводящая к точному описанию системы.

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

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

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

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

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

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

• разработка проектов для хорошо известных или несложных систем может сопровождаться папками больших размеров;

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

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

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

1. Папка посылается самому опытному эксперту, с целью получения его согласия с автором диаграммы.

2. Вторая папка с тем же содержанием отправляется группе экспертам, с целью получения их согласия.

3. Скорректированная папка отправляется всей читательской аудитории, чтобы получить общее одобрение работы.

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

Создание модели

Создание эффективных моделей требует:

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

• назначение авторов для декомпозиции конкретных блоков диаграммы АО. Группа аналити-ков определяет цели декомпозиции каждого блока диаграммы АО и назначает для каждого блока по одному автору. Автор детализирует свою часть модели и согласовывает интер-фейсы на диаграмме АО с другими авторами. Такая организация авторского коллектива по-зволяет организовать быструю разработку модели работу в режиме параллельного проек-тирования;

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

• доработку модели.

Дополнение модели

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

• описания функций с точки зрения пользователей. Функции системы, с которыми имеет дело пользователь определяются IDEF-моделью, поэтому автор должен выделить в модели эти функции, связать их с вопросами, относящимися к человеческому фактору;

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

• критерии приемлемости (т.е. независимые испытатели, тесты, место и длительность тестирования) должны быть организованы вокруг структуры IDEF-модели, если нельзя придумать лучшей организации. Для документирования этой информации используются исполнители;

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