Лекция_4_Семестр_1_Анализ_стандартов

1. Анализ стандартов

1

2.

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

3.

Упрощенная картина группировки стандартов и схожих
методических материалов:
по предмету стандартизации:
-функциональные стандарты (стандарты на языки
программирования, интерфейсы, протоколы)
-стандарты на организацию Жизненного Цикла (ЖЦ)
создания и использования Автоматизированных Систем
(АС) и Программного Обеспечения (ПО);
3

4.

по утверждающей организации:
- официальные международные стандарты,
- официальные
национальные
или
национальные
ведомственные (например ГОСТы, ANSI, IDEF0/1),
- стандарты международных консорциумов и комитетов по
стандартизации (OSF, OMG, ранее широко известный
CODASYL)
- стандарты "де-факто" (таким долгое время был SQL или
язык диаграмм SADT Д. Росса),
- фирменные стандарты (Microsoft, IBM и др.);
4

5.

по методическому источнику:
-методические материалы фирм-разработчиков ПО,
фирм-консультантов, научных центров, консорциумов
по стандартизации (например, Oracle)
они могут называться по-разному - например,
"Метод", "Методология", "Подход", "Модель".
5

6.

Результаты небольшого опроса среди практиков-разработчиков и
руководителей (как проектов, так и софтверных фирм), но также
поставщиков ПО, внедренцев, конечных пользователей:
1) Разработчики-программисты чаще рассматривали ГОСТы или другие
стандарты на ЖЦ, т. е. на организацию разработки ПО, как
нежизненные материалы, мешающие в практической работе, которая
слишком часто сегодня идет не так, как планировалось вчера.
Требования к обеспечению качества ПО, включающие несколько видов
внутреннего контроля, характеризовались некоторыми респондентами
как мазохизм особого рода, который может быть теоретически хорош,
но на который в реальной жизни нет времени. Внешний контроль
рассматривался как вмешательство во внутреннюю кухню и не
приветствовался.
6

7.

2) Многие разработчики, в первую очередь - аналитики, выполнившие и
оформившие несколько проектов по какому-либо стандарту или
методике и за счет этого накопившие свой набор образцов проектной
документации, говорили о той пользе, которую дает использование
этих образцов в качестве шаблонов:
3) Руководители проектов чаще считали стандарты на ЖЦ полезными
или даже необходимыми, рассматривая их в первую очередь как
средство организации управления разработкой.
4) Самое осознанное стремление к использованию стандартов и
методик
с
максимальным
использованием
предусмотренных
требований, типов документов и действий по обеспечению качества
демонстрировали грамотные и опытные заказчики/покупатели ПО и
АС и внедренцы этих систем.
5) Конечным пользователям (настоящим, а не программистам или
начальникам) важно было только "чтобы работало правильно, было
удобно и не ломалось".
7

8.

ГОСУДАРСТВЕННЫЙ СТАНДАРТ СОЮЗА ССР
ГОСТ 34.601-90
Комплекс стандартов на автоматизированные системы
АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. СТАДИИ
СОЗДАНИЯ.
Information technology. Set of standards for automated systems.
Stages of development.
Дата введения 01.01.1992г.
Заменен на следующий стандарт:
8

9.

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

10.

10

11.

11

12.

12

13.

13

14.

14

15.

15

16.

16

17.

17

18.

18

19.

19

20.

20

21.

21

22.

22

23.

23

24.

24

25.

25

26.

26

27.

27

28.

28

29.

29

30.

30

31.

Ссылка на сайт с рекомендациями, шаблонами, примерами
разработки ТЗ и других программных документов:
http://www.rugost.com
(вкладка Статьи)
31

32.

32

33.

33

34.

34

35.

35

36.

36

37.

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

38.

38

39.

39

40.

40

41.

41

42.

42

43.

43

44.

44

45.

45

46.

46

47.

47

48.

48

49.

49

50.

50

51.

51

52.

52

53.

ГОСТ Р ИСО/МЭК 12207-2010
Информационная технология.
ПРОЦЕССЫ ЖИЗНЕННОГО ЦИКЛА ПРОГРАММНЫХ
СРЕДСТВ
Information technology. Software life cycle processes,
Настоящий стандарт применяется при приобретении систем,
программных продуктов и оказании соответствующих
услуг; а также при поставке, разработке, эксплуатации и
сопровождении программных продуктов и программных
компонентов программно-аппаратных средств, как в самой
организации, так и вне ее.
Стандарт содержит также те аспекты описания системы,
которые необходимы для обеспечения понимания сути
программных продуктов и услуг.
53

54.

Стандарт
является
аутентичным
переводом
международного стандарта ISO/IEC 12207 - 2008 «System
and software engineering - Software life cycle processes».
Стандарт определяет стратегию и общий порядок в
создании и эксплуатации ПО. Он ориентирован на
различные виды ПО и типы проектов АС, куда ПО входит
как часть.
54

55.

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

56.

Каждый из процессов ЖЦ в пределах этих групп описывается
в терминах цели и желаемых выходов, списков действий и
задач, которые необходимо выполнять для достижения этих
результатов. Группы процессов стандарта:
1)процессы соглашения (2 процесса);
2)процессы организационного обеспечения проекта (5
процессов);
3)процессы проекта (7 процессов);
4)технические процессы (11 процессов);
5)процессы реализации ПС (7 процессов);
6)процессы поддержки ПС (8 процессов);
7)процессы повторного применения ПС (3 процесса).
56

57.

57

58.

58

59.

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

60.

Группа процессов реализации ПС включает в себя:
- процесс анализа требований к ПС;
- процесс проектирования архитектуры ПС;
- процесс детального проектирования ПС;
- процесс конструирования ПС;
- процесс комплексирования ПС;
- процесс квалификационного тестирования ПС.
Для каждого из выделенных процессов в стандарте
определяется цель, выходы, виды деятельности и задачи.
Степень адаптивности стандарта - максимальная.
Адаптация поддерживается возможностью исключения
процессов, видов деятельности и задач, не применяемых в
конкретном проекте. Такой характер позволяет реализовывать
любую модель ЖЦ.
60

61.

Содержание основных процессов ЖЦ ПО ИС (ISO/IEC 12207)
Процесс
(исполнитель
процесса)
Приобретение
(заказчик)
Действия
Вход
Результат
Инициирование
Решение о начале работ по
внедрению ИС
Подготовка заявочных
предложений
Результаты обследования
деятельности заказчика
Технико-экономическое
обоснование внедрения
ИС
Техническое задание на
ИС
Подготовка договора
Результаты анализа рынка
ИС/ тендера
Договор на поставку/
разработку
План поставки/
разработки
Акты приемки этапов
работы
Комплексный тест ИС
Акт приемно-сдаточных
испытаний
Контроль деятельности
поставщика
Приемка ИС
61

62.

Содержание основных процессов ЖЦ ПО ИС (ISO/IEC 12207)
Процесс
(исполнитель
процесса)
Поставка
(разработчик
ИС)
Действия
Вход
Результат
Инициирование
Техническое задание на ИС
Решение об участии в
разработке
Ответ на заявочные
предложения
Решение руководства об
участии в разработке
Коммерческие
предложения/ конкурсная
заявка
Подготовка договора
Результаты тендера
Договор на поставку/
разработку
Планирование исполнения
Техническое задание на
ИС
План управления
проектом
Контроль исполнений
Поставка ИС
План управления
проектом
Разработанная ИС и
документация
Реализация/
корректировка
Акт приемно-сдаточных
испытаний
62

63.

Процесс
(исп.проц.)
Разработка
(разработчик
ИС)
Действия
Вход
Результат
Подготовка
Техническое задание на ИС
Анализ требований к
ИС
Техническое задание на ИС,
модель ЖЦ
Проектирование
архитектуры ИС
Техническое задание на ИС
Состав подсистем,
компоненты оборудования
Разработка
требований к ПО
Подсистемы ИС
Спецификации требования к
компонентам ПО
Проектирование
архитектуры ПО
Спецификации требования к
компонентам ПО
Детальное
проектирование ПО
Архитектура ПО
Состав компонентов ПО,
нтер-фейсы с БД, план
интеграции ПО.
Проект БД, спецификации
интерфейсов между компонентами ПО, требования к тестам.
Используемая модель ЖЦ,
стандарты разработки.
План работ
Кодирование и
тестирование ПО
Материалы детального
проектирования ПО
Тексты модулей ПО, акты
автономного тестирования
Интеграция ПО и
квалификационное
тестирование ПО
План интеграции ПО, тесты
Оценка соответствия
комплекса ПО требованиям ТЗ
Интеграция ИС и
квалификационное
тестирование ИС
Архитектура ИС, ПО,
документация на ИС, тесты
Оценка соответствия ПО, БД,
технического комплекса и
63
комплекта документации
требованиям ТЗ

64.

Вопросы применения ГОСТ Р ИСО/МЭК 12207-2010 более
широко раскрыты в стандартах:
• ГОСТ Р ИСО/МЭК ТО 15271-2002 «Руководство по
применению ГОСТ Р ИСО/МЭК 12207»;
• ГОСТ Р ИСО/МЭК ТО 16326-2002 «Руководство по
применению ГОСТ Р ИСО/МЭК 12207 при управлении
проектом».
• ГОСТ Р ИСО/МЭК 14764-2002 «Информационная
технология. Сопровождение программных средств»
64

65.

ГОСТ Р ИСО/МЭК ТО 15271-2002
Информационная технология.
РУКОВОДСТВО ПО ПРИМЕНЕНИЮ ГОСТ Р ИСО/МЭК
12207 (ПРОЦЕССЫ ЖИЗНЕННОГО ЦИКЛА
ПРОГРАММНЫХ СРЕДСТВ)
Настоящий стандарт содержит рекомендации по применению
ГОСТ Р ИСО/МЭК 12207.
В стандарте основное внимание уделено особенностям,
подлежащим учету при прикладном применении ГОСТ Р
ИСО/МЭК 12207 в условиях реальных проектов создания
программных средств. Приведенные в настоящем
стандарте рекомендации не касаются обсуждения
обоснованности требований ГОСТ Р ИСО/МЭК 12207.
В стандарте рассмотрены три основополагающие модели
жизненного цикла и приведены примеры прикладного
применения ГОСТ Р ИСО/МЭК 12207.
65

66.

ГОСТ Р ИСО/МЭК ТО 16326-2002
Программная инженерия.
РУКОВОДСТВО ПО ПРИМЕНЕНИЮ ГОСТ Р ИСО/МЭК
12207 ПРИ УПРАВЛЕНИИ ПРОЕКТОМ
Настоящий стандарт уточняет и дополняет ГОСТ Р
ИСО/МЭК 12207 в части процесса управления.
Настоящий стандарт предназначен для лиц, отвечающих за
управление реализацией основных процессов по ГОСТ Р
ИСО/МЭК 12207: заказа, поставки, разработки,
эксплуатации и сопровождения.
66

67.

ГОСТ Р ИСО/МЭК 14764-2002
Информационная технология.
СОПРОВОЖДЕНИЕ ПРОГРАММНЫХ СРЕДСТВ
Стандарт уточняет требования к процессу сопровождения программных
средств. Сопровождение программных средств является одним из
основных процессов их жизненного цикла, что описано в ГОСТ Р
ИСО/МЭК 12207.
Из-за ограничений в стоимости и сроках разработки, а также отсутствия
опыта в применении ГОСТ Р ИСО/МЭК 12207 программные средства
нередко поставляют в «сыром» виде. Поэтому возникает необходимость в
последующей корректировке ошибок, обнаруженных при их
эксплуатации. Часто необходимо модернизировать программное
средство, чтобы удовлетворить изменившимся требованиям
пользователя. Сопровождение программного средства может в
стоимостном выражении составлять наибольшую часть жизненного
цикла.
Настоящий стандарт содержит рекомендации по планированию
сопровождения и сопровождению программных продуктов (средств) и
услуг. Стандарт не распространяется на эксплуатацию программных
средств.
67

68.

Стандарт ГОСТ Р ИСО/МЭК 15288-2005.
СИСТЕМНАЯ ИНЖЕНЕРИЯ.
ПРОЦЕССЫ ЖИЗНЕННОГО ЦИКЛА СИСТЕМ
К разработке стандарта были привлечены специалисты
различных
областей:
системной
инженерии,
программирования, управления качеством, человеческими
ресурсами, безопасностью и пр. Был учтен практический
опыт создания систем в правительственных, коммерческих,
военных и академических организациях.
Стандарт устанавливает общие основы для описания ЖЦ
систем,
созданных
людьми,
определяет
детально
структурированные
процессы
и
соответствующую
терминологию. Стандарт применим к полному ЖЦ системы.
68

69.

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

70.

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

71.

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

72.

Модель ЖЦ собирается в виде последовательности стадий,
которые могут перекрываться или повторяться в зависимости
от сферы применения рассматриваемой системы, от ее
размеров, сложности, изменяющихся потребностей и
возможностей.
В качестве примера модели ЖЦ в стандарте приведены
следующие шесть стадий:
1) стадия замысла;
2) стадия разработки;
3) стадия производства;
4) стадия применения;
5) стадия поддержки применения;
6) стадия прекращения применения и списания.
72

73.

Каждая из этих стадий описана в стандарте, определены
их цели и результаты.
Также в стандарте представлено соотношение процессов,
описанных в стандарте ИСО/МЭК 15288, и процессов,
описанных в Изменении №1 к ИСО/МЭК 12207.
Область действия, акценты, структура и детали этих
документов являются различными, однако применение и
описание
системных
принципов
осуществляется
аналогичным образом в виде процессов, используемых для
построения моделей ЖЦ.
73

74.

Обзор фирменных методологий и технологий
Методика Oracle CDM (Custom Development Method) конкретный материал, детализированный до уровня
заготовок проектных документов, рассчитанных на прямое
использование в проектах с опорой на инструментарий
Oracle. Фактической ориентацией методики является ее
направленность на создание ИС с базами данных в
достаточно традиционном понимании.
ЖЦ формируется из определенных этапов проекта и
процессов, каждый из которых выполняется в течение
нескольких этапов.
74

75.

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

76.

Процессы:
RD - Определение производственных требований;
ES - Исследование существующих систем;
TA - Определение технической архитектуры;
DB - Проектирование и построение БД;
MD - Проектирование и реализация модулей;
CV - Конвертирование данных;
DO – Документирование;
TE – Тестирование;
TR – Обучение;
TS - Переход к новой системе;
PS - Поддержка и сопровождение.
76

77.

Степень адаптивности CDM ограничивается тремя
моделями ЖЦ:
«классическая» (предусмотрены все работы/задачи и этапы);
«быстрая разработка» (Fast Track), еще более сильно
ориентированная
на
использование
инструментов
моделирования и программирования Oracle;
«облегченный подход», рекомендуемый в случае малых
проектов
и
возможности
быстро
прототипировать
приложения.
Все модели ЖЦ являются по сути каскадными, даже
«облегченный
подход»,
несмотря
на
понятную
итерационность выполнения действий по прототипированию,
сохраняет общий последовательный и детерминированный
порядок выполнения задач.
77

78.

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

79.

79

80.

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

81.

Суть работы в рамках RUP - это создание и сопровождение
моделей на базе языка моделирования Unified Modeling
Language (UML), являющегося международным стандартом.
В основе развития инструментов и процессов Rational лежат
следующие ключевые концепции:
адаптация процесса под проект;
управление запросами заинтересованных лиц;
организация
взаимодействия
удаленных
команд
разработчиков;
итерационный подход к разработке;
повышение уровня абстрагирования;
непрерывное повышение качества.
81

82.

Методология MSF (Microsoft Solution Framework)
разработки и внедрения IT-решений. Особенность этой
методологии состоит в том, что благодаря своей гибкости и
отсутствию жестко навязываемых процедур она может быть
применена при разработке весьма широкого круга ITпроектов. Эта модель сочетает в себе свойства двух моделей
ЖЦ: каскадной и спиральной.
Модель ЖЦ MSF также рассматривали в лекции 3
(слайды 21-26)
82

83.

Модель процессов включает такие основные фазы
процесса разработки:
Выработка концепции (Envisioning);
Планирование (Planning);
Разработка (Developing);
Стабилизация (Stabilizing);
Внедрение (Deploying).
Кроме
этого
существует
большое
количество
промежуточных вех, которые показывают достижение в
ходе проекта определенного прогресса и разделяют
большие сегменты работы на меньшие участки.
83

84.

Методология организационного планирования BSP
(Business System Planning)
Значительный вклад в теорию проектирования и разработки
ИС внесла компания IBM, предложив еще в середине 1970-х
годов.
Метод структурирования информации с использованием
матриц пересечения бизнес-процессов, функциональных
подразделений, функций систем обработки данных
(информационных систем), информационных объектов,
документов и баз данных, предложенный в BSP, используется
сегодня не только в ИТ-проектах, но и в проектах по
реинжинирингу
бизнес-процессов,
изменению
организационной структуры.
84

85.

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