2. Лекция: Содержание этапов ЖЦ ИС

кандидат технических наук, доцент

Грекул Владимир Иванович

Учебный курс

Проектирование информационных

систем

Лекция 2

2

Согласование, установление взаимосвязей

3

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

Процесс(исполни

тель процесса)

Действия Вход Результат

Приобретение(заказчик)

Инициирование Подготовка заявочных предложений Подготовка договора Контроль деятельности поставщика Приемка ИС

Решение о начале работ по внедрению ИС Результаты обследования деятельности заказчика Результаты анализа рынка ИС/тендера План поставки/разработки Комплексный тест ИС

Технико-экономическое обоснование внедрения ИС Техническое задание на ИС Договор на поставку/разработку Акты приемки этапов работы Акт приемо-сдаточных испытаний

4





Поставка(разработчик ИС)

Инициирование Ответ на заявочные предложения Подготовка договора Планирование исполнения Контроль исполнения Поставка

Техническое задание на ИС Решение руководства об участии в разработке Результаты тендера Техническое задание на ИС План управления проектом Разработанная ИС и документация

Решение об участии в разработке Коммерческие предложения/конкурсная заявка Договор на поставку/разработку План управления проектом Реализация/корректировка Акт приемо-сдаточных испытаний

5





Разработ-ка(разработчик ИС)

Подготовка Анализ требований к ИСПроектирование архитектуры ИС Разработка требований к ПОПроектирование архитектуры ПО Детальное проектирование ПО

Техническое задание на ИС Техническое задание на ИС, модель ЖЦ Техническое задание на ИС Подсистемы ИС Спецификации требования к компонентам ПО Архитектура ПО

Используемая модель ЖЦ, стандарты разработки План работ Состав подсистем, компоненты оборудования Спецификации требования к компонентам ПО Состав компонентов ПО, интерфейсы с БД, план интеграции ПО Проект БД, спецификации интерфейсов между компонентами ПО, требования к тестам

6


Процесс(исполните

ль процесса)


Разработка(разработчик ИС)

Кодирование и тестирование ПО Интеграция ПО и квалификационное тестирование ПО Интеграция ИС и квалификационное тестирование ИС

Материалы детального проектирования ПО План интеграции ПО, тесты Архитектура ИС, ПО, документация на ИС, тесты

Тексты модулей ПО, акты автономного тестирования Оценка соответствия комплекса ПО требованиям ТЗ Оценка соответствия ПО, БД, технического комплекса и комплекта документации требованиям ТЗ

7

Соответствие процессовГОСТ 34.601-90; "э.X.Y" - этап Y стадии X

ISO/IEC12207: 1995-08-01

Oracle CDM; Примечание

э.5.3 ТП, э.7.3 ВД. 1) Процесс приобретения разработчиком

нет в ГОСТ это приобретение планируется

нет 2) Процесс поставки нет CDM содержит процесс CV,

Все этапы ГОСТ34.601 кроме 8. Сп, а именно: 1. ФТ, 2. РК, 3. ТЗ, 4. ЭП, 5. ТП,6. РД, 7. ВД.

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

RD, ES, TA, DB, MD, (DO), TE, (TR), TS.

аналог есть в ГОСТ (э.7.5 ВД и ранее), в ISO аналога нет в явном виде. Процессы DO TR из CDM указаны в скобках, так как они отражены и в других стандартах ГОСТ34 и процессах ISO12207.

8

Соответствие процессов

ГОСТ 34.601-90; "э.X.Y" - этап Y стадии X

ISO/IEC12207: 1995-08-01

Oracle CDM; Примечание

нет 4) Процесс эксплуатации

нет По ISO организация-оператор разрабатывает план и гарантирует соответствие плану

8. Сп., развитие АС - по пункту.1.3 ГОСТ 34.601.

5) Процесс сопровождения

PS ISO предполагает развитие как элемент сопровождения, вызывающий новый процесс разработки, в CDM в этом смысле полномасштабное развитие не предусмотрено

9

Распределение процессов по стадиям ЖЦ (ISO/IEC 12207)

Формирование требований

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

Реализация Тестирование

Ввод в действие

Сопровождение

Снятие

Инициирование

Заявочные предл.

Договор

Надзор за деятельностью поставщика

Приемка и завершение

Процесс «ПРИОБРЕТЕНИЕ»Процесс «ПРИОБРЕТЕНИЕ»

Процесс «ПОСТАВКА»Процесс «ПОСТАВКА»

Инициирование

Ответ на ЗП

Договор

Планирование

Выполнение и контроль

Проверка и оценка

Поставка и завершение

10

Распределение процессов по стадиям ЖЦ

Формирование требований

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

Реализация Тестирование

Ввод в действие

Сопровождение

Снятие

Подгот. работа

Квалификационное тестирование ПО

Кодирование и тестир. ПО

Интеграция

Процесс «РАЗРАБОТКА»Процесс «РАЗРАБОТКА»

Анализ требований к системе

Интеграция ИС

Установка

Приемка

Проектиров. архитектуры

Детальное проектиров.

Квалификационное тестирование ИС

11

Процессы CDM•RD - Определение производственных требований,

•ES - Исследование существующих систем,

•TA - Определение технической архитектуры,

•DB - Проектирование и построение БД,

•MD - Проектирование и реализация модулей,

•CV - Конвертирование данных,

•DO - Документирование,

•TE - Тестирование,

•TR - Обучение,

•TS - Переход к новой системе,

•PS - Поддержка и сопровождение.

12

Последовательности задач

RD.020 – RD.030 – RD.070 – BR.020 – BR.080 – MD.020 – MD.060 – DO.070 – TE.110 – PM.050 – CV.140 – PM.080, где

•RD.020 – изучение существующих бизнес-процессов

•RD.030 – моделирование будущих бизнес-процессов

•RD.070 – выявление детальных требований к будущим бизнес-процессам

•BR.020 – отображение бизнес-процессов в функциональность приложения

•BR.080 – тестирование принятых решений

13

Последовательности задач

RD.020 – RD.030 – RD.070 – BR.020 – BR.080 – MD.020 – MD.060 – DO.070 – TE.110 – PM.050 – CV.140 – PM.080, где

•MD.020 – оценка решений по доработке функциональности приложения

•MD.060 – дизайн расширений функциональности приложения

•DO.070 – разработка инструкций пользователя

•TE.110 – тестирование приложения

•PM.050 – установка приложения на систему периода эксплуатации

•CV.140 – ввод начальных данных

•PM.080 – запуск новой системы

14

Доработка

AIM разделяет доработку:

•при «нехватке» возможностей приложения, касающихся функциональности

•при «нехватке» возможностей приложения, касающихся отчетов

•при «нехватке» возможностей приложения по предоставлению/ограничению доступа к функциям и данным,

•при разработке программ автоматической конвертации (программ переноса бизнес-данных в новое приложение).

15

Доработка

Доработка основного функционала

BR.020 – BR.080 – MD.020

•BR.020 – выявление «дыр» функциональности приложения, предварительное формулирование решения, как можно устранить «дыры»

•BR.080 – первоначальная оценка предложенного предварительного решения

•MD.020 – окончательное формулирование решения, как можно устранить «дыры», оценка трудозатрат

16

Характеристики стандартов

конкретности и детализации содержащихся требований;

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

степени обязательности для организаций разного типа;

прикладной области

Стандарты различаются по:

17

Методика Oracle CDM

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

Ориентирован на поддержку деятельности разработчика.

18

Степень адаптивности- ограничивается тремя разновидностями каскадной модели ЖЦ: "классическая""классическая" (предусмотрены все работы/задачи и этапы), "быстрая разработка""быстрая разработка" (Fast Track) (еще более сильно ориентированная на использование инструментов моделирования и

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

Методика не предусматриваетне предусматривает:

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

удаление задачи (и порождаемых ею документов);

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

19

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

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

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

20

ISO 12207

Равносильно ориентирован на организацию действий каждой из двух сторон: поставщик (разработчик) и покупатель (пользователь).

Определяет процессы ЖЦ. Состоит из крупных обобщенных процессов: "приобретение", "поставка", "разработка" и т. п.

Каждый процесс разделен на набор действий, каждое действие - на набор задач.

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

Заранее определенных последовательностей нет. !

На первый взгляд неконкретный, но вполне новый и отчасти "модный" стандарт.

21

Степень адаптивности

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

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

Позволяет реализовывать любую модель ЖЦ - один процесс при необходимости вызывает другой или его часть

22

Степень обязательности

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

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

Стандарт ориентирован на различные виды ПО и типы проектов АС, куда ПО входит как часть;содержит предельно мало описаний, направленных на проектирование БД.

23

Стандарты комплекса ГОСТ 34

Комплекс стандартов рассчитан на взаимодействие заказчика и разработчика.

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

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

Наиболее распространены: ГОСТ 34.601-90 (Стадии создания АС), ГОСТ 34.602-89 (ТЗ на создание АС), методические указания РД 50-34.698-90 (Требования к содержанию документов).

24

Степень адаптивностиопределяется возможностями:

1. опускать стадию эскизного проектирования и объединять стадии "Технический проект" и "Рабочая документация";

2. опускать этапы, объединять и опускать большинство документов и их разделов;

3. вводить дополнительные документы, разделы документов и работы;

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

25

Степень обязательности

Объектами стандартизации являются автоматизированные системы различных (любых!) видов и все виды их компонентов (а не только ПО и БД):

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

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

Прежняя полная обязательность отсутствует, материалы ГОСТ34 по сути стали методической поддержкой, причем чаще для заказчиков, имеющих в стандарте набор требований к содержанию ТЗ и проведению испытаний АС.

26

Waterfall model(модель водопада)

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

27

Incremental model

(модель расширения системы)

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

28

Evolutionary model (эволюционная модель)

Разработка осуществляется при постоянном уточнении требований

29

Моделирование функциональной области внедрения ИС

1. Моделирование – основа проектирования ИС

2. Основные подходы к разработке моделей

3. Задачи моделирования бизнес-процессов

4. Структурное моделирование БП

30

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

Подготовка к внедрению корпоративной информационной системы

Проведение реорганизации деятельности предприятия (реинжиниринг)

Подготовка предприятия к сертификации по стандартам ISO 9000

31

1. Моделирование – основа проектирования ИС

32

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

МоделиМодели:

организации,

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

требований к ИС,

проекта ИС,

требований к приложениям и т.д.

33

Виды моделей

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

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

Описывает

Описывает иерархическую

иерархическую

структуру,

структуру, «вертикальные»

«вертикальные»

отношения в компании

отношения в компании

Описывает

Описывает

«горизонтальные»

«горизонтальные»

отношения

отношения

34

Организационно-функциональная модель

Функция – это обособленный вид деятельности компании. Функции выполняются постоянно.

35

Шаблон распределения функций по

организационным звеньям Определяет

Определяет состав и

состав и распределение

распределение

рабочих мест

рабочих мест

пользователей

пользователей

ИСИС

36

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

Определяет требования к ИС

требования к ИС

в части

в части обеспечения

обеспечения деятельности

деятельности

предприятия

предприятия

37

2. Основные подходы к разработке моделей

38

Цикл реструктуризацииПродуктовая

модель

Фун

кц

ион

аль

ная

мод

ель

+

+

+

+

++

+

Фун

кц

ион

аль

ная

мод

ель

Организационная модель

+

+

+

+

+++

+ + +

Проверка на соответствие

39

Фрагменты организационно-функциональной модели – основные функции

40

Фрагменты организационно-функциональной модели – организационная структура

41

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

42

3. Задачи моделирования бизнес-процессов

43

Определение бизнес-процесса

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

Получение товара по заказу

Прием заявкиПроверка наличия

Выписка счета

Контроль платежа

Доставка товара

СкладОтдел продаж

Бухгалтерия БухгалтерияТранспортный отдел

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

44

Обобщенная модель бизнес-процесса

Организация Подразделение

Работник

Вход ВыходРесурсы:

• Сырье

• Промежуточная продукция

• Информация

• Деньги

Преобразование ресурсов,

добавляющее стоимость

Продукты:

• Топливо

• Прибор

•Счет-фактура

• Промежуточная продукция

• Информация

Бизнес-процессы

Бизнес-процесс – модель преобразования сущностей типа «вход-выход», рассматриваемая как работа по реализации предписываемой функции

45

Задачи моделирования бизнес-процессов

Описание выполняемых системой функцийфункций

Описание отношений между даннымиданными

Описание динамического поведенияповедения системы

46

Технологии и инструментальные средства моделирования бизнес-процессов.

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

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

Технология Технология ArisAris – управляемые событиями модели

Программные средства: IDEF Designer, ERwin\BPwin, Oracl Designer, BPM Workbench, Aris, Rational Rose

47

Принять заявку

Карты Харрингтона (BFD – Block Flow Diagrams)

Начало

Начало

Принять заявку

Проверить заявку

Рассчитать платеж

Оформить договор

Получить платеж

Конец

Формализуют следующие знания о бизнес-процессе:

Состоит из

Является частью

Следует за

Предшествует

48

Стандарты IDEF (Integrated Computer Aided

Manufacturing DEFinition) (1981г)

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

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

IDEF1X (IDEF1 еХtended) – методология построения реляционных структур. IDEF1X относится к типу методологий “Сущность-взаимосвязь” (ER – Entity-Relationship) и используется для моделирования реляционных баз данных в системе;

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

IDEF4 – методология построения объектно-ориентированных систем.

49

4. Структурное моделирование БП

50

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

Сложность больших систем преодолевается расчленением их на части

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

Критерии разбиения системы на «черные ящики»:

каждый «черный ящик» реализует единственную функцию системы;

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

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

связи между «черными ящиками» должны быть максимально простыми

51

Функциональная модель SADT(Structured

Analysis and Design Teqnique) (IDEF0)

отображает действия объекта и связи между этими действиями

Функция

Управление

ВыходВход

Механизм

(Нотация Росса)

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

52

Декомпозиция функциональных диаграмм

Подфункция

функция

Подфункция 1

Подфункция 1Подфункция 2


А0

А1

А2

А3

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

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

Выход

Выход


Вход

53

Контекстная диаграмма-диаграмма самого высокого уровня.

Определяет

- общее представление о деятельности организации

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

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

54

Перенос контекста на декомпозицию

Продажа, маркетинг

Сборка, тестирование

55

декомпозиция

56

Преобразование типов стрелок


Выход

Вход

Выход

Появление новых стрелок, отсутствующих на родительской диаграмме, отображается «туннелем»

57

Декомпозиция родительской диаграммы А2


А2

А21

А22А23

А24

58

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

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

Для моделирования бизнес-функции обычно достаточно 2-3 уровней детализации.

Общее число уровней в модели обычно не превышает 6-7.

59

Оценка бизнес-процессов

Функционально-стоимостной анализ АВС (Activity Based Costing) – методика определения характеристик товаров и услуг на базе действий и ресурсов, задействованных во всех бизнес-процессах предприятия

Этапы АВС-анализа:

Формирование перечня ресурсов и стоимостных объектов («центров затрат»)

Определение затрат на выполнение бизнес-задач (расходы ресурсов – прямые затраты материалов и труда, косвенные затраты труда и накладные расходы)

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

2. Лекция: Содержание этапов ЖЦ ИС

Technology