819.47K

Categories:

informatics

software

Жизненный цикл программного обеспечения (тема 2)

1.

Основы проектирования ПО
Куликова Елена Васильевна

2.

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

2.1. Стандартизация жизненного цикла
программных средств
Стандарт (наименование)
Принятие
Описание
ISO/IEC 12207:2008
Информационная технология.
Системная и программная
инженерия. Процессы жизненного
цикла программных средств.
В 2008 г. Международной
организацией по
стандартизации ISO
(стандарт был рассмотрен
и затем подтвержден в
2013 г.)
стандарт ISO описывающий процессы жизненного
цикла программного обеспечения;
основной
в
данном
направлении
международный стандарт
ГОСТ Р ИСО/МЭК 12207-2010
Информационная технология.
Системная и программная
инженерия. Процессы жизненного
цикла программных средств.
Принят и введен в
действие постановлением
Госстандарта РФ от
ГОСТ Р ИСО/МЭК ТО 15271-2002
Информационная технология.
Руководство по применению
ГОСТ ИСО/МЭК 12207
(Процессы жизненного цикла
программных средств)
Принят и введен в
действие постановлением
Госстандарта РФ от
идентичен ISO/IEC 12207:2008;
устанавливает общую структуру процессов
жизненного цикла программных средств, на
которую можно ориентироваться в программной
индустрии;
определяет процессы, виды деятельности и
задачи, которые используются при приобретении
программного продукта или услуги, а также при
поставке, разработке, применении по назначению,
сопровождении и прекращении применения
программных продуктов.
содержит рекомендации по применению ГОСТ Р
ИСО/МЭК 12207
01.03.2012
5.06.2002 г.
Есть еще стандарт ГОСТ 34.601-90, в котором описаны стадии и этапы создания
автоматизированной системы (АС)
3

4.

2.2. Жизненный цикл программных средств и его
составляющие
4

5.

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

6.

Состав ЖЦ
ЖЦ ПС состоит из процессов.
Каждый процесс ЖЦ разделен на набор работ.
Каждая работа разделена на набор задач.
ЖЦ
Процесс 1
Работа 1
Работа 2
Процесс 2
Работа N
Работа 1
Работа 2
Процесс N
Работа N
Работа 1
Работа 2
Работа N
Задача 1
Задача 1
Задача 1
Задача 1
Задача 2
Задача 2
Задача 2
Задача 2
Задача N
Задача N
Задача N
Задача N

7.

Процессы ЖЦ (3 группы)
Процессы
ЖЦ
основные
вспомогательные
организационные

8.

2.3. Основные процессы жизненного цикла
8

9.

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

10.

Основные процессы (всего 5)
1.
2.
3.
4.
5.
Заказ;
Поставка;
Разработка;
Эксплуатация;
Сопровождение.

11.

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

12.

Процесс разработки (13 работ, системные и
программные)
Работа
Задачи
1)
подготовка
процесса разработки
Выбирается модель ЖЦ ПС и систем. В данную модель структурируются процессы, работы и
задачи стандарта СТБ ИСО/МЭК 12207–2003.
Выбираются и адаптируются стандарты, методы, инструментальные средства разработки, языки
программирования.
Формируется план проведения работ процесса разработки.
2) анализ требований
к системе
Анализируется область применения системы.
На основании результатов анализа предметной области определяются требования к ней.
Выполняется оценка разработанных требований.
3)
проектирование
системной
архитектуры
Определяется общая архитектура системы. Осуществляется распределение требований к системе
между объектами технических и программных средств архитектуры и ручными операциями.
Производится дальнейшее уточнение требований. Осуществляется оценка архитектуры системы
и требований к объектам архитектуры.
4) анализ требований
к
программным
средствам;
Анализируется назначение программного средства. Исходя из результатов анализа определяются
и уточняются требования к программному средству. Выполняется оценка разработанных
требований.
5)
проектирование
программной
архитектуры;
Разрабатывается эскизный проект программного средства. Требования к программному средству
преобразуются в его архитектуру, распределяются между
его компонентами и уточняются далее. Производится оценка результатов эскизного
проектирования.
6)
техническое
проектирование
программных
средств;
Осуществляется детальное проектирование программного средства (разрабатывается
технический проект для компонентов программного объекта).
Компоненты проектируются до уровня их представления в виде набора программных модулей.
Сложность модулей должна обеспечить возможность их непосредственного кодирования в
следующей работе (работе 7).
Производится распределение технических требований к компонентам между программными
модулями и дальнейшее уточнение требований.
Выполняется оценка технического проекта.

13.

Процесс разработки (13 работ, системные и
программные)
Работа
Задачи
7)
программирование и
тестирование
программных
средств;
Производится кодирование и тестирование программных модулей. Осуществляется оценка
полученных результатов программирования и тестирования.
8)
сборка
программных
средств;
Производится сборка программных модулей и компонентов в программное средство и
тестирование промежуточных и конечных результатов сборки. Выполняется оценка результатов
сборки и тестирования.
9)
квалификационные
испытания
программных
средств;
Проводятся квалификационные испытания программного средства в моделируемой среде с
моделируемыми исходными данными.
Оцениваются результаты испытаний.
При необходимости производится доработка программного продукта.
10) сборка системы;
Осуществляется сборка объектов программной и технической конфигурации, ручных операций,
других подсистем в единую систему.
Проводятся испытания собранной системы.
Выполняется оценка собранной системы.
11)
квалификационные
испытания системы;
проводятся квалификационные испытания собранной системы в моделируемой
среде с моделируемыми исходными данными. По результатам испытаний выполняется оценка системы и при необходимости доработка программного
продукта.
12) ввод в действие
программных средств;
Программный продукт вводится в действие в среде эксплуатации.
13)
обеспечение
приемки
программных средств
Обеспечивается проведение заказчиком приемочных испытаний. Программный продукт
поставляется заказчику.

14.

2.4. Вспомогательные процессы жизненного цикла
14

15.

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

16.

Вспомогательные процессы жизненного
цикла:
1.
2.
3.
4.
5.
6.
7.
8.
документирование;
управление конфигурацией;
обеспечение качества;
верификация;
аттестация;
совместный анализ;
аудит;
решение проблем.

17.

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

18.

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

19.

Процесс управления конфигурацией
включает действия
подготовительную работу, заключающуюся в планировании управления
конфигурацией;
идентификацию конфигурации, устанавливающую правила, с помощью которых
однозначно идентифицируются компоненты ПО и их версии. При этом каждому
компоненту однозначно соответствует комплект документации;
контроль конфигурации – действие, предназначенное для систематической
оценки предлагаемых модификаций ПО и координированной их реализации с
учетом эффективности каждой модификации и затрат на ее выполнение;
учет состояния конфигурации, представляющий собой регистрацию состояния
компонентов ПО. Обеспечивает подготовку отчетов о реализованных и
отвергнутых модификациях версий компонентов ПО. Совокупность отчетов дает
однозначное отражение текущего состояния системы и ее компонентов, а также
обеспечивает ведение истории модификаций;
оценку конфигурации, заключающуюся в определении функциональной
полноты компонентов ПО, а также соответствия их физического состояния
текущему техническому описанию;
управление выпуском и поставку, охватывающие изготовление эталонных
копий программ и документации, их хранение и поставку пользователям в
соответствии с порядком, принятом в организации.
1.
2.
3.
4.
5.
6.
19

20.

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

21.

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

22.

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

23.

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

24.

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

25.

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

26.

2.5. Организационные процессы
жизненного цикла
26

27.

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

28.

Организационные процессы
жизненного цикла
1.
2.
3.
4.
управление;
создание инфраструктуры;
усовершенствование;
обучение.

29.

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

30.

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

31.

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

32.

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

33.

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

34.

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

35.

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

36.

2.6. Виды моделей жизненного цикла
Существующие модели ЖЦ определяют порядок исполнения этапов в ходе
разработки, а также критерии перехода от этапа к этапу
Модели ЖЦ
каскадные
модели
спиральные
модели
модели быстрой
разработки
приложений
36
инкрементные
модели

37.

2.6.1. Каскадные модели жизненного
цикла, ее характеристики
37

38.

Характеристики, преимущества,
недостатки
38

39.

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

40.

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

41.

По каскадной схеме разрабатываются
системы, обладающие недостатками:
Монолитность
Централизованность
Трудность использования
41

42.

Варианты каскадной модели
Каскадные
модели
Классическая
каскадная
модель
Каскадная
модель с
обратными
связями
Каскадная
модель по ГОСТ
Р ИСО/МЭК ТО
15271–2002
42
V-образная
модель

43.

Классическая каскадная модель (водопадная
модель)
Различная степень детализации процесса разработки ПС
Базируется на работах
процесса разработки,
определенного в
стандарте СТБ
ИСО/МЭК 12207–2003
43

44.

Каскадная модель с обратными связями
Возможна организация обратных связей между любыми шагами каскадной модели
Организация обратных
связей между соседними
шагами модели,
ориентированной на
работы стандарта СТБ
ИСО/МЭК 12207–2003
Структура фрагмента
каскадной модели
с возможностью возврата к
различным шагам
44

45.

Вариант каскадной модели по ГОСТ Р ИСО/МЭК
ТО 15271–2002
45

46.

V-образная модель
В модели выделены связи между шагами, предшествующими
программированию, и соответствующими видами тестирования и
испытаний
46

47.

V-образная модель
В модели организация обратных связей между этапами модели
47

48.

2.6.2. Спиральная модель жизненного цикла,
ее характеристики
48

49.

Спиральная модель жизненного цикла
49

50.

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

51.

Недостатки:
Основная проблема спирального цикла -
определение момента перехода на следующий
этап
Зачастую не уделяется достаточного внимания
разработке документации по системе
51

52.

2.6.3. Модели быстрой разработки
приложений
Rapid Application Development, RAD
52

53.

Характеристики
Основу RAD-модели составляет использование
мощных инструментальных средств разработки:
языки четвертого поколения 4GL (Fourth Generation
Language – язык программирования четвертого
поколения) и CASE-средства (Computer Aided Software
Engineering – компьютерная поддержка
проектирования ПО)
Использование инструментальных средств позволяет
задействовать пользователя, а следовательно, дать
оценку продукту на всех этапах его разработки.
активное привлечение заказчика уже на ранних
стадиях
короткое время перехода от анализа требований до
создания полной системы
53

54.

Базовая RAD-модель
Зависимость трудозатрат по разработке и
участия пользователя от этапов RAD-модели:
54

55.

2.6.4. Итеративные (инкрементные) модели
Итеративную разработку называют поразному: инкрементной, инкрементальной,
итеративной и постепенной.
Наиболее полным названием можно считать:
«итеративная и инкрементальная разработка»
(Iterative and Incremental Development, IDD)
55

56.

57.

Итеративная модель
Основные принципы:
жизненный цикл разработки ПО разбивается на последовательность
относительно коротких частей (итераций);
каждая итерация – маленький «водопад» (т.е. как каскадная модель)
для некоторой новой функциональности, выбранной с учетом
приоритетов;
требования – считаются неизменными в рамках одной итерации;
результат – работоспособная версия системы с дополнительной
функциональностью (инкремент);
регулярная поставка результата заказчику и получение обратной
связи (запросы на исправление или изменение, дополнительные
требования, обновленные приоритеты);
итерации – могут идти последовательно или с перекрытием;
завершение процесса – продукт удовлетворяет заказчика.
All rights reserved.

58.

Преимущества итеративной модели
Преимущества (в сравнении с каскадной):
вероятность успеха проекта существенно выше;
All rights reserved.
нет необходимости полностью и детально формулировать требования
до начала разработки;
заказчик имеет возможность задать приоритеты для требований;
заказчик может начать пользоваться системой задолго до конца
разработки;
у заказчика есть возможность вносить изменения в требования и их
приоритеты;
цена внесения изменений относительно невелика;
снижаются технологические (архитектурные и т.п.) риски на ранних
этапах ЖЦ.

59.

All rights reserved.
Итеративная модель: ограничения
Ограничения (недостатки):
из-за постоянного внесения изменений документация может потерять
полноту и согласованность, поэтому необходим рефакторинг;
итеративный процесс сложнее планировать и отслеживать, особенно в
случае перекрытия итераций;
бюджет проекта станет точно определенным только перед последней
итерацией, а до этого объем работ не фиксирован;
по мере своей эволюции любая методология, претендующая на
универсальность, неминуемо «разбухает», бюрократизируется и
становится сложной для восприятия;
процесс может стать формальностью, мешающей работе и отнимающей
время на борьбу с его несовершенством;
итеративный процесс существенно дороже водопадного.
Рефа́кторинг (англ. refactoring) или реорганизация кода — процесс изменения внутренней структуры
программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы.
В основе рефакторинга лежит последовательность небольших эквивалентных (то есть сохраняющих
поведение) преобразований. Поскольку каждое преобразование маленькое, программисту легче проследить
за его правильностью, и в то же время вся последовательность может привести к существенной
перестройке программы и улучшению её согласованности и четкости.

60.

Итеративная модель: требование и стоимость
ресурсов
нужно постоянно держать на проекте команду максимального
состава: аналитики, архитекторы, программисты,
тестировщики, технические писатели и т. д.;
доработка артефактов (документы, код) всегда дороже
разработки «с нуля», особенно если дорабатывает не тот, кто
разработал, а общие правила оформления не были созданы или
не соблюдались;
время от времени артефактам требуется рефакторинг, иначе
они потеряют полноту и согласованность;
методологии необходимо обучать (и команду, и заказчика).
требуется больше усилий на управление.
сознательное следование зрелой методологии требует
профессиональной зрелости от людей, а такие люди «стоят»
дороже.
All rights reserved.

61.

All rights reserved.
2.6.5. Стихийная модель «code and fix»
Суть этой модели:
единого плана не существует;
проект – смесь краткосрочных решений;
Хорошо подходит для создания небольшой системы, однако
по мере ее роста добавлять новые свойства становится все
более затруднительно;
появляется все больше ошибок, которые все труднее
исправлять;
типичный признак такой системы – долгий тестовый период
после того, как разработка всей функциональности системы
завершена;
соблюдение сроков и обязательств по выпуску программы
оказывается практически невозможным.

62.

English Русский Rules