Разделы презентаций

1 1 Современные технологии разработки ПО Методология и технология

Содержание

Литература:Смирнова Г.Н. Проектирование экономических информационных систем: учебник/Г.Н.Смирнова, А.А.Сорокин, Ю.Ф Тельнов под ред. Ю.Ф.Тельнова. – М.: Финансы и статистика, 2003Грекул В.И. Проектирование информационных систем: Курс лекций. Учебное пособие / В.И.Грекул, Г.Н.Денищенко, Н.Л.Коровкина.

Слайды и текст этой презентации

Слайд 1

Современные технологии разработки ПО
Методология и технология проектирования информационных систем



доцент кафедры


Веремьев Виктор Леонтьевич, к.т.н., с.н.с.
E-mail: veremyev.victor@gmail.com
моб.т. +7(911)089-04-56

Современные технологии разработки ПОМетодология и технология проектирования информационных системдоцент кафедры Веремьев Виктор Леонтьевич, к.т.н., с.н.с.E-mail: veremyev.victor@gmail.comмоб.т. +7(911)089-04-56

Слайд 2Литература:

Смирнова Г.Н. Проектирование экономических информационных систем: учебник/Г.Н.Смирнова, А.А.Сорокин, Ю.Ф Тельнов

под ред. Ю.Ф.Тельнова. – М.: Финансы и статистика, 2003
Грекул В.И.

Проектирование информационных систем: Курс лекций. Учебное пособие / В.И.Грекул, Г.Н.Денищенко, Н.Л.Коровкина. – М.: Интернет-университет информационных технологий, 2005
Гвоздева Т.В. Проектирование информационных систем: Учебное пособие. / Т.В.Гвоздева, Б.А.Баллод. – Ростов-на-Дону, Феникс, 2009
Ипатова Э.Р. Методологии и технологии системного проектирования информационных систем: Учебник. /Э.Р.Ипатова, Ю.В.Ипатов – М.: МПСИ, Флинта, 2008
Вендров А. М. Проектирование программного обеспечения экономических информационных систем: Учебник. – М.: Финансы и статистика, 2005
Маклаков С. В. Создание информационных систем с AllFusionModelingSuite. – М.: Диалог-МИФИ, 2005
Йордан Э. Объектно-ориентированный анализ и проектирование систем. / Э.Йордан, К.Аргила. – М.: Лори, 2007



Литература:Смирнова Г.Н. Проектирование экономических информационных систем: учебник/Г.Н.Смирнова, А.А.Сорокин, Ю.Ф Тельнов под ред. Ю.Ф.Тельнова. – М.: Финансы и

Слайд 31. Ведение

1. Ведение

Слайд 4Класcификация информационных систем

Класcификация информационных систем

Слайд 5Основные функции ИС организационного управления
оперативный контроль и регулирование,

оперативный учет

и анализ,

перспективное и оперативное планирование,

бухгалтерский учет,

управление сбытом,



управление снабжением и др.

Основные функции ИС организационного управленияоперативный контроль и регулирование, оперативный учет и анализ, перспективное и оперативное планирование,

Слайд 6Основные функции систем автоматизированного проектирования (САПР)
инженерные расчеты,

создание графической документации

(чертежей, схем, планов),

создание проектной документации, моделирование проектируемых объектов.


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

Слайд 7Функциональное назначение модулей корпоративной ИС

Функциональное назначение модулей корпоративной ИС

Слайд 8Классификация рынка информационных систем

Классификация рынка информационных систем

Слайд 9 Состав системы Галактика

Состав системы Галактика

Слайд 10Компоненты архитектуры организации

Компоненты архитектуры организации

Слайд 11Типовые архитектуры ИС

Лоскутная автоматизация
Настольные ИС
Централизованные
Распределенные корпоративные
Терминальные
Клиент-серверные
2-х уровневые
3-х трехуровневые
На базе Intranet
Распределенные

региональные
Выделенные телекоммуникационные каналы
На базе Internet

Типовые архитектуры ИСЛоскутная автоматизацияНастольные ИСЦентрализованныеРаспределенные корпоративныеТерминальныеКлиент-серверные2-х уровневые3-х трехуровневыеНа базе IntranetРаспределенные региональные Выделенные телекоммуникационные каналыНа базе Internet

Слайд 12Общая структура СУЗ

Общая структура СУЗ

Слайд 13Подходы к проектированию ИС
метод «снизу-вверх»
метод «сверху-вниз»

Из 8380 проектов, обследованных в

США в 1994 году, неудачными оказались более 30% проектов, общая

стоимость которых превышала 80 миллиардов долларов. При этом оказались выполненными в срок лишь 16% от общего числа проектов, а перерасход средств составил 189% от запланированного бюджета.

Подходы к проектированию ИСметод «снизу-вверх»метод «сверху-вниз» Из 8380 проектов, обследованных в США в 1994 году, неудачными оказались более

Слайд 14Задачи методологии проектирования корпоративных ИС
Обеспечивать создание корпоративных ИС, отвечающих целям

и задачам организации, а также предъявляемым требованиям по автоматизации деловых

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

Задачи методологии проектирования корпоративных ИСОбеспечивать создание корпоративных ИС, отвечающих целям и задачам организации, а также предъявляемым

Слайд 15 Внедрение методологии должно приводить к снижению сложности процесса создания ИС

за счет полного и точного описания этого процесса, а также

применения современных методов и технологий создания ИС на всем жизненном цикле ИС - от замысла до реализации.
Внедрение методологии должно приводить к снижению сложности процесса создания ИС за счет полного и точного описания этого

Слайд 16Проектирование ИС охватывает три основные области:
проектирование объектов данных, которые будут

реализованы в базе данных;

проектирование программ, экранных форм, отчетов, которые будут

обеспечивать выполнение запросов к данным;

учет конкретной среды или технологии, а именно: топологии сети, конфигурации аппаратных средств, используемой архитектуры (файл-сервер или клиент-сервер), параллельной обработки, распределенной обработки данных и т.п.
Проектирование ИС охватывает три основные области:проектирование объектов данных, которые будут реализованы в базе данных;проектирование программ, экранных форм,

Слайд 17Проектирование ИС должно обеспечить
требуемые функциональность системы и уровень ее адаптивности

к изменяющимся условиям функционирования;

требуемую пропускную способности системы;

требуемое временя реакции системы

на запрос;

безотказность работы системы;

необходимый уровня безопасности;

простоту эксплуатации и поддержки системы.

Проектирование ИС должно обеспечитьтребуемые функциональность системы и уровень ее адаптивности к изменяющимся условиям функционирования;требуемую пропускную способности системы;требуемое

Слайд 18 Согласно современной методологии, процесс создания ИС представляет собой процесс построения

и последовательного преобразования ряда согласованных моделей на всех этапах жизненного

цикла (ЖЦ) ИС.
Согласно современной методологии, процесс создания ИС представляет собой процесс построения и последовательного преобразования ряда согласованных моделей на

Слайд 19Этапы создания ИС
формирование требований к системе,

проектирование,

реализация,

тестирование,

ввод

в действие,

эксплуатация и сопровождение.

Этапы создания ИСформирование требований к системе, проектирование, реализация, тестирование, ввод в действие, эксплуатация и сопровождение.

Слайд 20Результаты этапа проектирования
схема базы данных (на основании ER-модели, разработанной на

этапе анализа);

набор спецификаций модулей системы (они строятся на базе моделей

функций).
Результаты этапа проектированиясхема базы данных (на основании ER-модели, разработанной на этапе анализа);набор спецификаций модулей системы (они строятся

Слайд 21Выбор характеристик архитектуры
будет ли это 3-уровневая архитектура со следующими слоями:

сервер, ПО промежуточного слоя (сервер приложений), клиентское ПО;
будет ли база

данных централизованной или распределенной. Если база данных будет распределенной, то какие механизмы поддержки согласованности и актуальности данных будут использоваться;
будет ли база данных однородной, то есть, будут ли все серверы баз данных продуктами одного и того же производителя (например, все серверы только Oracle или все серверы только DB2 UDB). Если база данных не будет однородной, то какое ПО будет использовано для обмена данными между СУБД разных производителей (уже существующее или разработанное специально как часть проекта);
будут ли для достижения должной производительности использоваться параллельные серверы баз данных (например, Oracle Parallel Server, DB2 UDB.
Выбор характеристик архитектурыбудет ли это 3-уровневая архитектура со следующими слоями: сервер, ПО промежуточного слоя (сервер приложений), клиентское

Слайд 22Тесты разработанного модуля
автономный тест, который преследует две основные цели:
обнаружение отказов

модуля (жестких сбоев);
соответствие модуля спецификации (наличие всех необходимых функций, отсутствие

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


Тесты разработанного модуляавтономный тест, который преследует две основные цели:обнаружение отказов модуля (жестких сбоев);соответствие модуля спецификации (наличие всех

Слайд 23 Необходимость контролировать процесс создания ИС, гарантировать достижение целей разработки и

соблюдение различных ограничений (бюджетных, временных и пр.) привело к широкому

использованию в этой сфере методов и средств программной инженерии: структурного анализа, объектно-ориентированного моделирования, CASE-систем.

Необходимость контролировать процесс создания ИС, гарантировать достижение целей разработки и соблюдение различных ограничений (бюджетных, временных и пр.)

Слайд 24 2. Жизненный цикл программного обеспечения ИС

2. Жизненный цикл программного обеспечения ИС

Слайд 25Каскадная модель ЖЦ ИС

Каскадная модель ЖЦ ИС

Слайд 26Каскадная модель
предусматривает последовательное выполнение всех этапов проекта в строго фиксированном

порядке. Переход на следующий этап означает полное завершение работ на

предыдущем этапе.
Каскадная модельпредусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное

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

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

Слайд 28Поэтапная модель с промежуточным контролем
Разработка ИС ведется итерациями с циклами

обратной связи между этапами. Межэтапные корректировки позволяют учитывать реально существующее

взаимовлияние результатов разработки на различных этапах; время жизни каждого из этапов растягивается на весь период разработки.

Поэтапная модель с промежуточным контролемРазработка ИС ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют

Слайд 29Спиральная модель ЖЦ ИС

Спиральная модель ЖЦ ИС

Слайд 30Спиральная модель
На каждом витке спирали выполняется создание очередной версии продукта,

уточняются требования проекта, определяется его качество и планируются работы следующего

витка. Особое внимание уделяется начальным этапам разработки - анализу и проектированию, где реализуемость тех или иных технических решений проверяется и обосновывается посредством создания прототипов (макетирования).

Спиральная модельНа каждом витке спирали выполняется создание очередной версии продукта, уточняются требования проекта, определяется его качество и

Слайд 31 На практике наибольшее распространение получили две основные модели жизненного цикла:

каскадная

модель (характерна для периода 1970-1985 гг.);

спиральная модель (характерна для периода

после 1986.г.)
На практике наибольшее распространение получили две основные модели жизненного цикла:каскадная модель (характерна для периода 1970-1985 гг.);спиральная модель

Слайд 32Положительные стороны каскадного подхода
на каждом этапе формируется законченный набор проектной

документации, отвечающий критериям полноты и согласованности;

выполняемые в логической последовательности этапы

работ позволяют планировать сроки завершения всех работ и соответствующие затраты.

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

Слайд 33Стандарты проектирования ИС
ГОСТ 34.601-90 - распространяется на автоматизированные системы и

устанавливает стадии и этапы их создания. Кроме того, в стандарте

содержится описание содержания работ на каждом этапе. Стадии и этапы работы, закрепленные в стандарте, в большей степени соответствуют каскадной модели жизненного цикла.

ISO/IEC 12207:1995 - стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не содержит описания фаз, стадий и этапов.

Стандарты проектирования ИСГОСТ 34.601-90 - распространяется на автоматизированные системы и устанавливает стадии и этапы их создания. Кроме

Слайд 34Методики проектирования ИС
Custom Development Method (методика Oracle) по разработке прикладных

информационных систем - технологический материал, детализированный до уровня заготовок проектных

документов, рассчитанных на использование в проектах с применением Oracle. Применяется CDM для классической модели ЖЦ (предусмотрены все работы/задачи и этапы), а также для технологий "быстрой разработки" (Fast Track) или "облегченного подхода", рекомендуемых в случае малых проектов.

Методики проектирования ИС Custom Development Method (методика Oracle) по разработке прикладных информационных систем - технологический материал, детализированный

Слайд 35Методики проектирования ИС (продолжение)
Rational Unified Process (RUP) предлагает итеративную модель разработки,

включающую четыре фазы: начало, исследование, построение и внедрение. Каждая фаза

может быть разбита на этапы (итерации), в результате которых выпускается версия для внутреннего или внешнего использования. Прохождение через четыре основные фазы называется циклом разработки, каждый цикл завершается генерацией версии системы. Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова минует те же фазы. Суть работы в рамках RUP - это создание и сопровождение моделей на базе UML.
Методики проектирования ИС (продолжение)Rational Unified Process (RUP) предлагает итеративную модель разработки, включающую четыре фазы: начало, исследование, построение

Слайд 36Методики проектирования ИС (продолжение)
Microsoft Solution Framework (MSF) сходна с RUP, так

же включает четыре фазы: анализ, проектирование, разработка, стабилизация, является итерационной,

предполагает использование объектно-ориентированного моделирования. MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес-приложений.

Extreme Programming (XP). Экстремальное программирование (самая новая среди рассматриваемых методологий) сформировалось в 1996 году. В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС, а разработка ведется с использованием последовательно дорабатываемых прототипов.

Методики проектирования ИС (продолжение)Microsoft Solution Framework (MSF) сходна с RUP, так же включает четыре фазы: анализ, проектирование,

Слайд 37Стандарт ISO/IEC 12207:процессы ЖЦ ПО
Основные процессы:
приобретение;
поставка;
разработка;
эксплуатация;
сопровождение.
Вспомогательные процессы:
документирование;
управление конфигурацией;
обеспечение качества;
разрешение проблем;
аудит;
аттестация;
совместная

оценка;
Верификация.

Стандарт ISO/IEC 12207:процессы ЖЦ ПООсновные процессы:приобретение;поставка;разработка;эксплуатация;сопровождение.Вспомогательные процессы:документирование;управление конфигурацией;обеспечение качества;разрешение проблем;аудит;аттестация;совместная оценка;Верификация.

Слайд 38Стандарт ISO/IEC 12207:процессы ЖЦ ПО (продолжение)
Организационные процессы:
создание инфраструктуры;
управление;
обучение;
усовершенствование.

Стандарт ISO/IEC 12207:процессы ЖЦ ПО (продолжение)Организационные процессы:создание инфраструктуры;управление;обучение;усовершенствование.

Слайд 39Содержание основных процессов ЖЦ ПО ИС (ISO/IEC 12207)

Содержание основных процессов ЖЦ ПО ИС (ISO/IEC 12207)

Слайд 40Содержание основных процессов ЖЦ ПО ИС (ISO/IEC 12207) (продолжение)

Содержание основных процессов ЖЦ ПО ИС (ISO/IEC 12207) (продолжение)

Слайд 41Содержание основных процессов ЖЦ ПО ИС (ISO/IEC 12207, продолжение)

Содержание основных процессов ЖЦ ПО ИС (ISO/IEC 12207, продолжение)

Слайд 42 Позднее был разработан и в 2002 г. опубликован стандарт на

процессы жизненного цикла систем
(ISO/IEC 15288 System life cycle

processes).
Был учтен практический опыт создания систем в правительственных, коммерческих, военных и академических организациях. Стандарт применим для широкого класса систем, но его основное предназначение - поддержка создания компьютеризированных систем.
Позднее был разработан и в 2002 г. опубликован стандарт на процессы жизненного цикла систем (ISO/IEC 15288

Слайд 43Стадии создания систем (ISO/IEC 15288)

Стадии создания систем (ISO/IEC 15288)

Слайд 44Стандарт ISO/IEC серии 15288: группы процессов
Договорные процессы:
приобретение (внутренние решения или

решения внешнего поставщика);
поставка (внутренние решения или решения внешнего поставщика).

Процессы предприятия:
управление

окружающей средой предприятия;
инвестиционное управление;
управление ЖЦ ИС;
управление ресурсами;
управление качеством.

Стандарт ISO/IEC серии 15288: группы процессовДоговорные процессы:приобретение (внутренние решения или решения внешнего поставщика);поставка (внутренние решения или решения

Слайд 45Стандарт ISO/IEC серии 15288: группы процессов (продолжение)
Проектные процессы:
планирование проекта;
оценка проекта;
контроль

проекта;
управление рисками;
управление конфигурацией;
управление информационными потоками;
принятие решений.

Стандарт ISO/IEC серии 15288: группы процессов (продолжение)Проектные процессы:планирование проекта;оценка проекта;контроль проекта;управление рисками;управление конфигурацией;управление информационными потоками;принятие решений.

Слайд 46Стандарт ISO/IEC серии 15288: группы процессов (продолжение)
Технические процессы:
определение требований;
анализ требований;
разработка

архитектуры;
внедрение;
интеграция;
верификация;
переход;
аттестация;
эксплуатация;
сопровождение;
утилизация.

Специальные процессы:
определение и установка взаимосвязей исходя из задач и целей.

Стандарт ISO/IEC серии 15288: группы процессов (продолжение)Технические процессы:определение требований;анализ требований;разработка архитектуры;внедрение;интеграция;верификация;переход;аттестация;эксплуатация;сопровождение;утилизация.Специальные процессы:определение и установка взаимосвязей исходя из

Слайд 473. Организация разработки ИС

3. Организация разработки ИС

Слайд 48результаты исследований, выполненных в 1995 г. компанией Standish Group, которая

проанализировала работу 364 американских корпораций и итоги выполнения более 23

тыс. проектов, связанных с разра­боткой ПО, выглядели следующим образом:
только 16,2% завершились в срок, не превысили запланиро­ванный бюджет и реализовали все требуемые функции и возможности;
52,7% проектов завершились с опозданием, расходы превы­сили запланированный бюджет, требуемые функции не бы­ли реализованы в полном объеме;
31,1% проектов были аннулированы до завершения;
для двух последних категорий проектов бюджет среднего проекта оказался превышенным на 89%, а срок выполнения — на 122%.
В 1998 г. процентное соотношение трех перечисленных кате­горий проектов лишь немного изменилось в лучшую сторону (26%, 46% и 28% соответственно).

результаты исследований, выполненных в 1995 г. компанией Standish Group, которая проанализировала работу 364 американских корпораций и итоги

Слайд 49В числе причин возможных неудач, по мнению разработчи­ков, фигурируют:
нечеткая

и неполная формулировка требований к ПО;
недостаточное вовлечение пользователей в

работу над про­ектом;
отсутствие необходимых ресурсов;
неудовлетворительное планирование и отсутствие грамот­ного управления проектом;
частое изменение требований и спецификаций;
новизна и несовершенство используемой технологии;
недостаточная поддержка со стороны высшего руководства;
недостаточно высокая квалификация разработчиков, отсут­ствие необходимого опыта.

В числе причин возможных неудач, по мнению разработчи­ков, фигурируют: нечеткая и неполная формулировка требований к ПО; недостаточное

Слайд 50Программный продукт является частью среды приложений, пользователей, законов и компьютеров.

Все они непрерывно меняются, и их изменения неизбежно требуют изменения

программного продукта.

Программный продукт является частью среды приложений, пользователей, законов и компьютеров. Все они непрерывно меняются, и их изменения

Слайд 51специалис­ты в индустрии ПО пришли к пониманию, что фундаментальная проблема

в этой области — неспособность эффективного управ­ления проектами создания ПО.

Невозможно достичь удовлетво­рительных результатов от применения даже самых совершенных технологий и инструментальных средств, если они применяются бессистемно, разработчики не обладают необходимой квалифи­кацией для работы с ними, и сам проект выполняется и управля­ется хаотически, в режиме «тушения пожара».
В соответствии с моделью СММ (Capability Maturity Model) Инс­титута программной инженерии (Software Engineering Institute, SEI), в хорошо подготовленной (зрелой) организации персонал обладает технологией и инструментарием оценки качества про­цессов создания ПО на протяжении всего жизненного цикла ПО и на уровне всей организации.
специалис­ты в индустрии ПО пришли к пониманию, что фундаментальная проблема в этой области — неспособность эффективного управ­ления

Слайд 523.1 Каноническое проектирование ИС
Организация канонического проектирования ИС ориентирована на использование

главным образом каскадной модели жизненного цикла ИС.

Стадии и этапы

работы описаны в стандарте
ГОСТ 34.601-90.
3.1 Каноническое проектирование ИС Организация канонического проектирования ИС ориентирована на использование главным образом каскадной модели жизненного цикла

Слайд 53Стадии создания ИС
Формирование требований к ИС.
Разработка концепции ИС.
Техническое задание.
Эскизный

проект.
Технический проект.
Рабочая документация.
Ввод в действие.
Сопровождение ИС.

Стадии создания ИСФормирование требований к ИС.Разработка концепции ИС. Техническое задание.Эскизный проект.Технический проект.Рабочая документация.Ввод в действие. Сопровождение ИС.

Слайд 54Стадия 1. Формирование требований к ИС
На начальной стадии проектирования

выделяют следующие этапы работ:

обследование объекта и обоснование необходимости создания ИС;

формирование

требований пользователей к ИС;

оформление отчета о выполненной работе и тактико- технического задания на разработку.
Стадия 1. Формирование требований к ИС На начальной стадии проектирования выделяют следующие этапы работ:обследование объекта и

Слайд 55Технико-экономическое обоснование проекта
ограничения, риски, критические факторы, которые могут повлиять

на успешность проекта;
совокупность условий, при которых предполагается эксплуатировать будущую систему:

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

Технико-экономическое обоснование проекта ограничения, риски, критические факторы, которые могут повлиять на успешность проекта;совокупность условий, при которых

Слайд 56На этапе детального анализа деятельности должны быть выявлены:
инструктивно-методические и

директивные материалы, на основании которых определяются состав подсистем и перечень

задач;
возможности применения новых методов решения задач.

Аналитики собирают и фиксируют информацию в двух взаимосвязанных формах:
функции - информация о событиях и процессах, которые происходят в бизнесе;
сущности - информация о вещах, имеющих значение для организации и о которых что-то известно.

На этапе детального анализа деятельности должны быть выявлены: инструктивно-методические и директивные материалы, на основании которых определяются состав

Слайд 57При изучении каждой функциональной задачи управления определяются:
наименование задачи; сроки и

периодичность ее решения;
степень формализуемости задачи;
источники информации, необходимые для решения задачи;
показатели

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

Слайд 58Содержание схемы маршрута движения документов
количество документов;
место формирования показателей документа;
взаимосвязь

документов при их формировании;
маршрут и длительность движения документа;
место использования и

хранения данного документа;
внутренние и внешние информационные связи;
объем документа в знаках.

Содержание схемы маршрута движения документов количество документов;место формирования показателей документа;взаимосвязь документов при их формировании;маршрут и длительность движения

Слайд 59Классификация функций системы в формате MuSCoW
Must have - необходимые функции;

Should

have - желательные функции;

Could have - возможные функции;

Won't have

- отсутствующие функции.
Классификация функций системы в формате MuSCoWMust have - необходимые функции;Should have - желательные функции; Could have -

Слайд 60Модели деятельности организации
модель "как есть" ("as-is")- отражает существующие в

организации бизнес-процессы;

модель "как должно быть" ("to-be") - отражает необходимые изменения

бизнес-процессов с учетом внедрения ИС.

Модели деятельности организации модель

Слайд 61Задачи тестирования
получения сравнительных характеристик предполагаемых к использованию аппаратных платформ, операционных

систем, СУБД, иного окружения;

разработки плана работ по обеспечению надежности информационной

системы и ее тестирования.

Задачи тестированияполучения сравнительных характеристик предполагаемых к использованию аппаратных платформ, операционных систем, СУБД, иного окружения;разработки плана работ по

Слайд 62Стадия 2. Разработка концепции ИС
изучение объекта автоматизации;

проведение необходимых научно-исследовательских

работ;

разработка вариантов концепции ИС, удовлетворяющих требованиям пользователей;

оформление отчета и утверждение

концепции.

Стадия 2. Разработка концепции ИС изучение объекта автоматизации;проведение необходимых научно-исследовательских работ;разработка вариантов концепции ИС, удовлетворяющих требованиям пользователей;оформление

Слайд 63Стадия 3. Техническое задание
Результаты обследования представляют объективную основу для

формирования технического задания на информационную систему.

Техническое задание - это документ,

определяющий цели, требования и основные исходные данные, необходимые для разработки автоматизированной системы управления.

Стадия 3. Техническое задание Результаты обследования представляют объективную основу для формирования технического задания на информационную систему.Техническое задание

Слайд 64Задачи при разработке технического задания
установить общую цель создания ИС, определить

состав подсистем и функциональных задач;
разработать и обосновать требования, предъявляемые к

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

Задачи при разработке технического заданияустановить общую цель создания ИС, определить состав подсистем и функциональных задач;разработать и

Слайд 65Состав технического задания (ГОСТ 34.602- 89)
1 Общие сведения
2

Назначение и цели создания (развития) системы
3 Характеристика объектов автоматизации


4 Требования к системе
к системе в целом
к функциям (по подсистемам)
к видам обеспечения
5 Состав и содержание работ по созданию системы
6 Порядок контроля и приемки системы
7 Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
8 Требования к документированию
9 Источники разработки: документы и информационные материалы, на основании которых разрабатывается ТЗ и система.

Состав технического задания (ГОСТ 34.602- 89) 1 Общие сведения 2 Назначение и цели создания (развития) системы

Слайд 66Стадия 4. Эскизный проект
разработка предварительных проектных решений по системе

и ее частям;

разработка эскизной документации на ИС и ее части.

Стадия 4. Эскизный проект разработка предварительных проектных решений по системе и ее частям;разработка эскизной документации на ИС

Слайд 67На этапе эскизного проектирования определяются:
функции ИС;
функции подсистем, их цели и

ожидаемый эффект от внедрения;
состав комплексов задач и отдельных задач;
концепция информационной

базы и ее укрупненная структура;
функции системы управления базой данных;
состав вычислительной системы и других технических средств;
функции и параметры основных программных средств.

На этапе эскизного проектирования определяются:функции ИС;функции подсистем, их цели и ожидаемый эффект от внедрения;состав комплексов задач и

Слайд 68Стадия 5. Технический проект
разработка проектных решений по системе и

ее частям;

разработка документации на ИС и ее части;

разработка и оформление

документации на поставку комплектующих изделий;

разработка заданий на проектирование в смежных частях проекта.

Стадия 5. Технический проект разработка проектных решений по системе и ее частям;разработка документации на ИС и ее

Слайд 69Содержание технического проекта

Содержание технического проекта

Слайд 70Содержание технического проекта (продолжение)

Содержание технического проекта (продолжение)

Слайд 71Содержание технического проекта (продолжение)

Содержание технического проекта (продолжение)

Слайд 72Содержание технического проекта (продолжение)

Содержание технического проекта (продолжение)

Слайд 73Содержание технического проекта (продолжение)

Содержание технического проекта (продолжение)

Слайд 74Стадия 6. Рабочая документация
разработка рабочей документации на ИС и

ее части;
разработка и адаптация программ.

Документация должна содержать все необходимые и

достаточные сведения для обеспечения выполнения работ по вводу ИС в действие и ее эксплуатации, а также для поддержания уровня эксплуатационных характеристик (качества) системы.
Стадия 6. Рабочая документация разработка рабочей документации на ИС и ее части;разработка и адаптация программ. Документация должна содержать

Слайд 75Стадия 7. Ввод в действие
подготовка объекта автоматизации;
подготовка персонала;
комплектация ИС поставляемыми

изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями);
строительно-монтажные работы;
пусконаладочные

работы;
проведение предварительных испытаний ;
проведение опытной эксплуатации ;
проведение приемочных испытаний.

Стадия 7. Ввод в действиеподготовка объекта автоматизации;подготовка персонала;комплектация ИС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами,

Слайд 76Стадия 8. Сопровождение ИС
выполнение работ в соответствии с гарантийными

обязательствами;

послегарантийное обслуживание.

Стадия 8. Сопровождение ИС выполнение работ в соответствии с гарантийными обязательствами;послегарантийное обслуживание.

Слайд 773.2 Типовое проектирование ИС
Типовое проектное решение (ТПР) - это

тиражируемое (пригодное к многократному использованию) проектное решение.

Типовое проектирование ИС предполагает

создание системы из готовых типовых элементов.

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

3.2 Типовое проектирование ИС Типовое проектное решение (ТПР) - это тиражируемое (пригодное к многократному использованию) проектное решение.Типовое

Слайд 78Классы ТПР
элементные ТПР - типовые решения по задаче или

по отдельному виду обеспечения задачи (информационному, программному, техническому, математическому, организационному);

подсистемные

ТПР - в качестве элементов типизации выступают отдельные подсистемы, разработанные с учетом функциональной полноты и минимизации внешних информационных связей;

объектные ТПР - типовые отраслевые проекты, которые включают полный набор функциональных и обеспечивающих подсистем ИС.

Классы ТПР элементные ТПР - типовые решения по задаче или по отдельному виду обеспечения задачи (информационному, программному,

Слайд 79Достоинства и недостатки ТП

Достоинства и недостатки ТП

Слайд 80Достоинства и недостатки ТП (продолжение)

Достоинства и недостатки ТП (продолжение)

Слайд 81Достоинства и недостатки ТП (продолжение)

Достоинства и недостатки ТП (продолжение)

Слайд 82Этапы параметрически-ориентированного проектирования
определение критериев оценки пригодности пакетов прикладных программ

(ППП) для решения поставленных задач,

анализ и оценка доступных ППП

по сформулированным критериям,

выбор и закупка наиболее подходящего пакета,

настройка параметров (доработка) закупленного ППП.
Этапы параметрически-ориентированного проектирования определение критериев оценки пригодности пакетов прикладных программ (ППП) для решения поставленных задач, анализ и

Слайд 83Модельно-ориентированное проектирование
Заключается в адаптации состава и характеристик типовой ИС

в соответствии с моделью объекта автоматизации.
Технология проектирования в этом

случае должна обеспечивать единые средства для работы как с моделью типовой ИС, так и с моделью конкретного предприятия.
Предполагает построение модели объекта автоматизации с использованием специального программного инструментария (например, SAP Business Engineering Workbench (BEW), BAAN Enterprise Modeler).
Возможно также создание системы на базе типовой модели ИС из репозитория, который поставляется вместе с программным продуктом и расширяется по мере накопления опыта проектирования информационных систем для различных отраслей и типов производства.
Модельно-ориентированное проектирование Заключается в адаптации состава и характеристик типовой ИС в соответствии с моделью объекта автоматизации. Технология

Слайд 84Типовые модели
Типовые модели описывают конфигурации информационной системы для определенных отраслей

или типов производства.

Модель конкретного предприятия строится либо путем выбора фрагментов

основной или типовой модели в соответствии со специфическими особенностями предприятия (BAAN Enterprise Modeler), либо путем автоматизированной адаптации этих моделей в результате экспертного опроса (SAP Business Engineering Workbench).

Построенная модель предприятия в виде метаописания хранится в репозитории и при необходимости может быть откорректирована. На основе этой модели автоматически осуществляется конфигурирование и настройка информационной системы.
Типовые моделиТиповые модели описывают конфигурации информационной системы для определенных отраслей или типов производства.Модель конкретного предприятия строится либо

Слайд 85Внедрение типовой информационной системы
Начинается с анализа требований к конкретной

ИС, которые выявляются на основе результатов предпроектного обследования.
Выбор пакета прикладных

программ (ППП).
На базе имеющихся в ППП референтных моделей строится предварительная модель ИС, в которой отражаются все особенности реализации ИС для конкретного предприятия.
Предварительная модель является основой для выбора типовой модели системы и определения перечня компонентов, которые будут реализованы с использованием других программных средств или потребуют разработки с помощью имеющихся в составе типовой ИС инструментальных средств (например, ABAP в SAP, Tools в BAAN).
Внедрение типовой информационной системы Начинается с анализа требований к конкретной ИС, которые выявляются на основе результатов

Слайд 86Реализация типового проекта
установка глобальных параметров системы;
задание структуры объекта автоматизации;
определение

структуры основных данных;
задание перечня реализуемых функций и процессов;
описание интерфейсов;
описание отчетов;
настройка

авторизации доступа;
настройка системы архивирования.
Реализация типового проекта установка глобальных параметров системы;задание структуры объекта автоматизации;определение структуры основных данных;задание перечня реализуемых функций и

Слайд 87 4. Анализ и моделирование функциональной области внедряемой ИС



 4. Анализ и моделирование функциональной области внедряемой ИС

Слайд 884.1. Организационное бизнес-моделирование
Практика выработала ряд подходов к проведению организационного

анализа, но наибольшее распространение получил инжиниринговый подход.

Компания рассматривается как

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

Возможности компании определяются характеристиками ее структурных подразделений и организацией их взаимодействия.
4.1. Организационное бизнес-моделирование Практика выработала ряд подходов к проведению организационного анализа, но наибольшее распространение получил инжиниринговый

Слайд 89Обобщенная схема организационного бизнес- моделирования

Обобщенная схема организационного бизнес- моделирования

Слайд 90Миссия компании
Миссия согласно [ISO-15704] :
деятельность, осуществляемая предприятием для того, чтобы

выполнить функцию, для которой оно было учреждено, - предоставления заказчикам

продукта или услуги.
Механизм, с помощью которого предприятие реализует свои цели и задачи.

Миссия компании по удовлетворению социально-значимых потребностей рынка определяется как компромисс интересов рынка и компании.

Миссия как атрибут открытой системы разрабатывается, с одной стороны, исходя из рыночной конъюнктуры и позиционирования компании относительно других участников внешней среды, а с другой - исходя из объективных возможностей компании и ее субъективных ценностей, ожиданий и принципов.

Миссия компании Миссия согласно [ISO-15704] :деятельность, осуществляемая предприятием для того, чтобы выполнить функцию, для которой оно было учреждено,

Слайд 91Цели и стратегии
Определение миссии позволяет сформировать дерево целей компании -

иерархические списки уточнения и детализации миссии.
Дерево целей формирует дерево стратегий

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


Цели и стратегииОпределение миссии позволяет сформировать дерево целей компании - иерархические списки уточнения и детализации миссии.Дерево целей

Слайд 92Бизнес-потенциал компании
Бизнес-потенциал компании - набор видов коммерческой деятельности, направленный

на удовлетворение потребностей конкретных сегментов рынка.

Далее, исходя из специфики

каналов сбыта, формируется первоначальное представление об организационной структуре - определяются центры коммерческой ответственности.

Возникает понимание основных ресурсов, необходимых для воспроизводства товарной номенклатуры.
Бизнес-потенциал компании Бизнес-потенциал компании - набор видов коммерческой деятельности, направленный на удовлетворение потребностей конкретных сегментов рынка. Далее,

Слайд 93Функционал компании
Бизнес-потенциал определяет функционал компании - перечень бизнес-функций, функций

менеджмента и функций обеспечения, требуемых для поддержания на регулярной основе

указанных видов коммерческой деятельности.

Уточняются необходимые для этого ресурсы -материальные, человеческие, информационные и структура компании.
Функционал компании Бизнес-потенциал определяет функционал компании - перечень бизнес-функций, функций менеджмента и функций обеспечения, требуемых для поддержания

Слайд 94Зоны ответственности менеджмента
Матрица коммерческой ответственности закрепляет ответственность структурных подразделений

за получение дохода в компании от реализации коммерческой деятельности. Ее

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

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

Зоны ответственности менеджмента Матрица коммерческой ответственности закрепляет ответственность структурных подразделений за получение дохода в компании от реализации

Слайд 95Результаты бизнес-моделирования статического описания компании
Формируется общепризнанный набор основополагающих внутрифирменных

регламентов:

базовое Положение об организационно-функциональной структуре компании;

пакет Положений об отдельных видах

деятельности (финансовой, маркетинговой и т.д.);

пакет Положений о структурных подразделениях (цехах, отделах, секторах, группах и т.п.);

должностные инструкции.

Результаты бизнес-моделирования статического описания компании Формируется общепризнанный набор основополагающих внутрифирменных регламентов:базовое Положение об организационно-функциональной структуре компании;пакет Положений

Слайд 96Этап динамического описания компании
Процессные потоковые модели - это модели, описывающие

процесс последовательного во времени преобразования материальных и информационных потоков компании

в ходе реализации какой-либо бизнес-функции или функции менеджмента.

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

Слайд 97Модель структур данных
Модель структур данных определяет перечень и форматы

документов, сопровождающих процессы в компании, а также задает форматы описания

объектов внешней среды, компонентов и регламентов самой компании.

При этом создается система справочников, на основании которых получают пакеты необходимых документов и отчетов.
Модель структур данных Модель структур данных определяет перечень и форматы документов, сопровождающих процессы в компании, а также

Слайд 98Основные этапы процессно-целевого описания компании

Основные этапы процессно-целевого описания компании

Слайд 99Полная бизнес-модель компании

Полная бизнес-модель компании

Слайд 100Организационный анализ: комплекс моделей компании
Стратегическая модель целеполагания - отвечает

на вопросы: зачем компания занимается именно этим бизнесом, почему предполагает

быть конкурентоспособной, какие цели и стратегии для этого необходимо реализовать;
Организационно-функциональная модель - отвечает на вопрос кто-что делает в компании и кто за что отвечает;
Функционально-технологическая модель - отвечает на вопрос что-как реализуется в компании;
Процессно-ролевая модель - отвечает на вопрос кто-что-как-кому;
Количественная модель - отвечает на вопрос сколько необходимо ресурсов;
Модель структуры данных - отвечает на вопрос в каком виде описываются регламенты компании и объекты внешнего окружения.

Организационный анализ: комплекс моделей компании Стратегическая модель целеполагания - отвечает на вопросы: зачем компания занимается именно

Слайд 101Шаблоны организационного бизнес-моделирования: шаблон разработки миссии
Миссия представляет собой результат позиционирования

компании среди других участников рынка. Для построения модели взаимодействия компании

с внешней средой (определение миссии компании на рынке) необходимо:

идентифицировать рынок (надсистему), частью которого является компания;

определить свойства (потребности) рынка;

определить предназначение ( миссию ) компании, исходя из ее роли на рынке.

Шаблоны организационного бизнес-моделирования: шаблон разработки миссии Миссия представляет собой результат позиционирования компании среди других участников рынка.

Слайд 102Шаблон разработки миссии ( матрица проекций)

Шаблон разработки миссии ( матрица проекций)

Слайд 103Шаблон разработки миссии

Шаблон разработки миссии

Слайд 104Шаблон формирования бизнесов

Шаблон формирования бизнесов

Слайд 105Шаблон формирования основных бизнес-функций

Шаблон формирования основных бизнес-функций

Слайд 106Шаблон формирования основных функций менеджмента

Шаблон формирования основных функций менеджмента

Слайд 107Шаблон распределения функций по организационным звеньям

Шаблон распределения функций по организационным звеньям

Слайд 108Потоковая процессная модель

Потоковая процессная модель

Слайд 109Функциональная схема компании

Функциональная схема компании

Слайд 110Построение организационно-функциональной модели
Для построения организационно-функциональной модели используется всего два

типа элементарных моделей - древовидные и матричные.

Древовидные модели (классификаторы) -

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

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

Слайд 111 В начальной организационно-функциональной модели применяется всего несколько классификаторов предметной области:

основные

группы продуктов и услуг компании;
ресурсы, потребляемые компанией в ходе своей

деятельности;
функции (процессы), поддерживаемые в компании;
организационные звенья компании.

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

В начальной организационно-функциональной модели применяется всего несколько классификаторов предметной области:основные группы продуктов и услуг компании;ресурсы, потребляемые компанией

Слайд 112 Главной функцией компании является предоставление продуктов и услуг, поэтому сначала

производится формальное описание, согласование и утверждение руководством предприятия перечня его

бизнесов (направлений коммерческой деятельности), продукции и услуг.

Из этого классификатора внешним контрагентам должно быть понятно, чем предприятие интересно рынку, а для внутренних целей - для чего нужен тот или иной функционал компании.
Главной функцией компании является предоставление продуктов и услуг, поэтому сначала производится формальное описание, согласование и утверждение руководством

Слайд 113 В результате этих операций производится идентификация функционала и создается единая

терминология описания функций предприятия, которая должна быть согласована всеми ведущими

менеджерами.

При составлении классификатора оргзвеньев важно, чтобы уровень детализации функций соответствовал уровню детализации звеньев.

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

Слайд 114Агрегированная модель
Агрегированная модель - модель организационной структуры, учетные регистры которой

имеют ограничение по степени детализации до 2-3 уровней.

Целью построения данной

модели является предоставление информации об организационной структуре высшим руководителям компании для проведения стратегического анализа, анализа соответствия данной структуры стратегии и внешнему окружению компании. Модель может также предоставляться внешним пользователям (например, потенциальным инвесторам как иллюстрация к бизнес-плану, крупным клиентам и др.).
Агрегированная модельАгрегированная модель - модель организационной структуры, учетные регистры которой имеют ограничение по степени детализации до 2-3

Слайд 115Детализированная модель
Детализированная модель - модель организационной структуры, детализация учетных регистров

которой производится на более глубоких уровнях, чем в агрегированной модели.

Степень детализации в модели обусловлена конкретными потребностями компании (создание определенных организационных регламентов).

Целью построения данной модели является предоставление информации о распределении функциональных обязанностей между подразделениями компании, а также об организации бизнес-процессов в компании.
Детализированная модель Детализированная модель - модель организационной структуры, детализация учетных регистров которой производится на более глубоких уровнях, чем

Слайд 116Схема создания Положения об организационно- функциональной структуре компании

Схема создания Положения об организационно- функциональной структуре компании

Слайд 117Распределение функций по подразделениям торгового предприятия

Распределение функций по подразделениям торгового предприятия

Слайд 118Инструментальные средства организационного моделирования
В начале 1990-х годов на Западе появились

первые программы (класс программ Orgware) организационного моделирования.

Первый российский продукт

- БИГ-Мастер - для поддержки определенной концепции управления предприятием, получившей название регулярного менеджмента.

Концептуальной основой БИГ-Мастера стал современный процессный подход к организации деятельности компании.
Инструментальные средства организационного моделированияВ начале 1990-х годов на Западе появились первые программы (класс программ Orgware) организационного моделирования.

Слайд 119БИГ-Мастер
Для структурного анализа и проектирования процессов, описываемых потоковыми моделями, БИГ-Мастер

поддерживает методологию SADT (IDEF).

Классификаторы, проекции и потоковые модели бизнес-процессов

поддерживаются различными способами их визуализации.

Для классификаторов - в виде списков и деревьев (орграфов), для проекции - в виде связанных списков и транспонируемых матриц, а для потоковых моделей бизнес-процессов - в виде диаграмм IDEF0 (IDEF3) и текстового описания, что облегчает понимание задач участниками процессов.
БИГ-МастерДля структурного анализа и проектирования процессов, описываемых потоковыми моделями, БИГ-Мастер поддерживает методологию SADT (IDEF). Классификаторы, проекции и

Слайд 120 5. Спецификация функциональных требований к ИС

Дальнейшее развитие (детализация) бизнес-модели происходит

на этапе динамичного описания компании на уровне процессных потоковых моделей.

5. Спецификация функциональных требований к ИСДальнейшее развитие (детализация) бизнес-модели происходит на этапе динамичного описания компании на уровне

Слайд 121Процессные потоковые модели
Это модели, описывающие процесс последовательного во времени

преобразования материальных и информационных потоков компании в ходе реализации какой-либо

бизнес-функции или функции менеджмента.

На верхнем уровне описывается логика взаимодействия участников процесса, на нижнем — технология работы отдельных специалистов на своих рабочих местах.

Процессный подход, в отличие от функционального, предполагает смещение акцентов от управления отдельными структурными элементами на управление сквозными бизнес-процессами, связывающими деятельность всех структурных элементов.
Процессные потоковые модели Это модели, описывающие процесс последовательного во времени преобразования материальных и информационных потоков компании в

Слайд 122Основные Положения и Словарь — ИСО 9000:2000
"Любая деятельность, или комплекс

деятельности, в которой используются ресурсы для преобразования входов в выходы,

может рассматриваться как процесс. Чтобы результативно функционировать, организации должны определять и управлять многочисленными взаимосвязанными и взаимодействующими процессами. Часто выход одного процесса образует непосредственно вход следующего. Систематическая идентификация и менеджмент применяемых организацией процессов, и особенно взаимодействия таких процессов, могут считаться " процессным подходом ".
Основные Положения и Словарь — ИСО 9000:2000

Слайд 123Процессная модель
Процессная модель компании должна строиться с учетом следующих

положений:
Верхний уровень модели должен отражать только контекст диаграммы – взаимодействие

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

Слайд 124Выделение и классификация бизнес-процессов
Целесообразно основываться на следующих классах процессов:
основные;
процессы

управления ;
процессы обеспечения ;
сопутствующие;
вспомогательные;
процессы развития.

Выделение и классификация бизнес-процессов Целесообразно основываться на следующих классах процессов:основные;процессы управления ;процессы обеспечения ;сопутствующие;вспомогательные;процессы развития.

Слайд 125Пример процесса "жизненного цикла документа"
Элементарные операции процесса оформления документа участниками

процесса:
предоставляет исходные данные;
подготавливает, разрабатывает;
заполняет;
корректирует;
оформляет;
подписывает;
контролирует соответствие установленным требованиям;
визирует;
согласует;
утверждает;
акцептует (принимает к сведению,

использует);
хранит;
снимает копию.


Пример процесса

Слайд 126Цикл организационного менеджмента: процессное моделирование
определение состава задач (обособленных функций, операций);
выбор

исполнителей (распределение зон и степени ответственности);
проектирование процедур (последовательности и порядка

исполнения);
согласование и утверждение регламента исполнения (процесса, плана мероприятий);
отчетность об исполнении;
контроль исполнения (процедурный контроль);
анализ причин отклонений и регулирование (возврат к 1, 2 или 3).
Цикл организационного менеджмента: процессное моделированиеопределение состава задач (обособленных функций, операций);выбор исполнителей (распределение зон и степени ответственности);проектирование процедур

Слайд 127Референтная модель бизнес-процесса
Референтная модель — это модель эффективного бизнес-процесса, созданная

для предприятия конкретной отрасли, внедренная на практике и предназначенная для

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

Референтная модель бизнес-процессаРеферентная модель — это модель эффективного бизнес-процесса, созданная для предприятия конкретной отрасли, внедренная на практике

Слайд 128Референтная модель бизнес-процесса (продолжение)
Референтная модель бизнес-процесса представляет собой совокупность логически взаимосвязанных

функций. Для каждой функции указывается исполнитель, входные и выходные документы

или информационные объекты.

Элементы (функции и документы) референтной модели бизнес-процесса содержат ссылки на соответствующие объекты ИС, а также документы и другую информацию (пользовательские инструкции, ответственных разработчиков), расположенную в репозитарии проекта. Отсюда и название — референтная модель (в переводе с английского «ссылочная» модель).

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

Слайд 129Роль моделирования предметной области
В основе проектирования ИС лежит моделирование предметной

области.
Под моделью предметной области понимается некоторая система, имитирующая структуру

или функционирование исследуемой предметной области и отвечающая основному требованию – быть адекватной этой области.
Предварительное моделирование предметной области позволяет сократить время и сроки проведения проектировочных работ и получить более эффективный и качественный проект.
Без проведения моделирования предметной области велика вероятность допущения большого количества ошибок в решении стратегических вопросов, приводящих к экономическим потерям и высоким затратам на последующее перепроектирование системы -> все современные технологии проектирования ИС основываются на использовании методологии моделирования предметной области.


Роль моделирования предметной областиВ основе проектирования ИС лежит моделирование предметной области. Под моделью предметной области понимается некоторая

Слайд 130Требования к моделям предметных областей
формализация, обеспечивающая однозначное описание структуры предметной

области;
понятность для заказчиков и разработчиков на основе применения графических средств

отображения модели;
реализуемость, подразумевающая наличие средств физической реализации модели предметной области в ИС;
обеспечение оценки эффективности реализации модели предметной области на основе определенных методов и вычисляемых показателей.

Для реализации перечисленных требований, как правило, строится система моделей, которая отражает структурный и оценочный аспекты функционирования предметной области.

Требования к моделям предметных областейформализация, обеспечивающая однозначное описание структуры предметной области;понятность для заказчиков и разработчиков на основе

Слайд 131Структурный аспект
Структурный аспект предполагает построение:

объектной структуры, отражающей состав взаимодействующих в

процессах материальных и информационных объектов предметной области;
функциональной структуры, отражающей взаимосвязь

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

Структурный аспект Структурный аспект предполагает построение:объектной структуры, отражающей состав взаимодействующих в процессах материальных и информационных объектов предметной области;функциональной

Слайд 132Оценочные аспекты моделирования
Оценочные аспекты моделирования предметной области связаны с разрабатываемыми

показателями эффективности автоматизируемых процессов, к которым относятся:
время решения задач;
стоимостные затраты

на обработку данных;
надежность процессов;
косвенные показатели эффективности, такие, как объемы производства, производительность труда, оборачиваемость капитала, рентабельность и т.д.

Для расчета показателей эффективности, как правило, используются статические методы функционально-стоимостного анализа (ABC) и динамические методы имитационного моделирования.
Оценочные аспекты моделирования Оценочные аспекты моделирования предметной области связаны с разрабатываемыми показателями эффективности автоматизируемых процессов, к которым относятся:время

Слайд 133Принципы последовательной детализации
Обычно модели строятся на трех уровнях:

внешнем уровне

( определении требований ),
концептуальном уровне ( спецификации требований ),


внутреннем уровне ( реализации требований ).
Принципы последовательной детализации Обычно модели строятся на трех уровнях: внешнем уровне ( определении требований ), концептуальном уровне (

Слайд 134На внешнем уровне модель отвечает на вопрос, что должна делать

система, то есть определяется состав основных компонентов системы: объектов, функций,

событий, организационных единиц, технических средств.

На концептуальном уровне модель отвечает на вопрос, как должна функционировать система? Иначе говоря, определяется характер взаимодействия компонентов системы одного и разных типов.

На внутреннем уровне модель отвечает на вопрос: с помощью каких программно-технических средств реализуются требования к системе?

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

Слайд 135Методологии описания предметной области
Методики делят на объектные и функциональные.
Объектные

методики рассматривают моделируемую организацию как набор взаимодействующих объектов – производственных

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


Методологии описания предметной областиМетодики делят на объектные и функциональные. Объектные методики рассматривают моделируемую организацию как набор взаимодействующих

Слайд 136Объектный подход позволяет построить более устойчивую к изменениям систему, лучше

соответствует существующим структурам организации.

Функциональное моделирование хорошо показывает себя в

тех случаях, когда организационная структура находится в процессе изменения или вообще слабо оформлена. Подход от выполняемых функций интуитивно лучше понимается исполнителями при получении от них информации об их текущей работе.

Объектный подход позволяет построить более устойчивую к изменениям систему, лучше соответствует существующим структурам организации. Функциональное моделирование хорошо

Слайд 137Функциональная методика IDEF0
В основе методологии лежат четыре основных понятия: функциональный

блок, интерфейсная дуга, декомпозиция, глоссарий.


Функциональная методика IDEF0В основе методологии лежат четыре основных понятия: функциональный блок, интерфейсная дуга, декомпозиция, глоссарий.

Слайд 138Для каждого из элементов IDEF0 — диаграмм, функциональных блоков, интерфейсных

дуг — существующий стандарт подразумевает создание и поддержание набора (глоссария)

соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом.

В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint).

Точка зрения определяет основное направление развития модели и уровень необходимой детализации. Четкое фиксирование точки зрения позволяет разгрузить модель, отказавшись от детализации и исследования отдельных элементов, не являющихся необходимыми, исходя из выбранной точки зрения на систему. Правильный выбор точки зрения существенно сокращает временные затраты на построение конечной модели.

Для каждого из элементов IDEF0 — диаграмм, функциональных блоков, интерфейсных дуг — существующий стандарт подразумевает создание и

Слайд 139Диаграммы потоков данных
Диаграммы потоков данных (Data Flow Diagram — DFD)

являются основным средством моделирования функциональных требований к проектируемой системе.

При создании

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

Кроме основных элементов, в состав DFD входят словари данных и миниспецификации.


Диаграммы потоков данныхДиаграммы потоков данных (Data Flow Diagram — DFD) являются основным средством моделирования функциональных требований к

Слайд 140Преимущества методики DFD
К преимуществам методики DFD относятся:

возможность однозначно определить внешние

сущности, анализируя потоки информации внутри и вне системы;
возможность проектирования сверху

вниз, что облегчает построение модели "как должно быть";
наличие спецификаций процессов нижнего уровня, что позволяет преодолеть логическую незавершенность функциональной модели и построить полную функциональную спецификацию разрабатываемой системы.

Преимущества методики DFD К преимуществам методики DFD относятся:возможность однозначно определить внешние сущности, анализируя потоки информации внутри и вне

Слайд 141Недостатки методики DFD
необходимость искусственного ввода управляющих процессов, поскольку управляющие воздействия

(потоки) и управляющие процессы с точки зрения DFD ничем не

отличаются от обычных;

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

Недостатки методики DFDнеобходимость искусственного ввода управляющих процессов, поскольку управляющие воздействия (потоки) и управляющие процессы с точки зрения

Слайд 142Объектно-ориентированная методика
Объектно-ориентированный подход использует объектную декомпозицию, при этом статическая структура

описывается в терминах объектов и связей между ними, а поведение

системы описывается в терминах обмена сообщениями между объектами.
Концептуальной основой объектно-ориентированного подхода является объектная модель, которая строится с учетом следующих принципов:
абстрагирование;
инкапсуляция;
модульность;
иерархия;
типизация;
параллелизм;
устойчивость.

Объектно-ориентированная методикаОбъектно-ориентированный подход использует объектную декомпозицию, при этом статическая структура описывается в терминах объектов и связей между

Слайд 143Основные понятия объектно-ориентированного подхода
Объект — предмет или явление, имеющее

четко определенное поведение и обладающие состоянием, поведением и индивидуальностью. Структура

и поведение схожих объектов определяют общий для них класс.
Класс – это множество объектов, связанных общностью структуры и поведения. Следующую группу важных понятий объектного подхода составляют наследование и полиморфизм.
Понятие полиморфизм может быть интерпретировано как способность класса принадлежать более чем одному типу.
Наследование означает построение новых классов на основе существующих с возможностью добавления или переопределения данных и методов.
В качестве языка моделирования объектного подхода используется унифицированный язык моделирования UML.

Основные понятия объектно-ориентированного подхода Объект — предмет или явление, имеющее четко определенное поведение и обладающие состоянием, поведением

Слайд 144Преимущества объектно-ориентированного подхода
Объектная декомпозиция дает возможность создавать модели меньшего

размера путем использования общих механизмов, обеспечивающих необходимую экономию выразительных средств.

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

Слайд 145Недостатки объектно-ориентированного подхода
высокие начальные затраты,

этот подход не дает немедленной

отдачи,

эффект от его применения сказывается после разработки двух–трех проектов и

накопления повторно используемых компонентов,

диаграммы, отражающие специфику объектного подхода, менее наглядны.

Недостатки объектно-ориентированного подхода высокие начальные затраты,этот подход не дает немедленной отдачи,эффект от его применения сказывается после разработки

Слайд 146Сравнение существующих методик
Для функциональных моделей характерны процедурная строгость декомпозиции ИС

и наглядность представления.
При функциональном подходе объектные модели данных в

виде ER-диаграмм "объект — свойство — связь" разрабатываются отдельно. Для проверки корректности моделирования предметной области между функциональными и объектными моделями устанавливаются взаимно однозначные связи.
Главный недостаток функциональных моделей заключается в том, что процессы и данные существуют отдельно друг от друга — помимо функциональной декомпозиции существует структура данных, находящаяся на втором плане. Кроме того, не ясны условия выполнения процессов обработки информации, которые динамически могут изменяться.


Сравнение существующих методикДля функциональных моделей характерны процедурная строгость декомпозиции ИС и наглядность представления. При функциональном подходе объектные

Слайд 147Сравнение существующих методик (продолжение)
Перечисленные недостатки функциональных моделей снимаются в объектно-ориентированных моделях,

в которых главным структурообразующим компонентом выступает класс объектов с набором

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

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

Слайд 148Комбинированные модели
При выборе методики моделирования предметной области обычно в качестве

критерия выступает степень ее динамичности. Для более регламентированных задач больше

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

Слайд 149Пример синтетической методики (стадии построения административных регламентов)
Определение границ системы. На

этой стадии при помощи анализа потоков данных выделяют внешние сущности

и собственно моделируемую систему.
Выделение сценариев использования системы. На этой стадии при помощи критерия полезности строят для каждой внешней сущности набор сценариев использования системы.
Добавление системных сценариев использования. На этой стадии определяют сценарии, необходимые для реализации целей системы, отличных от целей пользователей.
Построение диаграммы активностей по сценариям использования. На этой стадии строят набор действий системы, приводящих к реализации сценариев использования;
Функциональная декомпозиция диаграмм активностей как контекстных диаграмм методики IDEF0.
Формальное описание отдельных функциональных активностей в виде административного регламента (с применением различных нотаций ).

Пример синтетической методики (стадии построения административных регламентов) Определение границ системы. На этой стадии при помощи анализа потоков

Слайд 150Унифицированный язык визуального моделирования (UML)
UML представляет собой объектно-ориентированный язык моделирования,

обладающий следующими основными характеристиками:

является языком визуального моделирования, который обеспечивает разработку

репрезентативных моделей для организации взаимодействия заказчика и разработчика ИС, различных групп разработчиков ИС;

содержит механизмы расширения и специализации базовых концепций языка.
Унифицированный язык визуального моделирования (UML) UML представляет собой объектно-ориентированный язык моделирования, обладающий следующими основными характеристиками:является языком визуального

Слайд 151Унифицированный язык визуального моделирования (UML) (продолжение)
UML включает внутренний набор средств

моделирования (модулей?) ("ядро"), которые сейчас приняты во многих методах и

средствах моделирования. Пользователям языка предоставлены возможности:
строить модели на основе средств ядра, без использования механизмов расширения для большинства типовых приложений;
добавлять при необходимости новые элементы и условные обозначения, если они не входят в ядро, или специализировать компоненты, систему условных обозначений (нотацию) и ограничения для конкретных предметных областей.
Унифицированный язык визуального моделирования (UML) (продолжение) UML включает внутренний набор средств моделирования (модулей?) (

Слайд 152UML: классы
Классы представляют собой описание совокупностей однородных объектов с присущими

им свойствами — атрибутами, операциями, отношениями и семантикой.
Атрибут — это

свойство класса, которое может принимать множество значений. Множество допустимых значений атрибута образует домен. Атрибут имеет имя и отражает некоторое свойство моделируемой сущности, общее для всех объектов данного класса. Класс может иметь произвольное количество атрибутов.
Операция — реализация функции, которую можно запросить у любого объекта класса. Операция показывает, что можно сделать с объектом. Исполнение операции часто связано с обработкой и изменением значений атрибутов объекта, а также изменением состояния объекта.

UML: классыКлассы представляют собой описание совокупностей однородных объектов с присущими им свойствами — атрибутами, операциями, отношениями и

Слайд 153Изображение класса в UML

Изображение класса в UML

Слайд 154Диаграммы классов
Классы в UML изображаются на диаграммах классов, которые позволяют

описать систему в статическом состоянии — определить типы объектов системы

и различного рода статические связи между ними.

Между классами возможны различные отношения, представленные на рисунке:
зависимости, которые описывают существующие между классами отношения использования;
обобщения, связывающие обобщенные классы со специализированными;
ассоциации, отражающие структурные отношения между объектами классов.

Диаграммы классов Классы в UML изображаются на диаграммах классов, которые позволяют описать систему в статическом состоянии — определить

Слайд 155Отображение связей между классами

Отображение связей между классами

Слайд 156Диаграммы использования
Диаграммы использования описывают функциональность ИС, которая будет видна пользователям

системы. Каждая «функциональность» изображается в виде "прецедентов использования" (use case)

или просто прецедентов. Прецедент — это типичное взаимодействие пользователя с системой, которое при этом:
описывает видимую пользователем функцию,
может представлять различные уровни детализации,
обеспечивает достижение конкретной цели, важной для пользователя.

Список всех прецедентов фактически определяет функциональные требования к ИС, которые лежат в основе разработки технического задания на создание системы.


Диаграммы использования Диаграммы использования описывают функциональность ИС, которая будет видна пользователям системы. Каждая «функциональность» изображается в виде

Слайд 157Связи на диаграммах прецедентов
При исполнении прецедента " формирование заказа "

возможно использование информации из предыдущего заказа, что позволит не вводить

все необходимые данные. А при исполнении прецедентов " оценить риск сделки " и " согласовать цену " необходимо выполнить одно и то же действие — рассчитать стоимость заказа.

Связи на диаграммах прецедентовПри исполнении прецедента

Слайд 158Динамические аспекты поведения системы
Поведение системы отображаются в UML на

диаграммах взаимодействия.

Как правило, диаграмма взаимодействия охватывает поведение объектов в

рамках одного варианта использования.

Существуют два вида диаграмм взаимодействия: диаграммы последовательностей и кооперативные диаграммы.

Динамические аспекты поведения системы Поведение системы отображаются в UML на диаграммах взаимодействия. Как правило, диаграмма взаимодействия охватывает

Слайд 159Диаграммы последовательностей
Этот вид диаграмм используется для точного определения логики сценария

выполнения прецедента.

Диаграммы последовательностей отображают типы объектов, взаимодействующих при исполнении

прецедентов, сообщения, которые они посылают друг другу, и любые возвращаемые значения, ассоциированные с этими сообщениями.

Прямоугольники на вертикальных линиях показывают "время жизни" объекта. Линии со стрелками и надписями названий методов означают вызов метода у объекта.
Диаграммы последовательностейЭтот вид диаграмм используется для точного определения логики сценария выполнения прецедента. Диаграммы последовательностей отображают типы объектов,

Слайд 160Диаграмма последовательности обработки заказа

Диаграмма последовательности обработки заказа

Слайд 161Кооперативные диаграммы
На кооперативных диаграммах объекты (или классы ) показываются в

виде прямоугольников, а стрелками обозначаются сообщения, которыми они обмениваются в

рамках одного варианта использования. Временная последовательность сообщений отражается их нумерацией.

Кооперативные диаграммыНа кооперативных диаграммах объекты (или классы ) показываются в виде прямоугольников, а стрелками обозначаются сообщения, которыми

Слайд 162Диаграммы состояний
Диаграммы состояний используются для описания поведения сложных систем. Они

определяют все возможные состояния, в которых может находиться объект, а

также процесс смены состояний объекта в результате некоторых событий. Эти диаграммы обычно используются для описания поведения одного объекта в нескольких прецедентах.

Диаграммы состоянийДиаграммы состояний используются для описания поведения сложных систем. Они определяют все возможные состояния, в которых может

Слайд 163Диаграммы деятельности
Диаграмма деятельности — это частный случай диаграммы состояний. На

диаграмме деятельности представлены переходы потока управления от одной деятельности к

другой внутри системы. Этот вид диаграмм обычно используется для описания поведения, включающего в себя множество параллельных процессов.


Диаграммы деятельности Диаграмма деятельности — это частный случай диаграммы состояний. На диаграмме деятельности представлены переходы потока управления от

Слайд 164На диаграмме деятельности могут быть представлены действия, соответствующие нескольким вариантам

использования. На таких диаграммах появляется множество начальных точек, поскольку они

отражают теперь реакцию системы на множество внешних событий.
Таким образом, диаграммы деятельности позволяют получить полную картину поведения системы и легко оценивать влияние изменений в отдельных вариантах использования на конечное поведение системы.

Любая деятельность может быть подвергнута дальнейшей декомпозиции и представлена в виде отдельной диаграммы деятельности или спецификации (словесного описания).

На диаграмме деятельности могут быть представлены действия, соответствующие нескольким вариантам использования. На таких диаграммах появляется множество начальных

Слайд 165Диаграммы компонентов
Диаграммы компонентов позволяют изобразить модель системы на физическом уровне.
Элементами

диаграммы являются компоненты — физические замещаемые модули системы. Каждый компонент

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

Диаграммы компонентовДиаграммы компонентов позволяют изобразить модель системы на физическом уровне.Элементами диаграммы являются компоненты — физические замещаемые модули

Слайд 166Диаграмма компонентов фрагмента КИС
Основное назначение диаграмм компонентов — разделение системы

на элементы, которые имеют стабильный интерфейс и образуют единое целое.

Это позволяет создать ядро системы, которое не будет меняться в ответ на изменения, происходящие на уровне подсистем.










Каждый компонент диаграммы при необходимости документируется с помощью более детальной диаграммы компонентов, диаграммы сценариев или диаграммы классов.


Диаграмма компонентов фрагмента КИСОсновное назначение диаграмм компонентов — разделение системы на элементы, которые имеют стабильный интерфейс и

Слайд 167Взаимосвязи между диаграммами UML

Взаимосвязи между диаграммами UML

Слайд 168Этапы проектирования ИС с применением UML
UML обеспечивает поддержку всех этапов

жизненного цикла ИС:

На этапе создания концептуальной модели для описания бизнес-деятельности

используются модели бизнес-прецедентов и диаграммы видов деятельности, для описания бизнес-объектов – модели бизнес-объектов и диаграммы последовательностей.

На этапе создания логической модели ИС описание требований к системе задается в виде модели и описания системных прецедентов, а предварительное проектирование осуществляется с использованием диаграмм классов, диаграмм последовательностей и диаграмм состояний.

На этапе создания физической модели детальное проектирование выполняется с использованием диаграмм классов, диаграмм компонентов, диаграмм развертывания.
Этапы проектирования ИС с применением UML UML обеспечивает поддержку всех этапов жизненного цикла ИС:На этапе создания концептуальной модели

Слайд 169Выбор способа проектирования ИС
При функциональной декомпозиции программной системы ее структура

описывается блок-схемами, узлы которых представляют собой "обрабатывающие центры" (функции), а

связи между узлами описывают движение данных.
При объектном разбиении в системе выделяются "активные сущности" – объекты (или компоненты), которые взаимодействуют друг с другом, обмениваясь сообщениями и выполняя соответствующие функции (методы) объекта.
Если при проектировании ИС разбивается на объекты, то для ее визуального моделирования следует использовать UML. Если в основу проектирования положена функциональная декомпозиция ИС, то UML не нужен и следует использовать рассмотренные ранее структурные нотации.


Выбор способа проектирования ИСПри функциональной декомпозиции программной системы ее структура описывается блок-схемами, узлы которых представляют собой

Слайд 170В О П Р О С Ы ?

В О П Р О С Ы ?

Похожие презентации

Software Engineering Software Engineering 236
Волейбол Волейбол 754
Basic Life Support ( BLS) Базовая Реанимация . Луганск 2016 Basic Life Support ( BLS) Базовая Реанимация . Луганск 2016 295
законы теплообмена законы теплообмена 497
Орган слуха Орган слуха 295
Ашы қ сабақ Ашы қ сабақ 679
Системное программирование для Microsoft.NET на языке C# Лекция 1 Системное программирование для Microsoft.NET на языке C# Лекция 1 215
Муниципальное образовательное учреждение дополнительного образования Муниципальное образовательное учреждение дополнительного образования 112
Интерактивная игра-дорожка Интерактивная игра-дорожка "Змейка" 296
Физические методы измерения вязкости жидкости Физические методы измерения вязкости жидкости 266
Разработка многопотоковых программ Разработка многопотоковых программ 251
Родительское собрание «Главное о ЕГЭ» Родительское собрание «Главное о ЕГЭ» 523
Ясенецкая библиотека - сельский информационный центр. Составитель Морева Ясенецкая библиотека - сельский информационный центр. Составитель Морева 153
Разбор клинического случая Разбор клинического случая 286
Подготовка к диагностической работе по русскому языку за курс 6 класса Подготовка к диагностической работе по русскому языку за курс 6 класса 225
Украинский язык и л итературное чтение. 2 класс Украинский язык и л итературное чтение. 2 класс 181
Кліматична система. Кліматичне моделювання Кліматична система. Кліматичне моделювання 251
Акушерские кровоточения во время беременности Акушерские кровоточения во время беременности 247
Соки и кумовство Соки и кумовство 254
Металлические яды Металлические яды 608

Обратная связь

Если не удалось найти и скачать доклад-презентацию, Вы можете заказать его на нашем сайте. Мы постараемся найти нужный Вам материал и отправим по электронной почте. Не стесняйтесь обращаться к нам, если у вас возникли вопросы или пожелания:

Email: Нажмите что бы посмотреть 

Что такое TheSlide.ru?

Это сайт презентации, докладов, проектов в PowerPoint. Здесь удобно  хранить и делиться своими презентациями с другими пользователями.

Для правообладателей

Яндекс.Метрика