Файл: Методичка КР Вар 1.doc

ВУЗ: Не указан

Категория: Методичка

Дисциплина: Проектирование информационных систем

Добавлен: 25.10.2018

Просмотров: 4736

Скачиваний: 13

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

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

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

Во многих IDEF0-моделях находит или должно находить отражение явление, состоящее в формировании или специфической настройке (перестройке) механизмов в ходе деятельности. Это явление часто именуется реинжинирингом производства и/или бизнес-процессов на предприятии (в организации).

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

Укрупненная схема этой субдеятельности приведена на рис.1.3.


Рис. 1.3


Согласно схеме входом и одновременно потребляемым ресурсом субдеятельности являются финансы, преобразуемые в другие виды ресурсов — энергетические, трудовые, материальные (оборудование, вспомогательные материалы и т.д.).

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

Существенным признаком вспомогательного процесса является то, что этот процесс не создает конечного продукта деятельности и, следовательно, прибыли.

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

Ниже сформулирован ряд определений и методических положений, которыми следует руководствоваться при отражении управлений на функциональных моделях.

Управление деятельностью — это процесс, состоящий как минимум из следующих операций:

  • формулирование целей деятельности;

  • оценивание ресурсов, необходимых для осуществления деятельности и их сопоставление с имеющимися ресурсами;

  • сбор информации об условиях протекания и фактическом состоянии деятельности («глобальная» обратная связь);

  • выработка и принятие решений, направленных на достижение целей, в частности, решений о распределении ресурсов по процессам, входящим в состав деятельности; оформление решений в виде директив на управление процессами;

  • реализация решений (исполнение директив) и оценка их результатов («локальная обратная связь»);

  • корректировка (в случае необходимости, например при нехватке ресурсов) ранее сформулированных целей (самонастройка, адаптация).


Управление процессом — это операция, состоящая как минимум из следующих действий:

  • анализ директивы на управление процессом, ее декомпозиция на директивы управления операциями;

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

  • сопоставление информации о ходе операций с данными директив и выработка локальных решений, направленных на устранение отклонений;

  • корректировка (в случае необходимости) директив на выполнение операций.

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

Блоки управления должны присутствовать на каждой IDEF0-диаграмме (кроме тех, которые являются декомпозициями самих таких блоков). Через них осуществляются управляющие воздействия на остальные блоки диаграммы. Именно эти блоки воспринимают ограничивающую и предписывающую информацию и преобразуют ее в соответствующие директивы и команды. Имена таких блоков управления, как правило, содержат глагол «Управлять … ».

Стрелки, исходящие из блока с именем «Управлять … », описывают централизованную схему управления - управленческую «вертикаль».

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


1.2.3. Типизация функциональных моделей и IDEF0-диаграмм


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

Аналогичные типовые модели могут быть разработаны для других видов бизнеса (оказание услуг, транспорт, банковское дело, финансовая деятельность и т.д.).

1.2.4. Последовательность построения IDEF0-моделей


Основные этапы. Прежде чем начать моделирование, аналитик проводит

1. подготовку к моделированию;

2. собирает информацию по моделируемому объекту;

3. декомпозирует моделируемый объект;

4. обобщает полученную декомпозицию моделируемого объекта.

Подготовка к моделированию включает в себя:

  • выбор цели модели (например, описание того, как механический цех производит детали);

  • выбор точки зрения, с которой будет представлена модель (например, мастер, рабочий);

  • тип создаваемой модели (например, модель "потокового" процесса);

  • предполагаемое использование построенной и проверенной модели (например, подготовить нового оператора).


Таким образом, подготовка к моделированию должна максимально облегчить сбор информации.


Рис.1.4


Сбор информации по моделируемому объекту может включать любую комбинацию следующих видов деятельности:

  • чтение документов;

  • наблюдение за существующими операциями;

  • анкетирование группы экспертов;

  • опрос одного или нескольких экспертов;

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

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

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


Выбор цели и точки зрения. Цель и точка зрения модели определяются на самой ранней стадии создания модели.

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

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

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

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

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

На рис. 1.5 показано, как это делается для задачи, связанной с экспериментальным механическим цехом.



Рис. 1.5. Определение целей и точки зрения

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

В таком случае целесообразно составить списки данных и функций и, может быть, нарисовать диаграмму А0.

Сделав это, можно «почувствовать» систему и установить, описывает ли ее диаграмма А0 с нужной точки зрения.

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



Составление списка данных. Списки объектов системы, создаваемые в ходе моделирования, в стандарте IDEF0 принято называть «списками данных».

Термин «данное» здесь употребляется как синоним слова «объект». Поэтому, при обсуждении различных аспектов IDEF0 моделирования, как правило, применяется термин «список данных».

Составление списка данных является начальным этапом создания каждой диаграммы функциональной IDEF0-модели.

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

Формирование диаграммы начинается с выделения всех основных групп и категорий данных, используемых и генерируемых системой. При этом записывают все разумные возможности. При возникновении сомнении рекомендуется записывать все, что приходит на ум, потому что лучше записать слишком много, чем провести неполный анализ.

Так на рис. 1.6 в список вошло много деталей, хотя аналитик пытался создать диаграмму цеха как единого целого.

В современных аналитических методах слишком часто уделяется повышенное внимание функциям в ущерб данным.

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

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

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

Указывая вначале ограничения, выявляют естественную структуру анализируемой системы/объекта.

Без ограничений функциональная IDEF0-диаграмма представляет собой не более чем схему потоков данных.

Без ограничительных дуг диаграммы не смогут рассказать ее читателю, почему аналитик выбрал именно данную декомпозицию.

Благодаря тому, что в IDEF0 различаются входные дуги и дуги управления (информация, необходимая для пояснения декомпозиции), IDEF0-диаграммы ясно объясняют изучаемую систему и причину такой декомпозиции.

Составление списка функций. После формирования списка данных, приступают с его помощью к составлению списка функций.



Рис. 1.6. Подготовка списка функций и списка данных


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

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

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

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


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

Список функций должен находиться на одной странице со списком данных.

При составлении исходного списка не стоит пытаться объединять функции между собой.

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

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

Далее функции объединяют в «агрегаты».

Следует стремиться к организации 3-6 функциональных группировок одного и того же уровня сложности, содержащие примерно одинаковый «объем» функциональности, при этом функции в каждой из них должны иметь сходные операции и цели.

На рис. 1.6 видно, что исходный список функций сгруппирован в три функции более высокого уровня.

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


Построение диаграммы А0. Исходное содержание диаграммы А0 обеспечивают списки данных и функций.

Для правильного описания системы содержанию надо придать определенную форму. В стандарте IDEF0 это делается посредством построения диаграммы.

При построении диаграммы следует придерживаться определенного порядка:

  • расположить блоки на странице;

  • нарисовать основные дуги, представляющие ограничения;

  • нарисовать внешние дуги;

  • нарисовать все оставшиеся дуги.


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

Блоки располагаются в соответствии с их доминированием, т.е. по степени важности или по порядку следования.

Самый доминантный блок обычно располагается в верхнем левом углу, а наименее доминантный - в нижнем правом.

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