ИНЖИНИРИНГ ИС 01 ПРОЕКТИРОВАНИЕ Функциональное

Скачать презентацию ИНЖИНИРИНГ ИС  01  ПРОЕКТИРОВАНИЕ  Функциональное Скачать презентацию ИНЖИНИРИНГ ИС 01 ПРОЕКТИРОВАНИЕ Функциональное

ingh_is_2017_01.pptx

  • Размер: 9.0 Мб
  • Автор:
  • Количество слайдов: 125

Описание презентации ИНЖИНИРИНГ ИС 01 ПРОЕКТИРОВАНИЕ Функциональное по слайдам

ИНЖИНИРИНГ ИС  01 ИНЖИНИРИНГ ИС

ПРОЕКТИРОВАНИЕ  Функциональное Работоориентированный (ERWin Process Modeller) Датаориентированный (ERWin Process Modeller)  Объектное МодельноориентрованноеПРОЕКТИРОВАНИЕ Функциональное Работоориентированный (ERWin Process Modeller) Датаориентированный (ERWin Process Modeller) Объектное Модельноориентрованное (Math. Lab) Use-Case ориентированное (RR, Visio) Структурноориентированное (RR, Visio)

ИНФОРМАЦИОННЫЕ ТЕХНЛОГИИ ИНФОРМАЦИОННЫЕ ТЕХНЛОГИИ

ИНФОРМАЦИЯ И ДАННЫЕ  Информация это сведения о лицах, предметах, фактах,  событиях, явленияхИНФОРМАЦИЯ И ДАННЫЕ Информация это сведения о лицах, предметах, фактах, событиях, явлениях и процессах независимо от формы их представления. (Закон РФ «Об информации, информатизации и защите информации» ) Данные – это информация, представленная в виде, пригодном для обработки автоматическими средствами (ISO – International Organization of Standardization (Международная организация по стандартизации))

АВТОМАТИЗИРОВАННАЯ ИНФОРМАЦИОННАЯ СИСТЕМА  Автоматизированная информационная система – это совокупность методического обеспечения, технических (аппаратных)АВТОМАТИЗИРОВАННАЯ ИНФОРМАЦИОННАЯ СИСТЕМА Автоматизированная информационная система – это совокупность методического обеспечения, технических (аппаратных) и программных средств, а также работающих с ними пользователей (персонала), обеспечивающая процессы получения, передачи, обработки, хранения и представления информации. Методическое обеспечение играет первостепенную и направляющую роль в процессе эксплуатации информационной системы (ИС) — совокупность документов , описывающих технологию функционирования информационной системы, методы выбора и применения пользователями технологических приемов для получения конкретных результатов.

КАТЕГОРИИ СТАНДАРТОВ  -официальные международные, официальные национальные или национальные ведомственные стандарты (например,  стандартыКАТЕГОРИИ СТАНДАРТОВ -официальные международные, официальные национальные или национальные ведомственные стандарты (например, стандарты ISO, IEC, ГОСТ); -стандарты международных консорциумов и комитетов по стандартизации (например, стандарты ОМG); -стандарты «де-факто» – официально никем не утвержденные, но фактически действующие (например, стандартом «де-факто» долгое время были язык взаимодействия с реляционными базами данных SQL); -фирменные стандарты (например, Microsoft ODBC).

СТАНДАРТЫ ISO/IEC (ИСО/МЭК) В ОБЛАСТИ РАЗРАБОТКИ И ДОКУМЕНТИРОВАНИЯ ПРОГРАММНЫХ СРЕДСТВ ГОСТ Р ИСО/МЭК 12207СТАНДАРТЫ ISO/IEC (ИСО/МЭК) В ОБЛАСТИ РАЗРАБОТКИ И ДОКУМЕНТИРОВАНИЯ ПРОГРАММНЫХ СРЕДСТВ ГОСТ Р ИСО/МЭК 12207 -02 Информационная технология. Процессы жизненного цикла программных средств ГОСТ Р ИСО/МЭК 15271 -02 Информационная технология. Руководство по ИСО/МЭК 12207 (процессы жизненного цикла программных средств) ГОСТ Р ИСО/МЭК 9126 -93 Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению ГОСТ Р ИСО/МЭК 12119 -94 Информационная технология. Пакеты программ. Требования к качеству и тестирование

КОМПЛЕКС НОРМАТИВНЫХ ДОКУМЕНТОВ НА АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ ГОСТ 34. 003 -90 Автоматизированные системы. Термины иКОМПЛЕКС НОРМАТИВНЫХ ДОКУМЕНТОВ НА АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ ГОСТ 34. 003 -90 Автоматизированные системы. Термины и определения ГОСТ 34. 201 -89 Виды, комплектность и обозначение документов при создании автоматизированных систем ГОСТ 34. 601 -90 Автоматизированные системы. Стадии создания ГОСТ 34. 602 -89 Техническое задание на создание автоматизированной системы РД 50 -698 -90 Автоматизированные системы. Требования к содержанию документов РД 50 -34. 126 -92 Рекомендации. Правила проведения работ при создании автоматизированных систем

КОМПЛЕКС СТАНДАРТОВ ЕДИНОЙ СИСТЕМЫ ПРОГРАММНОЙ ДОКУМЕНТАЦИИ (ЕСПД) ГОСТ 19. 101 -77 Виды программ иКОМПЛЕКС СТАНДАРТОВ ЕДИНОЙ СИСТЕМЫ ПРОГРАММНОЙ ДОКУМЕНТАЦИИ (ЕСПД) ГОСТ 19. 101 -77 Виды программ и программных документов ГОСТ 19. 102 -77 Стадии разработки ГОСТ 19. 105 -78 Общие требования к программным продуктам ГОСТ 19. 201 -78 Техническое задание. Требования к содержанию и оформлению ГОСТ 19. 701 -90 (ИСО/МЭК 5807 -85) Схемы алгоритмов программ, данных и систем. Условные обозначения и правила выполнения

КОМПЛЕКС ОТРАСЛЕВЫХ РУКОВОДЯЩИХ МЕТОДИЧЕСКИХ МАТЕРИАЛОВ (ИНФОРМАЦИОННЫЕ СИСТЕМЫ НА ЖЕЛЕЗНОДОРОЖНОМ ТРАНСПОРТЕ (ОРММ ИСЖТ)) ОРММ ИСЖТКОМПЛЕКС ОТРАСЛЕВЫХ РУКОВОДЯЩИХ МЕТОДИЧЕСКИХ МАТЕРИАЛОВ (ИНФОРМАЦИОННЫЕ СИСТЕМЫ НА ЖЕЛЕЗНОДОРОЖНОМ ТРАНСПОРТЕ (ОРММ ИСЖТ)) ОРММ ИСЖТ 5. 03 -00 Процессы жизненного цикла ИС и программных средств ОРММ ИСЖТ 2. 01 -00 Требования к составу, содержанию и оформлению документов при создании ИС ОРММ ИСЖТ 2. 02 -00 Порядок представления, согласования и утверждения документов, разрабатываемых при создании ИС

Ж И З Н Е Н Н Ы Й  Ц И К ЛЖ И З Н Е Н Н Ы Й Ц И К Л И Н Ф О Р М А Ц И О Н Н О Й С И С Т Е М Ы

 Жизненный цикл информационной системы – это непрерывный процесс, начинающийся с момента принятия решения Жизненный цикл информационной системы – это непрерывный процесс, начинающийся с момента принятия решения о создании информационной системы и заканчивающийся в момент полного изъятия ее из эксплуатации — основные процессы (заказ, поставка, разработка, эксплуатация, сопровождение); — вспомогательные процессы (обеспечивают выполнение основных процессов); — организационные процессы

ВСПОМОГАТЕЛЬНЫЕ ПРОЦЕССЫ  документирование – работы по разработке, выпуску, редактированию, распространению и сопровождению документов,ВСПОМОГАТЕЛЬНЫЕ ПРОЦЕССЫ документирование – работы по разработке, выпуску, редактированию, распространению и сопровождению документов, в которых нуждаются все заинтересованные лица; управление конфигурацией (конфигурационное управление) включает работы: определение и установление состояния программных объектов в системе; управление изменениями и выпуском объектов; обеспечение полноты, совместимости и правильности объектов; управление хранением, обращением и поставкой объектов; обеспечение качества – работы по обеспечению соответствия создаваемой системы и реализуемых процессов жизненного цикла установленным требованиям и утвержденным планам; верификация – работы соответствующего субъекта (заказчика, поставщика или независимой стороны) по проверке соответствия создаваемых промежуточных результатов установленным требованиям по мере реализации проекта. Различают верификацию договора, процесса, требований, проекта, системы, сборки системы и документации; аттестация – работы соответствующего субъекта по проверке полного соответствия требований и конечного продукта функциональному назначению системы; совместный анализ – работы по оценке состояния или результатов какой-либо работы (системы); аудит – работы независимых (по отношению к проекту) экспертов по определению соответствия деятельности субъекта принятым требованиям, планам и условиям договора; разрешение проблем – работы по анализу и устранению проблем, обнаруженных при реализации проекта;

ОРГАНИЗАЦИОННЫЕ  управление проектами – работы по планированию и управлению процессами, включая контроль, проверкуОРГАНИЗАЦИОННЫЕ управление проектами – работы по планированию и управлению процессами, включая контроль, проверку и оценку выполненных работ с формированием отчетности; создание инфраструктуры проекта – работы по установлению и обеспечению инфраструктуры, необходимой для любого другого процесса. Инфраструктура может содержать технические и программные средства, инструментальные средства, методики, стандарты и условия для разработки, эксплуатации или сопровождения системы; усовершенствование – работы по оценке, контролю и улучшению процессов жизненного цикла; обучение – работы по планированию и проведению обучения персонала, включая разработку учебных материалов. При этом под персоналом понимаются не только конечные пользователи, которые будут эксплуатировать систему, но и разработчики системы.

С Т А Д И И  Ж И З Н Е Н НС Т А Д И И Ж И З Н Е Н Н О Г О Ц И К Л А И Н Ф О Р М А Ц И О Н Н О Й С И С Т Е М Ы

КЛАССИЧЕСКИЙ ЖЦ И ИСО / МЭК 12207 Классический ЖЦ ИСО / МЭК 12207 СистемныйКЛАССИЧЕСКИЙ ЖЦ И ИСО / МЭК 12207 Классический ЖЦ ИСО / МЭК 12207 Системный анализ Заказ Анализ требований Разработка Проектирование Кодирование (реализация) Тестирование Внедрение и сопровождение Поставка и эксплуатация Сопровождение и эксплуатация

МОДЕЛИ ЖИЗНЕННОГО ЦИКЛА МОДЕЛИ ЖИЗНЕННОГО ЦИКЛА

КАСКАДНАЯ МОДЕЛЬ модель применяется при разработке информационных систем, для которых в самом начале разработкиКАСКАДНАЯ МОДЕЛЬ модель применяется при разработке информационных систем, для которых в самом начале разработки можно достаточно и полно сформулировать все требования.

ВОДОПАДНАЯ (КАСКАДНАЯ,  ПОСЛЕДОВАТЕЛЬНАЯ) МОДЕЛЬ V 2 ВОДОПАДНАЯ (КАСКАДНАЯ, ПОСЛЕДОВАТЕЛЬНАЯ) МОДЕЛЬ V

 Достоинства модели:  -на каждой стадии формируется законченный набор документации, программного и аппаратного Достоинства модели: -на каждой стадии формируется законченный набор документации, программного и аппаратного обеспечения, отвечающий критериям полноты и согласованности; -выполняемые в четкой последовательности стадии позволяют уверенно планировать сроки выполнения работ и соответствующие ресурсы (денежные, материальные и людские). Недостатки модели: -реальный процесс разработки информационной системы редко полностью укладывается в такую жесткую схему. Особенно это относится к разработке нетиповых и новаторских систем; -жизненный цикл основан на точной формулировке исходных требований к информационной системе. Реально в начале проекта требования заказчика определены лишь частично; -основной недостаток – результаты разработки доступны заказчику только в конце проекта. В случае неточного изложения требований или их изменения в течение длительного периода создания ИС заказчик получает систему, не удовлетворяющую его потребностям.

ПОЭТАПНАЯ МОДЕЛЬ С ПРОМЕЖУТОЧНЫМ КОНТРОЛЕМ ПОЭТАПНАЯ МОДЕЛЬ С ПРОМЕЖУТОЧНЫМ КОНТРОЛЕМ

ИНКРЕМЕНТНАЯ (ИТЕРАЦИОННАЯ) МОДЕЛЬ характерна при разработке сложных систем,  для которых имеется четкое видениеИНКРЕМЕНТНАЯ (ИТЕРАЦИОННАЯ) МОДЕЛЬ характерна при разработке сложных систем, для которых имеется четкое видение (как со стороны заказчика, так и со стороны разработчика) : — отсутствия у заказчика возможности сразу профинансировать весь проект; — отсутствия у разработчика необходимых ресурсов для реализации проекта в сжатые сроки; — требований поэтапного внедрения и освоения продукта конечными пользователями.

СПИРАЛЬНАЯ МОДЕЛЬ новаторские (нетиповые) системы. В начале работы над проектом у заказчика и разработчикаСПИРАЛЬНАЯ МОДЕЛЬ новаторские (нетиповые) системы. В начале работы над проектом у заказчика и разработчика нет четкого видения итогового продукта (требования не могут быть четко определены) или стопроцентной уверенности в успешной реализации проекта (риски очень велики). В связи с этим принимается решение разработки системы по частям с возможностью изменения требований или отказа от ее дальнейшего развития Барри Боэм, 1988 г.

СПИРАЛЬНАЯ МОДЕЛЬ V 2 СПИРАЛЬНАЯ МОДЕЛЬ V

 Достоинства модели:  -позволяет быстрее показать пользователям системы работоспособный продукт, тем самым, Достоинства модели: -позволяет быстрее показать пользователям системы работоспособный продукт, тем самым, активизируя процесс уточнения и дополнения требований; -допускает изменение требований при разработке информационной системы, что характерно для большинства разработок, в том числе и типовых; -обеспечивает большую гибкость в управлении проектом; -позволяет получить более надежную и устойчивую систему. По мере развития системы ошибки и слабые места обнаруживаются и исправляются на каждой итерации; -позволяет совершенствовать процесс разработки – анализ, проводимый в каждой итерации, позволяет проводить оценку того, что должно быть изменено в организации разработки, и улучшить ее на следующей итерации; -уменьшаются риски заказчика. Заказчик может с минимальными для себя финансовыми потерями завершить развитие неперспективного проекта. Недостатки модели: -увеличивается неопределенность у разработчика в перспективах развития проекта. Этот недостаток вытекает из предыдущего достоинства модели; -затруднены операции временного и ресурсного планирования всего проекта в целом.

М Е Т О Д О Л О Г И И ,  ПМ Е Т О Д О Л О Г И И , П О Д Д Е Р Ж И В А Ю Щ И Е С П И Р А Л Ь Н У Ю М О Д Е Л Ь

МЕТОДОЛОГИЯ RAD.  ЭЛЕМЕНТЫ  -небольшая команда программистов (до 10 человек);  -короткий, ноМЕТОДОЛОГИЯ RAD. ЭЛЕМЕНТЫ -небольшая команда программистов (до 10 человек); -короткий, но тщательно проработанный производственный график (от 2 до 6 месяцев); -повторяющийся цикл, при котором разработчики по мере того, как приложение начинает обретать форму, реализуют в продукте требования, полученные через взаимодействие с заказчиком. Методология быстрой разработки приложений (Rapid Application Development, RAD)

МЕТОДОЛОГИЯ RAD.  ИСПОЛЬЗОВАНИЕ  -CASE-средствадля формирования и анализа требований,  проектирования системы, автоматическойМЕТОДОЛОГИЯ RAD. ИСПОЛЬЗОВАНИЕ -CASE-средствадля формирования и анализа требований, проектирования системы, автоматической генерации кода программ и структуры БД, а также автоматического тестирования программного обеспечения; -инструментальные средства, обеспечивающие визуальную разработку (программирование) системы. -инструментальные средства, поддерживающие объектно-ориентированный подход. -инструментальные средства, обеспечивающие событийное программирование. -шаблоны и библиотек готовых решений как собственной разработки, так и сторонних производителей.

УСЛОВИЯ ПРИМЕНЕНИЯ МЕТОДОЛОГИИ RAD  -применима для относительно небольших проектов, разрабатываемых под конкретного заказчика;УСЛОВИЯ ПРИМЕНЕНИЯ МЕТОДОЛОГИИ RAD -применима для относительно небольших проектов, разрабатываемых под конкретного заказчика; -неприменима для построения сложных расчетных программ, операционных систем или программ управления космическими кораблями, т. е. программ, требующих написания большого объема (сотни тысяч строк) уникального кода; -неприменима для разработки приложений, в которых отсутствует ярко выраженная интерфейсная часть, наглядно определяющая логику работы системы (например, приложения реального времени); -неприменима для разработки приложений, от которых зависит безопасность людей (например, управление самолетом или атомной электростанцией), так как итеративный подход предполагает, что первые несколько версий, скорее всего не будут полностью работоспособны, что в данном случае исключается

МЕТОДОЛОГИЯ XP.  ОСОБЕННОСТИ  -частая смена версий и модификаций (длительность итераций вплоть доМЕТОДОЛОГИЯ XP. ОСОБЕННОСТИ -частая смена версий и модификаций (длительность итераций вплоть до часов и минут, а обычно – 2 недели; в RAD – минимум 2 месяца); -непрерывная связь с заказчиком; -простое проектирование – при разработке всегда выбирается наиболее простое решение; -простой дизайн – система должна быть спроектирована настолько просто, насколько это возможно на каждый момент времени; -коллективное владение кодом – любой, кто видит возможность улучшить какую-то часть кода, может сделать это в любой момент времени; -программирование в парах – на пару программистов приходится один компьютер. Пока один из них непосредственно программирует, другой обдумывает вопросы реализации требований (функций, БД и т. п. ); -непрерывное и пересекающееся проектирование, разработка, интеграция и тестирование системы. Экстремальное программирование (e. Xtreme Programming, XP – автор Кент Бек, 1999)

V-MODEL V-MODEL

О С Н О В Ы  А Н А Л И З АО С Н О В Ы А Н А Л И З А И П Р О Е К Т И Р О В А Н И Я И Н Ф О Р М А Ц И О Н Н Ы Х С И С Т Е М

ЛР 1. Таблица (Роль в системе, Действие) 2. IDEF 0 3. IDEF 3 4.ЛР 1. Таблица (Роль в системе, Действие) 2. IDEF 0 3. IDEF 3 4. DFD 5. Варианты использования 6. Классы анализа 7. Кооперации 8. Классы проектирования 9. Последовательности 10. Компонентов 1. Excel, Word 2 -4 ERWin Process Modeller 5 -10 IBM Rationa Rose|

ОСОБЕННОСТИ  - сложность описания (достаточно большое количество функций, процессов, элементов данных и сложныеОСОБЕННОСТИ — сложность описания (достаточно большое количество функций, процессов, элементов данных и сложные взаимосвязи между ними) требует тщательного моделирования и анализа данных и процессов; — наличие совокупности тесно взаимодействующих компонентов (подсистем); — отсутствие прямых аналогов , ограничивающее возможность использования каких-либо типовых проектных решений и прикладных систем; — необходимость интеграции существующих и вновь разрабатываемых подсистем; — функционирование в неоднородной среде на разных аппаратных и операционных платформах; — разобщенность и разнородность отдельных групп разработчиков по уровню квалификации и сложившимся традициям использования тех или иных инструментальных средств; — существенная временная протяженность проекта , обусловленная ограниченными возможностями коллектива разработчиков, масштабами организации-заказчика, различной степенью готовности отдельных ее подразделений к внедрению информационных систем и т. д. ; — изменение или уточнение потребностей пользователей в процессе разработки и эксплуатации системы.

ОСНОВНЫЕ ДОКУМЕНТЫ С ТРЕБОВАНИЯМИ К СИСТЕМЕ  календарный план выполнения работ регламентирует состав, срокиОСНОВНЫЕ ДОКУМЕНТЫ С ТРЕБОВАНИЯМИ К СИСТЕМЕ календарный план выполнения работ регламентирует состав, сроки и финансирование работ техническое задание – основные требования к системе (ГОСТ 34. 602– 89 «Техническое задание на создание автоматизированной системы» )

РАЗДЕЛЫ ТЗ  -общие сведения (наименование системы; наименование предприятий разработчика и заказчика с ихРАЗДЕЛЫ ТЗ -общие сведения (наименование системы; наименование предприятий разработчика и заказчика с их реквизитами; перечень документов, на основании которых создается система, плановые сроки начала и окончания работы и т. д. ); -назначение и цели создания (развития) системы; -характеристика объектов автоматизации; -требования к системе в целом, к функциям и обеспечению.

ВИДЫ ОБЕСПЕЧЕНИЯ  o математическое – совокупность математических методов, моделей и алгоритмов,  применяемыхВИДЫ ОБЕСПЕЧЕНИЯ o математическое – совокупность математических методов, моделей и алгоритмов, применяемых в информационной системе; o информационное – совокупность форм документов, классификаторов, нормативной базы и реализованных решений по объемам, размещению и формам существования информации; o лингвистическое – совокупность правил применения в системе языков программирования, языков взаимодействия пользователей и технических средств системы, а также совокупность требований к кодированию и декодированию данных, к способам организации диалога и т. д. ; o программное – совокупность программ и документов, предназначенных для отладки, функционирования и проверки работоспособности системы; o техническое – совокупность всех технических средств, используемых при функционировании системы; o организационное – совокупность документов, устанавливающих организационную структуру, права и обязанности пользователей и эксплуатационного персонала системы; o методическое – совокупность документов, описывающих технологию функционирования системы, методы выбора и применения пользователями технологических приемов для получения конкретных результатов;

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

МОЖЕТ ВКЛЮЧАТЬ ПРИЛОЖЕНИЯ  -расчет ожидаемой эффективности системы;  -оценку научно-технического уровня системы; МОЖЕТ ВКЛЮЧАТЬ ПРИЛОЖЕНИЯ -расчет ожидаемой эффективности системы; -оценку научно-технического уровня системы; -перечень основных входных и выходных форм

ОСНОВНЫЕ ПРИНЦИПЫ ПРОЕКТИРОВАНИЯ  Процесс перехода от первичного описания системы в виде технического заданияОСНОВНЫЕ ПРИНЦИПЫ ПРОЕКТИРОВАНИЯ Процесс перехода от первичного описания системы в виде технического задания к ее описанию в виде набора стандартных документов (проектной документации), достаточных для создания системы, называется проектированием.

ОБЩИЕ ПРИНЦИПЫ  1. Принцип декомпозиции (разделяй и властвуй) – принцип решения сложных проблемОБЩИЕ ПРИНЦИПЫ 1. Принцип декомпозиции («разделяй и властвуй») – принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения. 2. Принцип иерархического упорядочения – организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне. 3. Принцип концептуальной общности заключается в следовании единой философии на всех стадиях жизненного цикла 4. Принцип абстрагирования — выделение существенных элементов системы и отвлечении от несущественных. 5. Принцип формализации — строгий методический подход к решению проблемы и описании системы на формальном языке, пригодном для ее анализа, проектирования и разработки, а также автоматизированной генерации кода и БД.

 6. Принцип унификации - унифицированное представление и обозначение одного и того же элемента 6. Принцип унификации — унифицированное представление и обозначение одного и того же элемента или однотипных элементов в разных моделях. 7. Принцип логической независимости — концентрации внимания на логическом проектировании в целях обеспечения независимости от физической реализации. 8. Принцип многомодельности — единственная модель не может с достаточной степенью адекватности описать различные аспекты сложной системы. 9. Принцип непротиворечивости (согласованности) — согласованность элементов моделей и самих моделей между собой. 10. Принцип информационной закрытости (инкапсуляции) — содержание внутреннего устройства элементов системы должно быть скрыто друг от друга — обмен информацией между элементами системы только в минимально необходимом объеме и ограничение доступа к операциям и данным каждого из них. 11. Принцип полиморфизма –построения элементов модели таким образом, чтобы они могли принимать различные внешние формы или функциональность (поведение) в зависимости от обстоятельств. Или свойство родственных элементов решать сходные по смыслу проблемы разными способами.

КЛАССИФИКАЦИЯ МОДЕЛЕЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ ПО СТРОГОСТИ ОПИСАНИЯ - неформальные – представлены в неструктурированном видеКЛАССИФИКАЦИЯ МОДЕЛЕЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ ПО СТРОГОСТИ ОПИСАНИЯ — неформальные – представлены в неструктурированном виде и дают общее представление о моделируемой системе. Недостаточно наглядны (особенно при сложном взаимодействии между объектами) и неприемлемы для какого-либо количественного анализа и обработки автоматическими средствами; — формальные : описательные – модели, где сведения представлены с помощью специальных документов (бланки, формы, анкеты, таблицы и т. п. ); графические – модели представляют собой схемы, чертежи, графы, диаграммы и т. д. Наиболее наглядны и получили широкое распространение при проектировании с помощью. CASE-средств; математические – представляют модель на языке математических отношений в виде функциональных зависимостей, систем алгебраических или дифференциальных уравнений, логических выражений и т. д.

ПО СТЕПЕНИ ФИЗИЧЕСКОЙ РЕАЛИЗАЦИИ (ЛОГИЧЕСКОЙ НЕЗАВИСИМОСТИ)  - логические – описывают состав, структуру, состояниеПО СТЕПЕНИ ФИЗИЧЕСКОЙ РЕАЛИЗАЦИИ (ЛОГИЧЕСКОЙ НЕЗАВИСИМОСТИ) — логические – описывают состав, структуру, состояние или поведение элементов системы без привязки к конкретным языкам или средам программирования, СУБД, техническим средствам и т. д. При разработке системы это обеспечивает гибкость в выборе и быстрый переход с одной программно-аппаратной платформы на другую; — физические – описывают элементы системы в соответствии с принятой физической реализацией этих элементов (языками программирования, СУБД, устройствами, и т. д. );

ПО СТЕПЕНИ ОТОБРАЖЕНИЯ ДИНАМИКИ ПРОИСХОДЯЩИХ ПРОЦЕССОВ  - статические – описывают состав и структуруПО СТЕПЕНИ ОТОБРАЖЕНИЯ ДИНАМИКИ ПРОИСХОДЯЩИХ ПРОЦЕССОВ — статические – описывают состав и структуру системы; — динамические – описывают поведение системы и/или ее отдельных элементов. Как правило, такие модели описывают порядок действий или состояния системы и переходы между ними. Другими словами, в этих моделях явно или не явно присутствует понятие времени;

ПО ОТОБРАЖАЕМОМУ АСПЕКТУ  - функциональные – описывают функции системы, возможные варианты ее использования;ПО ОТОБРАЖАЕМОМУ АСПЕКТУ — функциональные – описывают функции системы, возможные варианты ее использования; могут содержать сведения о циркулирующей в системе информации, объектах и субъектах, взаимодействующих с системой; могут быть как динамическими, так и статическими моделями; — информационные – описывают состав и структуру данных (реляционных БД, классов и др. ). Относятся к статическим моделям; — поведенческие – описывают состояния системы и/или ее отдельных элементов и переходы между ними, взаимодействие элементов, алгоритмы обработки информации. Относятся к динамическим моделям; — компонентные – описывают состав и структуру программных и аппаратных средств. Относятся к статическим моделям; — смешанные – характеризуют сразу несколько аспектов системы (например, диаграммы потоков данных отображают работы, накопители данных, подсистемы)

C A S E - Т Е Х Н О Л О Г ИC A S E — Т Е Х Н О Л О Г И И А Н А Л И З А И П Р О Е К Т И Р О В А Н И Я

CASE-ТЕХНОЛОГИЯ  CASE-технология представляет собой методологию проектирования информационных систем, набор методов,  нотацийи инструментальныхCASE-ТЕХНОЛОГИЯ CASE-технология представляет собой методологию проектирования информационных систем, набор методов, нотацийи инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать модель системы на всех этапах разработки и сопровождения системы и разрабатывать приложения в соответствии с информационными потребностями пользователей

 - централизованное хранение в единой базе данных проекта (репозитарии) информации об информационной системе — централизованное хранение в единой базе данных проекта (репозитарии) информации об информационной системе в течение всего жизненного цикла. Репозитарий может хранить объекты различных типов: диаграммы, определения экранов и меню, проекты отчетов, описание данных, логику их обработки, исходные коды программ и т. п. ; — прямое проектирование программного обеспечения и баз данных. При этом порядок использования разработчиками CASE-средства следующий: создается логическая модель системы; выбирается конкретный язык программирования или СУБД для построения физической модели, после чего CASE-средство автоматически создает физическую модель системы; дорабатывается физическая модель; выполняется автоматическая генерация текста программы или структуры базы данных на диске;

 - обратное проектирование (реинжиниринг). В этом случае порядок использования CASE-средства обратный – от — обратное проектирование (реинжиниринг). В этом случае порядок использования CASE-средства обратный – от текста программы или базы данных на диске к логической модели. Помимо построения, CASE-средства позволяют быстро интегрировать полученные таким образом модели в проект, а также с меньшими потерями переходить от одной физической реализации к другой (например, в случае ухода «старых» разработчиков, плохо документирующих программное обеспечение, или появления новых, более перспективных языков программирования и СУБД); — синхронизация моделей системы с ее физической реализацией. В случае изменения модели системы могут быть автоматически внесены необходимые изменения в физическую реализацию или наоборот; — автоматическое обеспечение качества и тестирование моделей на наличие ошибок (например, ошибок нормализации БД), полноту и непротиворечивость; — автоматическая генерация документации. Вся документация по проекту генерируется автоматически на базе репозитария (как правило, в соответствии с требованиями действующих стандартов).

ЦЕЛЬ ИСПОЛЬЗОВАНИЯ CASE-ТЕХНОЛОГИЙ  Максимальная автоматизация стадий анализа и проектирования систем с целью построенияЦЕЛЬ ИСПОЛЬЗОВАНИЯ CASE-ТЕХНОЛОГИЙ Максимальная автоматизация стадий анализа и проектирования систем с целью построения формальных и непротиворечивых моделей системы Вынесение части деятельности (чем больше, тем лучше) из стадии кодирования в стадию проектирования

СТРУКТУРНЫЙ  ПОДХОД СТРУКТУРНЫЙ ПОДХОД

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

МЕТОДОЛОГИИ СТРУКТУРНОГО АНАЛИЗА И ПРОЕКТИРОВАНИЯ Методология Тип разрабатываемой модели SADT (Structured Analysis and DesignМЕТОДОЛОГИИ СТРУКТУРНОГО АНАЛИЗА И ПРОЕКТИРОВАНИЯ Методология Тип разрабатываемой модели SADT (Structured Analysis and Design Technique, методология структурного анализа и проектирования) Функциональная DFD (Data Flow Diagrams, диаграммы потоков данных) Функциональная или компонентная ERD (Entity-Relationship Diagrams, диаграммы «сущность-связь») Информационная Flowcharts (блок-схемы) Поведенческая EPC (Event-driven Process Chain, событийная цепочка процессов) Функциональная или поведенческая BPMN (Business Process Model and Notation, модель и нотация бизнес-процессов) Функциональная или поведенческая

ПРЕДВАРИТЕЛЬНЫЕ ДЕЙСТВИЯ ПРЕДВАРИТЕЛЬНЫЕ ДЕЙСТВИЯ

ТАБЛИЦА РОЛЕЙ ТАБЛИЦА РОЛЕЙ

О С Н О В Ы  Ф У Н К Ц И ОО С Н О В Ы Ф У Н К Ц И О Н А Л Ь Н О Г О А Н А Л И З А И П Р О Е К Т И Р О В А Н И Я С И С Т Е М

ПРОБЛЕМЫ  -заказчик не может точно выразить, решение каких задач возлагается на информационную систему.ПРОБЛЕМЫ -заказчик не может точно выразить, решение каких задач возлагается на информационную систему. Зачастую заказчик даже не знает, что такое требование и как его формулировать; -представители заказчика (начальники разных уровней, эксперты-технологи, рядовые пользователи) по-своему видят работу будущей системы и часто их требования к системе носят взаимоисключающий характер. Особенно характерна такая ситуация, когда разрабатываемая система будет внедряться на нескольких объектах автоматизации; -заказчик зачастую не знает возможностей современных вычислительных систем и стремится рассматривать процесс автоматизации как простой перенос элементарных видов деятельности, выполняемых вручную, на компьютеры. При этом он не задумывается об оптимизации бизнес-процессов внутри организации с приходом новых технологий; -заказчик не верит в возможность выполнения некоторых функций «бездушными» машинами.

AS-IS (КАК ЕСТЬ)  На основе должностных инструкций, приказов, отчетов,  нормативной документации AS-IS (КАК ЕСТЬ) На основе должностных инструкций, приказов, отчетов, нормативной документации Анализ модели позволяет понять, где находятся слабые места, в чем будут состоять преимущества новых процессов и насколько глубоким изменениям подвергнется существующая организация деятельности предприятия (компании, отдела). Признаки неэффективной организации деятельности: -бесполезные, неуправляемые и дублирующие работы; -работы без результата; -неэффективный документооборот (нужный документ не оказывается в нужное время в нужном месте)

TO-BE (КАК БУДЕТ)  недостатки исправляются  создается модель новой организации работы предприятия. МодельTO-BE (КАК БУДЕТ) недостатки исправляются создается модель новой организации работы предприятия. Модель TO-BE нужна для анализа альтернативных путей решения задачи и выбора наилучшего из них.

 SHOULD-BE (КАК ДОЛЖНО БЫЛО БЫТЬ).  Идеализированная модель SHOULD-BE (КАК ДОЛЖНО БЫЛО БЫТЬ). Идеализированная модель

IDEF 0 I

Система разбивается на функциональные подсистемы, которые, в свою очередь, делятся на подфункции, подфункции –Система разбивается на функциональные подсистемы, которые, в свою очередь, делятся на подфункции, подфункции – на задачи и т. д. до конкретных процедур СУЩНОСТЬ СТРУКТУРНОГО ПОДХОДА К МОДЕЛИРОВАНИЮ СИСТЕМ Система Функция 1 Функция 2 … Функция n Подфункция 2 … …Задача 2 …Подфункция 1 … Задача 1 …… Задача n … …Подфункция n …

ОСОБЕННОСТИ  - описывать любые системы, а не только информационные  - создать описаниеОСОБЕННОСТИ — описывать любые системы, а не только информационные — создать описание системы и ее внешнего окружения до определения окончательных требований к ней

4 ТИПА ДИАГРАММ  Контекстная диаграмма - вершина древовидной структуры диаграмм,  показывает назначение4 ТИПА ДИАГРАММ Контекстная диаграмма — вершина древовидной структуры диаграмм, показывает назначение системы (основную функцию) и ее взаимодействие с внешней средой. Диаграммы декомпозиции — функции делятся на подфункции и так до достижения требуемого уровня детализации исследуемой системы. Диаграмма дерева узлов показывает иерархическую зависимость функций (работ), но не связи между ними. Их может быть несколько, поскольку дерево можно построить на произвольную глубину и с произвольного узла. Диаграммы для экспозиции строятся для иллюстрации отдельных фрагментов модели с целью отображения альтернативной точки зрения на происходящие в системе процессы (например, с точки зрения руководства организации).

СИНТАКСИЧЕСКИЕ ПРАВИЛА СИНТАКСИЧЕСКИЕ ПРАВИЛА

 Олицетворяет некоторую конкретную функцию или работу в рамках рассматриваемой системы  РД IDEF Олицетворяет некоторую конкретную функцию или работу в рамках рассматриваемой системы РД IDEF 0 – 2000 : прямоугольник, содержащий имя и номер и используемый для описания функции ФУНКЦИОНАЛЬНЫЙ БЛОК Управлять предприятием А 0 управление вход выход механизм. Наименование осуществляется оборотом глагола или существительного Каждый блок в рамках единой системы имеет уникальный номер. Каждая сторона функционального блока имеет свое назначение

 Интерфейсная дуга отображает элемент системы,  который обрабатывается функциональным блоком или оказывает иное Интерфейсная дуга отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображаемую функциональным блоком. Графически изображается в виде однонаправленной стрелки. Каждая дуга должна иметь свое уникальное название , сформулированное оборотом существительного (должно отвечать на вопросы кто? , что? ). Примеры : информация, разработчик, документ, обработанная заявка. В зависимости от того, к какой стороне блока она подходит, интерфейсная дуга будет являться входящей, выходящей, управления, механизма. ИНТЕРФЕЙСНАЯ ДУГА

ИНТЕРФЕЙСНАЯ ДУГА Функциональный блок А 0 управление вход выход механизм Ресурсы, необходимые для проведенияИНТЕРФЕЙСНАЯ ДУГА Функциональный блок А 0 управление вход выход механизм Ресурсы, необходимые для проведения работы (человеческие ресурсы, оборудование, ИС). Ресурсы, перерабатываемые системой Регулирует работу системы, управляет (нормативная документация и т. п. ) Результат работы системы, переработанные ресурсы, продукт деятельности Стрелки входа может не быть. Остальные интерфейсные дуги обязательны.

 AS-IS  TO-BE  Should-BE AS-IS TO-BE Should-

 Точка зрения – позиция, с которой будет строиться модель. В качестве точки зрения Точка зрения – позиция, с которой будет строиться модель. В качестве точки зрения берется взгляд человека, который видит систему в нужном для моделирования аспекте. Как правило, выбирается точка зрения человека, ответственного за выполнение моделируемой работы. Между целью и точкой зрения должно быть жесткое соответствие. ТОЧКА ЗРЕНИЯ

ДЕКОМПОЗИЦИЯ А 0 Цель: Т. зрения: А-0 А 1 А 3 А 2 АДЕКОМПОЗИЦИЯ А 0 Цель: Т. зрения: А-0 А 1 А 3 А 2 А 0 А 11 А 13 А 12 А 1 А 33 А 32 А 3 Контекстная диаграмма Декомпозиция контекстной диаграммы Декомпозиция блока А 1 Декомпозиция блока А

ДЕКОМПОЗИЦИЯ А 0 А 1 А 2 А 3 А 11 А 12 АДЕКОМПОЗИЦИЯ А 0 А 1 А 2 А 3 А 11 А 12 А 13 А 0 ____________ А 11______ А 12______ А 13______ А 2______ А 3______ Дерево узлов Индекс узлов

НУМЕРАЦИЯ РАБОТ И ДИАГРАММ А 0 Цель: Т. зрения: А-0 А 1 А 3НУМЕРАЦИЯ РАБОТ И ДИАГРАММ А 0 Цель: Т. зрения: А-0 А 1 А 3 А 2 А 0 А 11 А 13 А 12 А 1 А 33 А 32 А 3 Номер контекстной диаграммы. Номер функционального блока на контекстной диаграмме Диаграммы декомпозиции имеют номер декомпозируемого блока. Формат номера блока: 1. Префикс 2. Номер родительской работы 3. Собственный порядковый номер

1. На одной диаграмме рекомендуется рисовать от 3 до 6 блоков. Иначе диаграмма будет1. На одной диаграмме рекомендуется рисовать от 3 до 6 блоков. Иначе диаграмма будет плохо читаемой. 2. Функциональные блоки должны располагаться слева направо сверху вниз в порядке доминирования. 3. Следует избегать излишнего пересечения стрелок. ОСНОВНЫЕ ПРАВИЛА ПОСТРОЕНИЯ ДИАГРАММ

4. Выход одного блока может являться входом (управлением) для другого. Могут быть и обратные4. Выход одного блока может являться входом (управлением) для другого. Могут быть и обратные связи по входу и управлению. ОСНОВНЫЕ ПРАВИЛА ПОСТРОЕНИЯ ДИАГРАММ Связь по входу Связь по управлению

ОСНОВНЫЕ ПРАВИЛА ПОСТРОЕНИЯ ДИА ГРА ММ а) обратная связь по входу б) обратная связьОСНОВНЫЕ ПРАВИЛА ПОСТРОЕНИЯ ДИА ГРА ММ а) обратная связь по входу б) обратная связь по управлению Обратная связь по входу , как правило, используется для описания циклов. Обратная связь по управлению – выход нижестоящей работы передается на управление вышестоящей Обратная связь по механизму – выход нижестоящей работы создает ресурсы, выполняющие вышестоящую работу в) обратная связь по механизму

5. Стрелки могут быть сливающимися и разветвляющимися ОСНОВНЫЕ ПРАВИЛА ПОСТРОЕНИЯ ДИАГРАММ Слияние стрелок Разветвление5. Стрелки могут быть сливающимися и разветвляющимися ОСНОВНЫЕ ПРАВИЛА ПОСТРОЕНИЯ ДИАГРАММ Слияние стрелок Разветвление стрелок

Стрелки на контекстной диаграмме служат для описания взаимодействия системы с окружающим миром. Они могутСтрелки на контекстной диаграмме служат для описания взаимодействия системы с окружающим миром. Они могут начинаться у границы диаграммы и заканчиваться у функционального блока и наоборот. Такие стрелки называются граничными [8]. Граничные стрелки помечаются с помощью ICOM-меток (Input, Control, Output, Mechanism) ГРАНИЧНЫЕ СТРЕЛКИ I 1 I 2 M 1 C 1 O 2 ICOM-метки

Иногда необходимо отобразить граничные стрелки,  которые значимы на данном уровне и не значимыИногда необходимо отобразить граничные стрелки, которые значимы на данном уровне и не значимы на родительской диаграмме. Например, некоторые данные используются только на данном уровне используются на других. Без использования механизма тоннелирования малозначимая стрелка появится на всех уровнях модели, что затруднит чтение диаграмм. ТОННЕЛЬНЫЕ СТРЕЛКИ

 Для каждого из элементов в IDEF 0 существует стандарт, подразумевающий создание и поддержку Для каждого из элементов в IDEF 0 существует стандарт, подразумевающий создание и поддержку набора соответствующих определений, ключевых слов, повествований, изложений и т. д, которые характеризуют объект, отраженный данным элементом. Этот набор – глоссарий , являющийся описанием сущности данного элемента. FEO-диаграмма ( For Exposition Only ) – это диаграмма, которая поясняет особо интересные и тонкие аспекты диаграмм. Эти диаграммы не ограничены синтаксисом IDEF 0. В них может быть текстовая, графическая информация, схемы, альтернативная точка зрения на процесс и т. п. ГЛОССАРИЙ И FEO-СТРАНИЦА

 Стандартный бланк для диаграмм (облегчает подшивку и копирование) Разделен на 3 основные части: Стандартный бланк для диаграмм (облегчает подшивку и копирование) Разделен на 3 основные части: 1) поле рабочей информации (для отслеживания диаграммы в процессе моделирования) 2) поле сообщений (область рисования диаграммы) 3) поле идентификации (идентификация диаграммы и ее позиционирование в иерархии)МАСТЕРСКАЯ СТРАНИЦА (КАРКАС ДИАГРАММЫ)

МАСТЕРСКАЯ СТРАНИЦАUSED AT : AUTHOR:  FIODATE: REV: PROJECT:  model 1 27. 02.МАСТЕРСКАЯ СТРАНИЦАUSED AT : AUTHOR: FIODATE: REV: PROJECT: model 1 27. 02. 2009 NO TES: 1 2 3 4 5 6 7 8 9 10 WO RKING DRAFT RECOMMENDED PUBLICATION READERDATECO NTEXT: TOP NO DE: TIT LE: NUMBER: A-0 Поле сообщений Поле идентификации. Поле рабочей информации Статусы проекта : 1) Рабочая версия – диаграмма с большим числом изменений на стадии разработки 2) Эскиз имеет меньше изменений и свидетельствует о достижении некоторого согласия ряда читателей 3) Рекомендовано – сопутствующие тексты утверждены 4) Публикация – материал может печататься. Сведения о модели : -автор; -название проекта; -замечания; -дата создания и пересмотра. Сведения о читателях-экспе ртах и дате экспертизы Сведения о родительской работе Название диаграммы (совпадает с названием родительской работы)Номер диаграммы Уникальный номер версии диаграммы

ПРИМ Е Р М О ДЕ ЛИ ПР О ЦЕ С С А ПРИМ Е Р М О ДЕ ЛИ ПР О ЦЕ С С А ПО С Т РО ЙКИ С АДО В О Г О ДО МИКА Построить дом. Материалы Строители Дом. Проект дома Цель: Определить действия, необходимые для постройки дачного домика Точка зрения: владельца дачного участка 1. Строим контекстную диаграмму.

П Р И М Е Р  М О Д Е Л И П Р И М Е Р М О Д Е Л И П Р О Ц Е С С А П О С Т Р О Й К И С А Д О В О Г О Д О М И К А 2. Декомпозируем контекстную диаграмму Заложить фундамент Возвести стены Положить крышу Выполнить отделку. Материалы Проект дома Строители Дом Каменщики Плотники Кровельщики Мастера по отделке. Фундамент Стены Крыша

ПРИМЕР МОДЕЛИ,  ПОСТРОЕННОЙ С ИСПОЛЬЗ ОВАНИЕМ CAS E-СРЕДСТВА ERWI N USED AT: AUПРИМЕР МОДЕЛИ, ПОСТРОЕННОЙ С ИСПОЛЬЗ ОВАНИЕМ CAS E-СРЕДСТВА ERWI N USED AT: AU TH OR : Ш илина М. А. DATE: REV: PR OJ ECT: П остройка дома 27. 02. 2009 NOTES: 1 2 3 4 5 6 7 8 9 10 W ORKIN G DR AF T RECOMMEN DED PU BLICATION READ ER DATE CONTEXT: TOP NODE: TI TLE: NU MBER : П остро ить дом A-0 Материалы Д ом. Проект дома Строители A 0 Построить дом Цель: определить дейс тв ия, необх одимые для постройки дачного домика Точка зрения: Владельца дачного у частка

П Р И М Е Р  М О Д Е Л И ,П Р И М Е Р М О Д Е Л И , П О С Т Р О Е Н Н О Й С И С П О Л Ь З О В А Н И Е М C A S E — С Р Е Д С Т В А E R W I N USED AT: AU TH OR : Ш илина М. А. DATE: REV: PR OJ EC T: П ос тройка дома 27. 02. 2009 10. 03. 2010 NOTES: 1 2 3 4 5 6 7 8 9 10 W OR KIN G DR AF T RECOMMEN DED PU BLICATION READ ER DATE CONTEXT: A-0 NODE: TI TLE: NU MBER : П остро ить дом A 0 Проект дома Строители. Материалы Д ом. Фу ндамент Стены Крыша. A 1 Заложить фу ндамент A 2 Возв ести стены A 3 Положить крышу A 4 Выполнить отделочные работы. I 1 O 1 M 1 C 1 Каменщики Плотники Кров ельщики Мастера по отделке

ДЕРЕВО УЗЛОВ USED AT: AU TH OR :  Ш илина М. А. DATE:ДЕРЕВО УЗЛОВ USED AT: AU TH OR : Ш илина М. А. DATE: REV: PR OJ ECT: П остройка дома 27. 02. 2009 NOTES: 1 2 3 4 5 6 7 8 9 10 W ORKIN G DR AF T RECOMMEN DED PU BLICATION READ ER DATE CONTEXT: A-0 TOP NODE: TI TLE: NU MBER : П остро ить дом A 0 A 0 Построить дом A 1 Заложить фу ндамент A 2 Возв ести стены A 3 Положить крышу A 4 Выполнить отделочные работы

FEO -СТРАНИЦА USED AT: AU TH OR :  Ш илина М. А. DATE:FEO -СТРАНИЦА USED AT: AU TH OR : Ш илина М. А. DATE: REV: PR OJ ECT: П остройка дома 27. 02. 2009 NOTES: 1 2 3 4 5 6 7 8 9 10 W ORKIN G DR AF T RECOMMEN DED PU BLICATION READ ER DATE CONTEXT: A-0 NODE: TI TLE: NU MBER : П остро ить дом A 0 F Проект дома Строители. Материалы Д ом. Фу ндамент Стены Крыша. A 0. 1 Заложить фу ндамент A 0. 2 Возв ести стены A 0. 3 Положить крышу A 0. 4 Выполнить отделочные работы Каменщики Плотники Кров ельщики Мастера по отделке

5 ВИДОВ СТРЕЛОК  - вход (англ. input) – материал или информация, которые используются5 ВИДОВ СТРЕЛОК — вход (англ. input) – материал или информация, которые используются и преобразуются работой для получения результата (выхода). Вход отвечает на вопрос «Что подлежит обработке? » . В качестве входа может быть как материальный объект (сырье, деталь, экзаменационный билет), так и не имеющий четких физических контуров (запрос к БД, вопрос преподавателя). Допускается, что работа может не иметь ни одной стрелки входа. Стрелки входа всегда рисуются входящими в левую грань работы; — управление (англ. control) – управляющие, регламентирующие и нормативные данные, которыми руководствуется работа. Управление отвечает на вопрос «В соответствии с чем выполняется работа? » . Управление влияет на работу, но не преобразуется ей, т. е. выступает в качестве ограничения. В качестве управления могут быть правила, стандарты, нормативы, расценки, устные указания. Стрелки управления рисуются входящими в верхнюю грань работы. Если при построении диаграммы возникает вопрос, как правильно нарисовать стрелку сверху или слева, то рекомендуется ее рисовать как вход (стрелка слева); — выход (англ. output) – материал или информация, которые представляют результат выполнения работы. Выход отвечает на вопрос «Что является результатом работы? » . В качестве выхода может быть как материальный объект (деталь, автомобиль, платежные документы, ведомость), так и нематериальный (выборка данных из БД, ответ на вопрос, устное указание). Стрелки выхода рисуются исходящими из правой грани работы; — механизм (англ. mechanism) – ресурсы, которые выполняют работу. Механизм отвечает на вопрос «Кто выполняет работу или посредством чего? » . В качестве механизма могут быть персонал предприятия, студент, станок, оборудование, программа. Стрелки механизма рисуются входящими в нижнюю грань работы; — вызов (англ. call) – стрелка указывает, что некоторая часть работы выполняется за пределами рассматриваемого блока. Стрелки выхода рисуются исходящими из нижней грани работы.

ТИПЫ СВЯЗЕЙ МЕЖДУ РАБОТАМИ ТИПЫ СВЯЗЕЙ МЕЖДУ РАБОТАМИ

ИЕРАРХИЧЕСКАЯ СВЯЗЬ (СВЯЗЬ «ЧАСТЬ» –  «ЦЕЛОЕ» )  имеет место между функцией иИЕРАРХИЧЕСКАЯ СВЯЗЬ (СВЯЗЬ «ЧАСТЬ» – «ЦЕЛОЕ» ) имеет место между функцией и подфункциями, из которых она состоит.

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

ФУНКЦИОНАЛЬНАЯ (ТЕХНОЛОГИЧЕСКАЯ) СВЯЗЬ  имеет место, когда выход одной функции служит входными данными дляФУНКЦИОНАЛЬНАЯ (ТЕХНОЛОГИЧЕСКАЯ) СВЯЗЬ имеет место, когда выход одной функции служит входными данными для следующей функции. С точки зрения потока материальных объектов данная связь показывает технологию (последовательность работ) обработки этих объектов. Различают прямую связь по входу , когда выход передается с вышестоящей работы на нижестоящую обратную связь по входу , когда выход передается с нижестоящей к вышестоящей

ПОТРЕБИТЕЛЬСКАЯ СВЯЗЬ  имеет место, когда выход одной функции служит механизмом для следующей функции.ПОТРЕБИТЕЛЬСКАЯ СВЯЗЬ имеет место, когда выход одной функции служит механизмом для следующей функции. Таким образом, одна функция потребляет ресурсы, вырабатываемые другой.

ЛОГИЧЕСКАЯ СВЯЗЬ  наблюдается между логически однородными функциями. Такие функции,  как правило, выполняютЛОГИЧЕСКАЯ СВЯЗЬ наблюдается между логически однородными функциями. Такие функции, как правило, выполняют одну и ту же работу, но разными (альтернативными) способами или, используя разные исходные данные (материалы).

КОЛЛЕГИАЛЬНАЯ (МЕТОДИЧЕСКАЯ) СВЯЗЬ  имеет место между функциями,  алгоритм работы которых определяется однимКОЛЛЕГИАЛЬНАЯ (МЕТОДИЧЕСКАЯ) СВЯЗЬ имеет место между функциями, алгоритм работы которых определяется одним и тем же управлением. Аналогом такой связи является совместная работа сотрудников одного отдела (коллег), подчиняющихся начальнику, который отдает указания и приказы (управляющие сигналы). Такая связь также возникает, когда алгоритмы работы этих функций определяются одним и тем же методическим обеспечением (СНИП, ГОСТ, официальными нормативными материалами и т. д. ), служащим в качестве управления.

РЕСУРСНАЯ СВЯЗЬ  возникает между функциями,  использующими для своей работы одни и теРЕСУРСНАЯ СВЯЗЬ возникает между функциями, использующими для своей работы одни и те же ресурсы. Ресурсно-зависимые функции, как правило, не могут выполняться одновременно.

ИНФОРМАЦИОННАЯ СВЯЗЬ  имеет место между функциями, использующими в качестве входных данных одну иИНФОРМАЦИОННАЯ СВЯЗЬ имеет место между функциями, использующими в качестве входных данных одну и ту же информацию.

ВРЕМЕННАЯ СВЯЗЬ  возникает между функциями,  которые должны выполняться одновременно до или одновременноВРЕМЕННАЯ СВЯЗЬ возникает между функциями, которые должны выполняться одновременно до или одновременно после другой функции. Эта связь имеет место также между другими сочетаниями управления, входа и механизма, поступающими в одну функцию.

СЛУЧАЙНАЯ СВЯЗЬ  возникает, когда конкретная связь между функциями мала или полностью отсутствует СЛУЧАЙНАЯ СВЯЗЬ возникает, когда конкретная связь между функциями мала или полностью отсутствует

ICOM-КОДЫ  ICOM-коды (аббревиатура от Input, Control, Output и Mechanism) предназначены для идентификации граничныхICOM-КОДЫ ICOM-коды (аббревиатура от Input, Control, Output и Mechanism) предназначены для идентификации граничных стрелок. ICOM-код содержит префикс, соответствующий типу стрелки (I, С, О или М), и порядковый номер