- •Глава 1. Асоиу как объект проектирования
- •1.1. Классификация асу
- •1.2. Структуризация ас
- •1.2.1. Виды структур ас
- •1.2.2. Виды обеспечений асоиу и их структура
- •Глава 2. Регламентация порядка проектирования асу
- •2.1. Общий порядок проектирования асу
- •2.2. Содержание работ предпроектных стадий создания асу.
- •2.3. Содержание работ проектных стадий создания асу
- •2.4. Содержание работ на стадиях ввода в действие и сопровождения асу
- •Глава 3. Методы и модели анализа и синтеза ас на предпроектных и проектных стадиях ее создания
- •3.1. Методы анализа документооборота в исследуемом объекте управления
- •3.2. Структурный анализ систем средствами idef-моделирования
- •3.2.1. Общие положения
- •3.2.2. Методология описания бизнес-процессов idef3
- •3.2.3. Методология функционального моделирования idef0
- •3.2.3.1. Точка зрения
- •3.2.4. Определение стрелок на контекстной диаграмме
- •3.2.5. Нумерация блоков и диаграмм
- •3.2.6. Связь между диаграммой и ее родительским функциональным блоком
- •3.2.7. Два подхода к началу моделирования ("в ширину" и "в глубину")
- •3.2.8. Когда остановиться?
- •3.2.9. Другие диаграммы idef0
- •3.2.10. Структурный анализ средствами idef-моделирования
- •3.2.11. Применение методов idef для моделирования поведения компаний
- •3.2.12. Синтаксис и семантика моделей idef0
- •3.2.13. Создание моделей idef3 для отображения блоков idef0
- •3.3. Структурный анализ потоков данных с помощью диаграмм dfd
- •3.4. Математическая модель оптимизации движения информационных потоков в системе управления
- •3.5. Построение макромодели ас на предпроектной стадии ее проектирования
- •Уровень 3, ранг 0
- •Уровень 2, ранг 1
- •Уровень 1, ранг 2
- •3.6. Формализация разбиения проектируемой ас на модули
- •3.6.1 Общая постановка задачи
- •3.6.2. Постановка и модель решения задачи разбиения илм асу на функциональные модули с минимальным числом информационных связей
- •3.6.3. Постановка и модель решения задачи разбиения илм асу на функциональные модули с минимальным временем обмена с внешней памятью эвм (базой данных)
- •3.6.4. Синтез технической структуры асутп на основе конденсации графовой функциональной модели системы
- •Алгоритм решения задачи
- •3.7. Синтез информационного обеспечения ас модульного типа
- •3.7.1. Постановка задачи
- •3.7.2. Задача и модель определения числа и состава информационных массивов
- •3.7.3. Задача выбора оптимальных методов организации полученных массивов и размещения программных модулей и массивов во внешней памяти эвм
- •3.7.4. Задача определения оптимальной величины блока данных
- •Глава 4. Примеры математических моделей для асоиу разрабатывающего предприятия (рп).
- •4.1. Агрегированные модели распределения ресурсов рп между нир и окр
- •4.1.1 Общая постановка задачи
- •4.1.2. Модель на основе временной зависимости между затратами ресурсов на нир и окр
- •4.2. Модели формирования тематического плана рп
- •4.2.1. Общая постановка задачи формированная тематического плана
- •4.2.2. Двухуровневое распределение ресурсов между разработками методом динамического программирования
- •4.3. Модели оперативного управления разработками
- •4.3.1. Модель определения срока начала выполнения новой разработки
- •4.3.2. Постановка и вероятностная модель определения периодичности контроля процесса выполнения проектных работ
- •4.4. Модели для определения частоты опроса отдельного исполнителя при оперативном управлении разработками
- •4.4.1. Графическая модель
- •Глава 5. Требования к содержанию документов, разрабатываемых на проектных стадиях создания ас
- •5.1. Общие положения
- •5.2. Требования к документам по общесистемным решениям
- •5.3.Требования к содержанию документов по видам обеспечения ас
- •5.3.1.Требования к содержанию документов по организационному обеспечению
- •5.3.2. Требования к содержанию документов с решениями по техническому обеспечению
- •5.3.3.Требования к содержанию документов с решениями по информационному обеспечению
- •5.3.4.Требования к содержанию документов с решениями по программному обеспечению
- •5.3.5.Требования к содержанию документов с решениями по математическому обеспечению
- •5.3.6.Требования к выполнению схем алгоритмов, программ, данных и систем
- •Экзаменационные вопросы по курсу «проектирование асоиу» 2004 – 2005 учебный год
- •Содержание
- •Глава 1. Асоиу как объект проектирования 1
- •Глава 2. Регламентация порядка проектирования асу 31
- •Глава 3. Методы и модели анализа и синтеза ас на предпроектных и проектных стадиях ее создания 43
- •Глава 4. Примеры математических моделей для асоиу разрабатывающего предприятия (рп). 131
- •Глава 5. Требования к содержанию документов, разрабатываемых на проектных стадиях создания ас 147
3.2. Структурный анализ систем средствами idef-моделирования
3.2.1. Общие положения
Постоянное усложнение производственно-технических и организационно-экономических систем – фирм, предприятий, производств, и др. субъектов производственно-хозяйственной деятельности – и необходимость их анализа с целью совершенствования функционирования и повышения эффективности обусловливают необходимость применения специальных средств описания и анализа таких систем. Эта проблема приобретает особую актуальность в связи с появлением интегрированных компьютеризированных производств и автоматизированных предприятий.
В США это обстоятельство было осознано еще в конце 70-ых годов, когда ВВС США предложили и реализовали Программу интегрированной компьютеризации производства ICAM (ICAM - Integrated Computer Aided Manufacturing), направленную на увеличение эффективности промышленных предприятий посредством широкого внедрения компьютерных (информационных) технологий.
Реализация программы ICAM потребовала создания адекватных методов анализа и проектирования производственных систем и способов обмена информацией между специалистами, занимающимися такими проблемами. Для удовлетворения этой потребности в рамках программы ICAM была разработана методология IDEF (ICAM Definition), позволяющая исследовать структуру, параметры и характеристики производственно-технических и организационно-экономических систем (в дальнейшем, там, где это не вызывает недоразумений – систем)
Методология IDEF в настоящее время поддерживается семейством из 11 стандартов, отражающих различные аспекты моделирования систем. Мы ограничимся тремя технологиями моделирования, а именно методом функционального моделирования IDF0, методом описания бизнес-процессов IDF3 и методом построения диаграмм потоков данных DFD.
Своим появлением семейство стандартов IDEF во многом обязано появившейся в 80-х гг. технологии автоматизированной поддержки разработки информационных систем CASE (Computer Aided Software Engineering). До настоящего времени эта технология с успехом применяется при разработке разнообразного программного обеспечения. Однако в последнее время CASE-технологии приобретают все большее распространение для моделирования и анализа деятельности предприятий, предоставляя богатый набор возможностей для оптимизации или, в терминах CASE, реинжиниринга технологических процедур, выполняемых этими предприятиями – бизнес-процессов.
IDEF0, ранее известный как технология структурированного анализа и разработки (Structured Analysis and Design Technique – SADT), был разработан компанией SofTech, Inc. в конце 60-х гг. как набор рекомендаций по построению сложных систем, которые предполагали взаимодействие механизмов и обслуживающего персонала. Значительная часть SADT была принята ВВС США как часть их программы интегрированной компьютерной поддержки производства (Integrated Computer-Aided Manufacturing – ICAM) в конце 70-х гг. Эта технология, переименованная в IDEF0, довольно быстро стала стандартом технологии моделирования деятельности в министерстве обороны США.
В 1993 г. группа пользователей IDEF (IDEF Users Group, в настоявшее время Society of Enterprise Engineering – SEE), совместно с Национальным институтом стандартов и технологии (National Institute of Standards and Technology – NIST) предприняли попытку создания документированного стандарта для IDEF0, который мог бы использоваться как военными, так и гражданскими департаментами правительства США. Этот стандарт был опубликован как федеральный стандарт обработки информации (Federal Information Processing Standard – FIPS).
Несколько независимо, но с использованием аналогичных подходов технология DFD (Data Flow Diagrams – диаграммы потоков данных) завоевала популярность для структурной разработки (а впоследствии и структурного анализа) проектов построения информационных систем. Диаграммы потоков данных во многом аналогичны моделям IDEF0 и могут быть использованы при проектировании информационных систем, например, после разработки моделей анализа IDEF0.
Стандарт IDEF3 был специально разработан для закрытого проекта ВВС США. Это технология получения описания деталей процесса от экспертов в предметной области и разработки таких моделей процессов, в которых важно понять последовательность выполнения действий и взаимозависимости между ними.
Подход SADT относится к классу формальных методов, используемых при анализе и разработке систем. Несмотря на то, что вполне допустима независимая разработка функциональных моделей, методология SADT предполагает ведение структурированного проекта анализа, в процессе которого происходит их создание. В дополнение к функциональному моделированию SADT структурный анализ предполагает построение информационных моделей данных и диаграмм состояний (State-Transition Diagrams – STD), которые моделируют поведение системы во времени.
Основной принцип SADT состоит в том, что тщательный анализ системы обусловливает получение возможного оптимального решения. Использование SADT автоматически приводит к необходимости сбора и обработки значительного количества информации о системе. Традиционно такая информация собирается аналитиком посредством формализованного опроса экспертов предметной области – людей, владеющих информацией о механизме функционирования системы в целом или ее частей. С течением времени некоторые эксперты освоили технологию моделирования, что привело к появлению IDEF3-технологии получения знаний от экспертов. Однако роль системного аналитика в проектах SADT оставалась ключевой.
Часто разработка моделей применяется для документирования ситуации, сложившейся к определенному моменту (модели "как есть" – «as is»). Впоследствии они применяются при создании новых моделей функционирования системы (модели "как должно быть" – «to be»), а также для проверки моделей «to be», с тем, чтобы удостовериться, что предлагаемые изменения действительно повлекут улучшение функционирования системы.
В дополнение к алгоритмизации процесса построения предлагаемой системы модели «to be» используются для планирования загрузки частей системы; калькуляции бюджета и распределения ресурсов; при построении плана реорганизации системы, определяющего действия по переводу системы из состояния «as is» в состояние «to be».
