Инжиниринг ИС

1. Инжиниринг ИС

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

2. Проектирование

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

3. Информационные технлогии

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

4. Информация и данные

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

5. Автоматизированная информационная система

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

6. Процесс разработки программного обеспечения

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

7. Категории стандартов

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

8. Стандарты ISO/IEC (ИСО/МЭК) в области разработки и документирования программных средств

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

9. Комплекс нормативных документов на автоматизированные системы

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

10. Комплекс стандартов Единой системы программной документации (ЕСПД)

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

11. Комплекс отраслевых руководящих методических материалов (информационные системы на железнодорожном транспорте (ОРММ ИСЖТ))

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

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

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

13.

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

14. вспомогательные процессы

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

15. организационные

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

16. Стадии жизненного цикла информационной системы

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

17. Классический ЖЦ и ИСО / МЭК 12207

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

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

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

19. Каскадная модель

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

20. Водопадная (каскадная, последовательная) модель v2

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

21.

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

22. Поэтапная модель с промежуточным контролем

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

23. Инкрементная (итерационная) модель

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

24. Спиральная модель

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

25. Спиральная модель v2

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

26.

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

27. Методологии, поддерживающие спиральную модель

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

28. Методология RAD. Элементы

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

29. Методология RAD. Использование

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

30. Условия применения методологии RAD

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

31. Методология XP. Особенности

V-MODEL

32. V-Model

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

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

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

34. ЛР

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

35. особенности

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

36. Основные документы с требованиями к системе

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

37. Разделы ТЗ

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

38. виды обеспечения

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

39.

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

40. может включать приложения

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

41. Основные принципы проектирования

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

42. Общие принципы

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

43.

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

44. Классификация моделей информационной системы По строгости описания

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

45. По степени физической реализации (логической независимости)

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

46. По степени отображения динамики происходящих процессов

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

47. По отображаемому аспекту

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

48. CASE-технологии анализа и проектирования

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

49. CASE-технология

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

50.

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

51.

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

52. цель использования CASE-технологий

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

53. Структурный подход

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

54.

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

55. Методологии структурного анализа и проектирования

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

56. Предварительные действия

57.

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

58.

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

59.

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

60. Таблица ролей

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

61. Основы функционального анализа и проектирования систем

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

62. Проблемы

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

63. AS-IS (как есть)

IDEF0

64. TO-BE (как будет)

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

65.  SHOULD-BE (как должно было быть).

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

66. IDEF0

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

67. Сущность структурного подхода к моделированию систем

68. особенности

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

69. 4 типа диаграмм

70.

71. Синтаксические правила

72.

73.

74.

75.

76.

77.

78.

79.

80.

81.

82.

83.

84.

85.

86.

87.

88.

89.

90.

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

91.

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

92.

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

93. Функциональный блок

AS-IS
TO-BE
Should-BE

94. Интерфейсная дуга

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

95. Интерфейсная дуга

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

96.

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

97. Точка зрения

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

98. Декомпозиция

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

99. Декомпозиция

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

100. Нумерация работ и диаграмм

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

101. Основные правила построения диаграмм

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

102. Основные правила построения диаграмм

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

103. Основные правила построения диаграмм

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

104. Основные правила построения диаграмм

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

105. Граничные стрелки

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

106. Тоннельные стрелки

МАСТЕРСКАЯ СТРАНИЦА
USED AT:
AUTHOR: FIO
DATE: 27. 02.2009
WORKING
PROJECT: model1
REV:
DRAFT
27. 02.2009
READER
DATE CONTEXT:
TOP
RECOMMENDED
NOTES: 1 2 3 4 5 6 7 8 9 10
PUBLICATION
Поле рабочей информации
Статусы проекта:
Сведения оСведения о
родительской
1) Рабочая версия –читателяхдиаграмма
с
работе
большим числом изменений
стадии
экспертахна
и дате
Сведения о модели:
разработки
экспертизы
-автор;
2) Эскиз имеет меньше изменений и
свидетельствует о достижении
-название проекта;
некоторого согласия ряда читателей
Поле
сообщений
-замечания;
3) Рекомендовано – сопутствующие
тексты утверждены
-дата создания и пересмотра.
4) Публикация – материал может
печататься.
Номер
диаграммы
Название диаграммы
(совпадает с названием
родительской работы)
Поле идентификации
NODE:
TITLE:
A-0
Уникальный
номер версии
диаграммы
NUMBER:

107. Глоссарий и FEO-страница

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

108. Мастерская страница (каркас диаграммы)

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

109. Мастерская страница

ПРИМЕР МОДЕЛИ, ПОСТРОЕННОЙ С
ИСПОЛЬЗОВАНИЕМ CASE-СРЕДСТВА ERWIN
USED AT: AUTHOR: Шилина М.А.
PROJECT: Постройка дома
DATE: 27.02.2009
REV: 27.02.2009
WORKING
DRAFT
RECOMMENDED
PUBLICATION
NOTES: 1 2 3 4 5 6 7 8 9 10
READER
DATE CONTEXT:
TOP
Проект дома
Материалы
Дом
Построить
дом
A0
Цель: определить действ ия, необходимые
для постройки дачного домика
Строители
Точка зрения: Владельца дачного у частка
NODE:
TITLE:
A-0
Построить дом
NUMBER:

110. Пример модели процесса постройки садового домика

ПРИМЕР МОДЕЛИ, ПОСТРОЕННОЙ С
ИСПОЛЬЗОВАНИЕМ CASE-СРЕДСТВА ERWIN
USED AT: AUTHOR: Шилина М.А.
PROJECT: Постройка дома
DATE: 27.02.2009
REV: 10.03.2010
WORKING
DRAFT
RECOMMENDED
PUBLICATION
C1
Проект дома
NOTES: 1 2 3 4 5 6 7 8 9 10
Материалы
I1
Заложить
фу ндамент
A1
READER
DATE CONTEXT:
A-0
Фу ндамент
Возв ести
стены
Стены
A2
Положить
крышу
Крыша
A3
Выполнить
отделочные
работы
A4
Каменщики
Кров ельщики
Плотники
M1
NODE:
TITLE:
A0
Мастера
по отделке
Строители
Построить дом
NUMBER:
Дом
O1

111. Пример модели процесса постройки садового домика

ДЕРЕВО УЗЛОВ
USED AT: AUTHOR: Шилина М.А.
PROJECT: Постройка дома
DATE: 27.02.2009
REV: 27.02.2009
NOTES: 1 2 3 4 5 6 7 8 9 10
WORKING
DRAFT
RECOMMENDED
PUBLICATION
READER
DATE CONTEXT:
TOP
A-0
Построить
дом
A0
Заложить
фу ндамент
Возв ести
стены
A1
A2
NODE:
Положить
крышу
TITLE:
A0
A3
Выполнить
отделочные
работы
A4
Построить дом
NUMBER:

112. Пример модели, построенной с использованием CASE-средства ErWin

FEO-СТРАНИЦА
USED AT: AUTHOR: Шилина М.А.
PROJECT: Постройка дома
DATE: 27.02.2009
REV: 27.02.2009
NOTES: 1 2 3 4 5 6 7 8 9 10
WORKING
DRAFT
RECOMMENDED
PUBLICATION
READER
DATE CONTEXT:
A-0
Проект дома
Материалы
Фу ндамент
Заложить
фу ндамент
A0.1
Стены
Возв ести
стены
A0.2
Положить
крышу
A0.3
Крыша
Выполнить
отделочные
работы
A0.4
Каменщики
Плотники
Кров ельщики
Мастера
по отделке
Строители
NODE:
TITLE:
A0F
Построить дом
NUMBER:
Дом

113. Пример модели, построенной с использованием CASE-средства ERWin

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

114. Дерево узлов

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

115. FEO-страница

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

116. 5 видов стрелок

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

117. Типы связей между работами

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

118. Иерархическая связь (связь «часть» – «целое»)

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

119.

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

120. Функциональная (технологическая) связь

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

121. Потребительская связь 

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

122. Логическая связь

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

123. Коллегиальная (методическая) связь

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

124. Ресурсная связь

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

125. Информационная связь

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