Аис1
.pdf3. Согласен ли я с тем, что выразил автор? Вопросы о согласии с автором занимают последнее место, как самые важные. Часто они очень сложны, требуют размышлений и разъяснении.
Вопросы о синтаксисе. Вопросы, связанные с синтаксисом очень важны, потому что хорошее изложение начинается с правильного использования графического языка IDEF. При анализе деталей диаграммы, вначале задаются следующие вопросы:
все ли блоки правильно пронумерованы?
все ли блоки имеют названия в глагольной форме?
все ли дуги на месте?
все ли дуги имеют названия в форме существительного?
все ли метки ясно привязаны к своим дугам?
есть ли на длинных дугах дополнительные метки?
нет ли дуг без меток?
При изучении непосредственного контекста диаграммы, вопросы задаются следующие:
у всех ли внешних дуг есть ICOM-код?
верно ли связывает ICOM-код внешние дуги с граничными дугами родителя?
все ли метки внешних дуг совместимы с метками граничных дуг родителя?
не используется ли помещение дуг в тоннель (скобки рядом с их концами) избыточно или неверно?
Вопросы о понимании диаграммы. Для правильного понимания содержания диаграммы, нужно проследить ход событий, изложенных на ней, последовательно проверяя, как работают блоки, как и почему они влияют друг на друга и почему данные преобразуются указанным образом. Т.о. происходит проверка декомпозиции.
Анализ каждого блока происходит с помощью вопросов:
какова роль этот блока в диаграмме?
как активизируется этот блок?
ясна ли роль каждой дуги?
как данный блок преобразует свои входы в выходы?
ясно ли, как исправить серьезные ошибки?
Чтение внутренних дуг позволяет определить основные пути потока данных, поэтому задаются вопросы:
ясна ли основная линия изложения?
понятны ли побочные потоки данных?
соответствует ли терминология изложению?
При изучении ближайшего контекста диаграммы следует спросить:
как декомпозируют блоки родительский блок?
каковы источники и приемники всех внешних дуг?
ясны ли основные входы, управления и выходы?
Сложная диаграмма затрудняет восприятие, поэтому простота изложения обеспечивает правильное понимание содержания диаграммы. Проверку выполнения соглашений о правильном построении диаграмм можно провести с помощью вопросов:
не слишком ли много (или мало) блоков?
не нужно ли блоки переопределить?
не перегружена ли (или достаточно ли заполнена) часть диаграммы?
не слишком ли много дуг?
не запутаны ли пересечения дуг?
нет ли нескольких дуг с одним и тем же icom-кодом?
не слишком ли длинны или многословны метки?
не слишком ли много жаргона?
соответствует ли терминология точке зрения аудитории, для которой диаграмма предна-значена?
Вопросы о согласии с автором. Для решения вопроса о согласии с автором нужно провести оценку декомпозиции, цели и точки зрения диаграммы, адекватности описания, точности изображения, активизации блоков.
Оценка декомпозиции диаграммы осуществляется при получении ответов на вопросы:
достаточна ли полная декомпозиция?
не отсутствует ли какой-нибудь блок?
нет ли блока, не относящегося к делу?
131
нет ли в декомпозиции каких-либо неожиданностей?
не сделал бы я совершенно другую декомпозицию?
Чтобы определить цель и точку зрения диаграммы, уточнитена какие вопросы отвечает эта диаграмма?
соответствует ли это цели модели?
с чьей точки зрения описана модель?
совпадает ли это с точкой зрения модели?
При определении непротиворечивости диаграммы спрашивают:
не является ли диаграмма слишком запутанной или слишком детальной, чтобы ответить на вопросы, связанные с целью модели?
не отвечает ли диаграмма на вопросы, не относящиеся к цели модели?
используются ли термины в одном и том же смысле?
все ли факты соответствуют точке зрения модели?
При рассмотрении адекватности описания можно спросить:
отражает ли модель реальность?
соответствует ли порядок расположения блоков убыванию их доминантности?
нет ли лишних или отсутствующих дуг между блоками?
Чтобы оценить точность представления, задаются вопросы:
не вводят ли в заблуждение названия блоков и дуг?
содержит ли ветви дуг только те данные, которые действительно нужны блоку?
не перекрываются ли функции двух блоков?
нет ли ненужных дуг, касающихся блока?
Для оценки правильности активизации блоков (т.е. какова возможная последовательность их функционирования в ходе реальной работы системы):
работает ли "нормальный" путь потока данных?
как ошибочные данные будут влиять на блок?
объясняются ли чем-либо ошибочные пути?
не должна ли функция выполнять больше, чем это определяется касающимися ее дугами?
И, наконец, один из самых полезных вопросов: "что нового я узнал, читая диаграмму?" Он ведет к последнему вопросу: "стоило ли читать диаграмму?". При положительном ответе, воз-можно, диаграмму стоит включить в модель.
Комментирование
Чтение диаграмм экспертом/читателем обязательно сопровождается комментированием. КОММЕНТИРОВАНИЕ – запись возникающих проблем возникающих во время чтения диаграммы. Методология IDEF рассматривает комментарии как самостоятельные понятия, не являющиеся частью исходной диаграммы, но накладываемые поверх исходной графики и текста, и имеющие позитивный и конструктивный стиль комментирования, направленный на исправление диаграммы.
Для маркировки комментариев используется шрифт красного цвета с тем, чтобы они отличались от самой диаграммы. Для комментариев лучше всего использовать графическую но-тацию IDEF0, что облегчает процесс комментирования и позволяет быстро исправить синтаксис (например, предложить другие метки, направление дуг к другим блокам или рекомендовать другие декомпозиции).
Процесс документирования комментариев производится согласно алгоритму:
1. Проверить правильность заполнения полей бланка IDEF:
-фамилию автора, название проекта, дату создания и исправления, а также С- номер, чтобы отличить эту диаграмму от других; -контекстный блок, название и номер узла, чтобы определить место диаграммы в модели;
-поле статуса, чтобы определить уровень полученной диаграммы; -поместить свои инициалы и дату рецензирования в поле "Читатель";
2. С помощью простых символов указать согласие (красная галочка) или несогласие (красный крестик) с автором. Эти пометки используются для краткого
132
комментирования конкретной части диаграммы или авторского замечания. Каждая диаграмма и страница дополнительного материала должны быть отмечены, по крайней мере, галочкой или крестом. Эти пометки говорят автору о том, что они были прочитаны и что читатель либо согласен, либо не согласен с изложенным. Однако рекомендуется давать на каждой диаграмме более содержательные комментарии.
3.Использовать поля "Замечания" для записи комментариев в виде замечаний "с
кружком". Порядок выполнения замечаний:
-жирно перечеркнуть очередной номер замечаний. Присвоение замечаниям номера означает соответствие каждому из них уникального идентификатора; -записать этот номер и обвести его кружком. Помещение номера в кружок позволяет
отличить замечания читателя от замечаний автора, которые тоже могут быть на этой странице;
-около обведенного номера записать содержание замечания. В IDEF используются замечания "с кружком" и "с квадратом". Замечания "с кружком" записываются на диаграмме авторами и читателями во время цикла автор/читатель. Поэтому они могут быть как красными, так и синими. Замечания "с квадратом" вводятся в
исходную диаграмму автором обычно для того, чтобы что-то подчеркнуть на ней. Поэтому замечания "с квадратом" являются неотъемлемой частью диаграммы. Они всегда пишутся черным цветом и редко встречаются в модели.
- при необходимости соединить зигзагом свое замечание с соответствующей частью диаграммы. Соединение зигзагом замечания с соответствующей частью диаграммы, позволяет точно указать, к чему они относятся.
4.Упростить замечания с помощью языка ссылок IDEF0. Если избыток замечаний затрудняет чтение диаграммы и понимание ее смысла, то язык ссылок помогает идентифицировать конкретный блок, дугу или замечание. Код ссылки составляется из номера узла диаграммы или буквенного обозначения страницы папки и ICOMкода или номера замечаний. ICOM-коды используются для ссылок на определенные дуги конкретного блока. Язык ссылок полезен также при написании текста к диаграмме.
5.Перед возвращением диаграммы автору прочитать ее еще раз. Повторный просмотр ком-ментариев, позволяет эксперту отметить важные замечания галочкой, зачеркнуть ненужные, уточнить неясные, добавить новые замечания и кратко изложить рецензию на титульном листе.
Если после первого прочтения эксперт не находит ошибок, то он должен отметить все верное. Таким образом можно обнаружить пропуски важных моментов, неуместность отдельных частей диаграммы, неверную точку зрения или неправильно понятую цель.
Ответы на комментарии
РЕАГИРОВАНИЕ - процесс разработки автором ответов на комментарии читателей, записывая рядом с каждым из них свой ответ синим цветом, после получения от отрецензированной IDEF-папки. В IDEF ответы автора не являются частью диаграммы, а рассматриваются как самостоятельные понятия, отличные как от диаграммы, так и от замечаний эксперта. Ответы автора как бы накладываются на откомментированную диаграмму. В IDEF0 используется для ответов синий цвет, чтобы они отличались как от самой диаграммы, так и от читательских замечаний.
Авторы должны быть внимательны к мнению каждого читателя, и реагировать на замечания, приводя при необходимости объяснения и обоснования. При записи ответов или дополнительных замечаний необходимо помнить о том, что каждый читатель смотрит на работу со своей точки зрения.
Алгоритм изучения автором комментариев эксперта:
1.Изучить каждое замечание читателя и ответить на него.
2.Для получения представление о тех частях папки, которые не вызывают сомнения, и
отех, к которым много претензий необходимо бегло просмотреть папку, отмечая замечания и фиксируя их количество.
133
3.Для получения оценки трудности процесса комментирования папки определить, сколько времени затратил читатель на ее рецензирование.
4.На титульном листе отметить продолжительность своей работы.
5.Просмотреть все замечания, стараясь понять, что хотел сказать читатель, затем вернуться назад и ответить на каждое из них.
6.Сделать выводы – при согласии ставиться галочка, если несогласие – крестик.
7.Добавить, если нужно, пояснительный текст около отвергнутого замечания, в котором содержатся пояснения, почему имеется не согласие с его комментарием. Помещение новых замечаний в откомментированную папку допустимо, поэтому при ответе на важный вопрос или изложении новой идеи, возникшей в процессе анализа комментариев, рядом с ним за-писывается синим цветом новое замечание "с кружком" и соединяется зигзагом с комментарием.
8.В случае возникновения серьезных разногласий или существенных взаимных непониманий, принять решение о необходимости диалога автор/читатель для обсуждения основных вопросов.
9.Возникшие проблемы записываются на титульном листе в форме замечания, которое со-провождается словами «ДАВАЙТЕ ПОБЕСЕДУЕМ». написанными заглавными буквами.
10.До начала диалога подготовить список вопросов, которые следует обсудить в ходе беседы автор/читатель.
11.Провести встречу и последовательно рассмотреть все вопросы один за другим. Во время встречи необходимо придерживаться запланированной тематики и время обсуждения (обычно один час). Если во время диалога появятся вопросы, требующие дополнительного обдумывания, то возникшие новые проблемы должны быть записаны для обсуждения во время следующего диалога.
12.Выработанное решение каждой проблемы записывается в папке в виде замечания "с кружком".
13.Обобщить все комментарии на авторской копии папки. Внесение записей в авторский экземпляр папки позволяет отобразить новые качественные изменения в диаграммах в до-полнение к тем, что предлагают читатели. В ходе обобщения комментариев авторам представляется возможность увязать и объединить идеи сразу всех читателей, что часто приво-дит к новым плодотворным идеям, реализация которых ведет к новым качественным изме-нениям исходной диаграммы. Принятое или не принятое замечание читателя отмечается в авторском экземпляре папки. Не рекомендуется вносить изменения в отрецензированную диаграмму до окончания диалога со всеми экспертами.
14.Каждое согласованное замечание приводит к изменениям в исходной диаграмме, которые должны документироваться с помощью замечания "с кружком" на авторском экземпляре папки. При подаче экспертами взаимно исключающих замечаний, автор должен выбрать то из них, которое больше согласуется с целью и точкой зрения модели. Если это вызывает затруднения, то автор должен провести беседу автор/ читатель с обоими читателями одновременно для разрешения противоречия. Окончательное решение, которое, как правило, является компромиссом, записывается в авторском экземпляре папки.
15.Переделать диаграмму и все другие диаграммы, которые были затронуты, в соответствии с набором обобщенных замечаний.
16.Для внесения незначительных изменения, необходимо получить от библиотекаря исходную диаграмму, проставить в служебном поле дату пересмотра, внести необходимые измене-ния и вставить откорректированную диаграмму в новую папку.
17.При серьезных изменениях рекомендуется начертить диаграмму заново. При перечерчивании необходимо отметить заменяемую диаграмму, указав ее С-номер в скобках сразу же после С-номера новой диаграммы. Таким образом с помощью набора указателей, направленных назад, метод IDEF связывает между собой различные версии одной и той же диаграммы, чтобы всегда можно было проследить изменения в ходе аналитического проекта.
18.По выполнении корректировки диаграммы требуется подготовить новую папку, содержащую переделанную диаграмму для повторного рецензирования.
134
Цикл автор/читатель
Для построения системы должны использоваться модели, созданные по заказу пользователей и одобренные ими, в ином случае использованные для построения модели будут неверными или их будет не хватать, а формат отчетов не будет удовлетворять информационные потребности. Адекватное описание системы, может быть разработано только на основе информации, полученной от будущих пользователей этой системы. Входящий в цикл автор/читатель формализованный набор процедур дает возможность разрешить любую ситуацию, которая может возникнуть в ходе одновременного рецензирования материала несколькими экспертами. Формализованным набор называется потому, что он предписывает правила координации работы многих людей для достижения ими консенсуса. Эти процедуры легко модифицируются, поэтому с их помощью в любом проекте можно осуществить рецензирование, не смотря на то, что каждый проект предъявляет свои требования к полноте и формализованности этого процесса.
Следует отметить, что не необходимости в использовании цикла автор/читатель в полном объеме в каждом проекте по системному анализу. Необходимо всегда учитывать, в какой степени этот процесс соответствует авторам, читательской аудитории, величине и сложности системы, цели аналитического проекта.
Сбор информации начинается в момент определения требований, т.е. на первом этапе создания системы, однако потребуется несколько итераций, прежде чем исходные идеи приведут к результату, удовлетворяющему пользователей.
Цикл автор/читатель выделяется, как отдельный этап в создании модели системы:
предполагает индивидуальную работу, поскольку она позволяет выполнять построение моделей и рецензирование их в удобном режиме
облегчает асинхронное и альтернативное рецензирование работы нескольких аналитиков
обеспечивает максимизацию обратных связей одного или более аналитика с конечными пользователями за кратчайшее время и с минимумом усилий, что позволяет получить обратные связи от пользователей, которые заняты своей основной деятельностью, и скоординировать работы нескольких IDEF-авторов по созданию одной или нескольких взаимосвязанных моделей.
Вцикле автор/читатель принимают участие специалисты с разными обязанностями:
авторы создают модели
читатели читают и комментируют работу авторов
Комитет технического контроля утверждает результаты
библиотекарь организует хранение и распространение материалов.
Этапы цикла автор/читатель.
Составление исходной документации. Создания модели является деятельностью, связанной как с получением знаний, так и с их представлением. Знания получают при чтении сответствующих документов, опросе экспертов, наблюдением за функционированием реальной системы или придумывая сценарии. Документирование (фиксация) знаний с помощью графического языка IDEF и с добавлением текстовых записей является базой для построения IDEF-диаграмм и моделей. Аналитик должен документально зафиксировать свое понимание системы путем создания нескольких IDEF-диаграмм, в совокупности составляющих модель, являю-щейся в свою очередь, составной частью взаимосвязанных моделей. В определенный момент автор составляет из своих рабочих материалов папку, которая является основной единицей хранения и обработки рецензируемого материала (диаграммы и модели). Автор записывает в соответствующие поля титульного листа папки список адресатов, дату возврата и другую необходимую информацию. Папка посылается библиотекарю.
Комментирование работы. Библиотекарь полученные папки регистрирует и копирует, одну из копий помещает в архив моделей проекта, остальные копии распространяет среди участников проекта, в соответствии со списком адресатов на титульном листе папки, и одну из копий библиотекарь посылает автору. Библиотекарем записываются дата рассылки папки и срок ответа автору, что позволяет ему контролировать документооборот - знать, кто и когда получил папку, а также дату ее возврата. В обязанности библиотекаря входит библиотекарь напоминание опаздывающим читателям о необходимости вернуть задержанные папки, что обеспечивает своевременную обратную связь между аналитиком и
135
экспертами. Папки с комментариями, полученные библиотекарем, опять регистрируются и немедленно отсылаются автору.
Чтение материалов. После получения папки от библиотекаря читатель должен не просто изучить включенные в нее материал, а обязательно записать все свои комментарии. При появлении вопроса вопрос или предложение, эксперт записывает его красным цветом в форме замечания. С этих записей начинается письменный диалог между читателем и автором, в ходе которого немедленно фиксируются все сомнения читателя. Немедленная запись замечаний является гарантией, что ни одна идея, возникшая в ходе проектирования, не пропадет. Детали беседы часто забываются, а к диалогу в письменной форме всегда можно обратиться при решении проблем или повторном просмотре материалов. Читатель согласился помочь автору, сделав соответствующую пометку на титульном листе, помес-тив комментарии на диаграмме, проставив дату комментирования и указав срок ответа для автора. После внесения всех необходимых замечаний и комментариев читатель обязан вернуть папку библиотекарю.
Ответы на комментарии. Автор просматривает папки с комментариями и пишет ответы на них. Папки с ответами передаются библиотекарю для регистрации и возврата читателям. После этого каждый экземпляр папки остается у своего владельца и библиотекарь никогда больше не обрабатывает их. Просматривая папку с комментариями, автор синим цветом пишет ответ рядом с каждым замечанием. По ходу чтения автор может добавить еще какуюлибо информацию для пояснения своих ответов или для указания на свое намерение переделать диаграмму в соответствии с рецензией.
Комментарии всех читателей объединяются аналитиком в своем авторском экземпляре папки для дальнейшего анализа и обобщения различных и, возможно, противоречивых мнений экспертов. На основании обобщенного мнения экспертов и аналитика создается улучшенная версия разрабатываемой модели, которые также поступают к библиотекарю, для их помещения в архивы модели. После этого данный цикл рецензирования считается завершенным, и автор может начинать новый цикл на основе переработанного материала. Совершенствование моделей. После нескольких циклов автор/читатель участники проекта обычно начинает приходить к консенсусу относительно содержания конкретной модели - появляется общее понимание того, как работает или должна работать данная система. Степень понимание диаграмм характеризуется стандартными ключевыми выражениями. Значения терминов: "рабочая версия", "эскиз", "рекомендовано", "публикация", составляющих каркас IDEF-диаграммы, определяются на начальной стадии проектирования, что дает возможность для каждого аналитического проекта вырабатывать свои критерии документального контроля за уровнем достижения консенсуса. Например, термин "рабочая версия" может относиться к первому, черновому варианту диаграммы, "эскиз" может относиться к следующим ее версиям, которые нуждаются в уточнениях, "рекомендовано" может означать, что диаграмма готова для окончательного утверждения, а "публикация что диаграмма окончательно утверждена.
Автор делает на диаграммах пометки, соответствующие степени их принятия читателями, а затем посылает диаграммы библиотекарю, который вносит изменения в архивной модели. Если набор диаграмм, представляющий собой хорошо проработанную часть модели, достиг уровня "рекомендовано", он отправляется на окончательное утверждение в Комитет технического контроля.
Комитет технического контроля представляет письменно свои замечания, автор отвечает на них и переделывает диаграммы в соответствии с замечаниями Комитета технического контроля, а библиотекарь обеспечивает своевременность рецензирования, рассылая напоминания. Когда Комитет технического контроля сочтет, что данный набор диаграмм мож-но утвердить, решение об утверждении поступает к библиотекарю, который сообщает о нем автору. Утвержденные диаграммы печатаются и распространяются как среди участников проекта, так и среди других специалистов. Утвержденные модели печатаются также в виде документов для использования на более поздних стадиях проекта.
Управление проектом
Управление проектом в методологии IDEF представляет собой процесс, в ходе которого координируется работа экспертов, авторов, читателей и Комитета технического контроля -
136
органа, осуществляющего прием окончательной версии модели системы для использования. Успех проектов зависит от правильного составления папок и методов их рецензирования, от результатов совместной деятельности специалистов и от их индивидуальных усилий.
Управление проектом «Моделирование информационной системы» представляет процесс, в ходе которого координируется работа авторов, экспертов и тех, кто принимает окончательную версию модели системы или ее части.
Процесс моделирования иллюстрируется. Диаграмма отражает тот факт, что этот процесс - итеративная процедура, приводящая к точному описанию системы.
Начало проекта
Разработка проекта должна начинаться с разработки плана проекта, который включает формирование технического задания (ТЗ) на проектирование, исходный выбор создаваемых моделей, организацию группы аналитиков, выбор Комитета технического контроля и
составление графика работ:
техническое задание - это концепция проекта, в котором определяются назначение, сфера, ограничения, ожидаемые результаты и преимущества проекта. ТЗ может также включать набросок плана проекта, который помогает документировать предварительные пре-ложения организаторов и руководителей проекта.. Если проект мал, то он может быть инициирован одним автором, но обычно в разработке ТЗ участвуют небольшие коллективы;
выбор создаваемых моделей и сроки выбора планируются после формирования ТЗ. Это помогает определить наиболее важные объекты, прояснить цели проекта и разработать его детальный план. До определения основных пунктов работы необходимо выяснить, что из-вестно по данной проблеме, какую новую информацию надо собрать, и какие источники ее доступны для проекта. Возможно, необходимо создать несколько небольших IDEF-моделей, чтобы получить эти сведения. Например, мы часто строим модель самого проекта с помощью IDEF, чтобы определить, какие модели будут создаваться (текущие операции, будущие операции, план преобразований, архитектура системы). План, основанный на такой информации, быстрее приведет к созданию точных и полезных моделей;
определение участников проекта. На этом этапе следует определить число экспертов, авторов, читателей, вспомогательный персонал (библиотекарь, делопроизводители и тех-нические оформители), состав Комитета технического контроля. К функциям участников проекта относятся разрешение конфликтов, проведение политики проекта, принятие ре-зультатов, интерпретация и реализация ТЗ.
Создание и рецензирование проекта
Разработка точных и полезных моделей должна сопровождаться постоянным выпуском папок, предназначенных для передачи информации участникам проекта.
Размер папки - это один из аспектов проектирования. Согласно методологии IDEF папки создаются при наличии информация для рецензирования и состоят из контекстной диаграммы, рецензируемой диаграммы и страницы глоссария. Однако объем папок может быть различным в зависимости от опыта участников проекта и от типа самого проекта:
137
разработка проектов, связанных с новыми технологиями, что требует углубленного рецен-зирования каждой новой идеи. В этом случае наблюдается большой объем поступающей информации и более эффективной будет работа аналитиков работают с небольшими папками;
разработка проектов для хорошо известных или несложных систем может сопровождаться папками больших размеров;
в разработке проекта принимают участие начинающие аналитики. В этом случае для обес-печения заданных сроков разработки желательно создавать небольшие папки, т.к. в этом случае легче исправлять ошибки и менять исполнителей;
разработка проектов рецензируемых опытными аналитиками, может сопровождаться
пап-ками, содержащими несколько диаграмм, например диаграмму с ее потомками. Количество папок, рассылаемых в соответствии с конкретным объектом, также является аспектом проектирования. Опыт показывает, что по каждому рецензируемому объему информации лучше производить рассылку не одной, а серии папок. Алгоритм работы с
сериями папок:
1.Папка посылается самому опытному эксперту, с целью получения его согласия с автором диаграммы.
2.Вторая папка с тем же содержанием отправляется группе экспертам, с целью получения их согласия.
3.Скорректированная папка отправляется всей читательской аудитории, чтобы
получить общее одобрение работы.
Такой процесс достижения возрастающих уровней согласия, начиная от одного человека, затем переходя к небольшой группе лиц и далее - ко всем участникам проекта, типичный путь нашего получения знания в IDEF. Он схематически изображен на рис. 1, где показаны также уровни достижения согласия.
Создание и дополнение модели
138
Создание модели
Создание эффективных моделей требует:
использования совместной деятельности специалистов для получения утвержденных диа-грамм А-0 и АО. Обычно работа по моделированию начинается с технического совещания, в котором принимают участие эксперты и разработчики и целью которого является разработка схемы диаграмм АО и А-0, а также уточнение цели и точки зрения модели Начальные диаграммы и связанный с ними глоссарий составляют первую папку, которая проходит несколько циклов автор/читатель, пока не будут созданы стабильные диаграммы АО и А-0;
назначение авторов для декомпозиции конкретных блоков диаграммы АО. Группа аналити-ков определяет цели декомпозиции каждого блока диаграммы АО и назначает для каждого блока по одному автору. Автор детализирует свою часть модели и согласовывает интер-фейсы на диаграмме АО с другими авторами. Такая организация авторского коллектива по-зволяет организовать быструю разработку модели работу в режиме параллельного проек-тирования;
формирования основных задач декомпозиции. Каждый автор детализирует свою
часть модели путем - сбора информации (чтение документов и опрос экспертов);
-ограничением каждого декомпозируемого объекта; -определением точки зрения декомпозиции; -создания диаграммы и ее рецензирования.
доработку модели. Дополнение модели
Описание системы в методологии IDEF позволяет создать модель, которая определяет и описывает функции и объекты системы. Но для разработки полной системы спецификаций одной модели обычно недостаточно, поэтому модель, как правило, сопровождается дополнениями.
Спецификация системы содержит:
описания функций с точки зрения пользователей. Функции системы, с которыми имеет дело пользователь определяются IDEF-моделью, поэтому автор должен выделить в модели эти функции, связать их с вопросами, относящимися к человеческому фактору;
указания и ограничения по проектированию:
-указания по проектированию (например, какие функции автономны, какие формируют основу, какие функции можно отложить до создания соответствующего программного обеспечения) должны быть изложены и привязаны к примечаниям на модели (т.е. выделенным основным функциям); -проектные ограничения, выявленные в процессе анализа (смета, график работ,
лимиты памяти и обработки данных, предварительно определенное техническое и программное обеспечение, ресурсы персонала), должны иметь вид примечаний, приведенных рядом с функцией, на которую они действуют;
критерии приемлемости (т.е. независимые испытатели, тесты, место и длительность тестирования) должны быть организованы вокруг структуры IDEFмодели, если нельзя придумать лучшей организации. Для документирования этой информации используются исполнители;
справочный материал (исходные документы, глоссарий терминов, описания специальных обозначений) важен для правильного понимания и использования спецификацией. Эта информация должна заноситься в соответствующие разделы спецификации. Материал большого объема (например, чертеж самолета) или материал общего характера (например, словарь данных) помещаются в одно или в несколько приложений.
Проектная группа
139
В разработке модели принимают участие специалисты разных направлений - аналитики, эксперты предметной области, библиотекари и контролеры, то на каждом из этапов создания модели заранее определяются права и обязанности участников проекта, а также формализованные процедуры, предписывающие правила координации деятельности участников.
При проведении сложных проектов обследования предприятий, разработка моделей с помощью методологии IDEF позволяет наглядно и эффективно отобразить весь механизм деятельности предприятия в нужном разрезе. Однако самое главное – это возможность коллективной работы, которую предоставляет IDEF. В практической деятельности построение модели осуществляется с прямой помощью сотрудников различных подразделений.
Для этого консультант за достаточно короткое время должен объяснить участникам проектной группы основные принципы IDEF и обучить работе с соответствующим прикладным программным обеспечением. В результате, сотрудники различных отделов должны создать IDEF-диаграммы деятельности своего функционального подразделения, созданные путем ответов на следующие вопросы:
что поступает в подразделение “на входе”?
какие функции, и в какой последовательности выполняются в рамках подразделения?
кто является ответственным за выполнение каждой из функций?
чем руководствуется исполнитель при выполнении каждой из функций?
что является результатом работы подразделения (на выходе)?
Разумеется, подобный подход требует ряда организационных мер, в первую очередь со стороны руководства обследуемого предприятия. Это обусловлено тем, что эта техника подразумевает возложение на некоторых сотрудников дополнительных обязанностей по освоению и практическому применению новых методологий. Однако в конечном итоге это оправдывает себя, так как дополнительные один-два часа работы отдельных сотрудников в течение нескольких дней позволяют существенно экономить средства на оплату консультационных услуг сторонней компании (которые в любом случае будут отрывать от работы тех же работников анкетами и вопросами). Что касается самих работников предприятия, так или иначе выраженного противодействия с их стороны я в своей практике не встречал.
Вывод из всего этого можно сделать следующий: совершенно не обязательно каждый раз самим придумывать решения для стандартных задач. Всегда, когда Вы сталкиваетесь с необходимостью анализа той или иной функциональной системы (от системы проектирования космического корабля, до процесса приготовления комплексного ужина) – используйте годами проверенные и обкатанные методы. Одним из таких методов и является IDEF0, позволяющий с помощью своего простого и понятного инструментария решать сложные жизненные задачи.
Общие положения
IDEF-модель –это результат коллективной работы, при которой авторы создают первоначальные диаграммы, основанные на собранной информации об объекте моделирования, и передают их другим участникам проекта для рассмотрения и формулирования замечаний.
Ценность модели (проекта) определяется ее приемлемостью для экспертов. Эта приемлемость достигается следующими путями:
постоянным рецензированием экспертами развивающейся модели, что обеспечивает не-обходимый уровень соответствия модели конкретной моделируемому объекту (если модель отражает состояние «как есть») или предполагаемому (состояние «как должно быть») в том понимании, которое соответствует мнению экспертов.
периодическим обсуждением диаграмм, частей модели и модели в целом на техническом совете, решение которого (оформленное в виде протокола) позволяет автору продолжить уточняющее моделирование или закончить его ввиду
достаточности детализации и приемлемости проекта (модели).
Если в процессе моделирования выявляется несогласованность оценок экспертов, то такая
140