ПРОЕКТИРОВАНИЕ ИС 2016 01 ИНФОРМАЦИОННЫЕ ТЕХНЛОГИИ

ПРОЕКТИРОВАНИЕ ИС 2016 01

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

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

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

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

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

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

КОМПЛЕКС СТАНДАРТОВ ЕДИНОЙ СИСТЕМЫ ПРОГРАММНОЙ ДОКУМЕНТАЦИИ (ЕСПД) ГОСТ 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 Системный анализ Заказ Анализ требований Разработка Проектирование Кодирование (реализация) Тестирование Внедрение и сопровождение Поставка и эксплуатация Сопровождение и эксплуатация

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

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

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

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

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

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

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

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

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

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

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

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

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

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

V-MODEL

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

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

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

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

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

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

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

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

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

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

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

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

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

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

CASE-ТЕХНОЛОГИИ АНАЛИЗА И ПРОЕКТИРОВАНИЯ

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

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

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

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

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

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

МЕТОДОЛОГИИ СТРУКТУРНОГО АНАЛИЗА И ПРОЕКТИРОВАНИЯ Методология Тип разрабатываемой модели 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 (КАК ЕСТЬ) На основе должностных инструкций, приказов, отчетов, нормативной документации Анализ модели позволяет понять, где находятся слабые места, в чем будут состоять преимущества новых процессов и насколько глубоким изменениям подвергнется существующая организация деятельности предприятия (компании, отдела). Признаки неэффективной организации деятельности: - бесполезные, неуправляемые и дублирующие работы; - работы без результата; - неэффективный документооборот (нужный документ не оказывается в нужное время в нужном месте)

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

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

IDEF 0

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

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

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

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

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

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

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

AS-IS TO-BE Should-BE

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

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

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

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

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

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

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

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

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

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

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

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

МАСТЕРСКАЯ СТРАНИЦА Поле рабочей информации Сведения о Статусы проекта: Сведения о родительской 1) Рабочая версия – диаграмма с читателяхработе большим числом изменений на стадии экспертах и дате Сведения о модели: разработки экспертизы -автор; 2) Эскиз имеет меньше изменений и свидетельствует о достижении -название проекта; некоторого согласия ряда читателей Поле сообщений -замечания; 3) Рекомендовано – сопутствующие тексты утверждены -дата создания и пересмотра. 4) Публикация – материал может печататься. Номер диаграммы Название диаграммы (совпадает с названием родительской работы) Поле идентификации Уникальный номер версии диаграммы

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

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

ПРИМЕР МОДЕЛИ, ПОСТРОЕННОЙ С ИСПОЛЬЗОВАНИЕМ CASE -СРЕДСТВА ERWIN

ПРИМЕР МОДЕЛИ, ПОСТРОЕННОЙ С ИСПОЛЬЗОВАНИЕМ CASE -СРЕДСТВА ERWIN

ДЕРЕВО УЗЛОВ

FEO- СТРАНИЦА

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

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

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

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

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

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

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

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

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

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

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

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

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