- •Глава 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.4. Определение стрелок на контекстной диаграмме
Стрелки IDEF0-диаграмм обычно проще проектировать в следующем порядке: выход, вход, механизм исполнения, управление. Каждый функциональный блок обозначает отдельную функцию, и эта функция часто имеет четко описываемые результаты работы. Наличие неясностей при анализе выходов того или иного функционального блока – возможный сигнал необходимости проведения реинжиниринга рассматриваемого бизнес-процесса.
Определение выходов. После идентификации возможных выходов полезно провести анализ модели на предмет предвидения всех возможных сценариев поведения процесса. Это означает, что если существует вероятность возникновения той или иной ситуации в ходе процесса, модель ее отражает. Многие начинающие аналитики забывают отразить негативные результаты работы функциональных блоков. Например, блок "Провести экзамен по вождению" определенно произведет поток водителей, только что получивших права, но вполне правомерно ожидать и поток лиц, не сдавших экзамен. Негативные результаты часто используются в качестве обратных связей, их анализ должен проводиться для каждого блока. Также важным является необходимость включения в модель "спорных" стрелок, решение о наличии которых в модели могут принимать рецензирующие модель эксперты.
Определение входов. Входы можно рассматривать как особым образом преобразуемые функциональными блоками сырье или информация для получения выхода. В производственных отраслях определить, как входное сырье преобразуется в готовую продукцию, обычно довольно просто. Однако при моделировании информационных потоков входной поток данных может представляться не потребляемым и не обрабатываемым вообще. Случаи, когда входящие и исходящие стрелки называются одинаково, крайне редки и в основном указывают на бесполезность данного блока для системы в целом или на некорректный выбор имени для исходящей стрелки. Решением может служить применение более подробного описания для входящих и исходящих потоков данных. Например, вход может иметь название "Предварительный диагноз пациента", а выход – "Уточненный диагноз пациента".
Определение механизмов исполнения. После создания входов и выходов можно приступить к рассмотрению механизмов исполнения или ресурсов, относящихся к функциональному блоку. В понятие механизма исполнения входят персонал, оборудование, информационные системы и т.п. Например, функциональный блок "Собрать деталь" может потребовать использования какого-либо оборудования, например, гаечного ключа. При приеме экзаменов на водительские права механизмом исполнения является инспектор ГИБДД. Как правило, определить механизмы исполнения для функциональных блоков довольно просто.
Определение управления. Наконец, должно быть определено управление, контролирующее ход работы функционального блока. Все функциональные блоки в IDEF0 должны иметь хотя бы одно управление. В случаях когда неясно, относить ли стрелку ко входу или к управлению, следует ее рисовать как управление. Важно помнить, что управление можно рассматривать как особую форму входа функционального блока.
Когда контекстная диаграмма представляется завершенной, попробуйте задать следующие вопросы:
• Обобщает ли диаграмма моделируемый бизнес-процесс?
• Согласуется ли диаграмма с границами моделирования, точкой зрения и целью моделирования?
• Подходит ли выбранный уровень детализации стрелок для контекстного блока? (Обычно на контекстной диаграмме рекомендуется рисовать не более шести стрелок каждого типа.)