Основные процессы ЖЦ

1. Основные процессы ЖЦ

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

2. Основные процессы ЖЦ

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

3.

Основные процессы ЖЦ
3) Процесс разработки (development process) работы по созданию ПО и его компонентов в соответствии с заданными требованиями:
оформление проектной и эксплуатационной документации, подготовка материалов,
необходимых для проверки работоспособности и соответствующего качества программных
продуктов, материалов, необходимых для организации обучения персонала и т.д.
Разработка ПО включает в себя анализ, проектирование и реализацию
(программирование):
подготовительная работа;
анализ требований к системе;
проектирование архитектуры системы;
анализ требований к ПО;
проектирование архитектуры ПО;
детальное проектирование ПО;
кодирование и тестирование ПО;
интеграция ПО;
квалификационное тестирование ПО;
интеграция системы;
квалификационное тестирование системы;
установка ПО;
приемка ПО.

4.

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

5.

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

6.

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

7.

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

8.

Основные процессы ЖЦ
5) Процесс сопровождения (maintenance process)
- предусматривает действия и задачи, выполняемые
службой сопровождения. Данный процесс активизируется при
модификациях ПП и соответствующей документации,
вызванных возникшими проблемами или потребностями в
модернизации, либо адаптации ПО.
Сопровождение – внесение изменений в ПО в целях
исправления ошибок, повышения производительности или
адаптации
к
изменившимся
условиям
работы
или
требованиям. (Стандарт IEEE-90)
Грейди Буч разделяет термины сопровождение, эволюция и
сохранение:
Сопровождение – устранение ошибок.
Эволюция – внесение изменений в систему в ответ на
изменившиеся требования к ней.
Сохранение – использование всех возможных способов для
поддержания жизни в устаревшей системе.

9. Вспомогательные процессы ЖЦ

1) Процесс документирования (documentation process)
– предусматривает формализованное описание информации,
созданной в течение ЖЦ ПО.
2) Процесс управления конфигурацией (configuration
management process)
При создании проектов сложных ИС, состоящих из многих
компонентов,
каждый
из
которых
может
иметь
разновидности или версии, возникает проблема учета их
связей и функций, создания унифицированной структуры и
обеспечения
развития
всей
системы.
Управление
конфигурацией позволяет организовать, систематически
учитывать и контролировать внесение изменений в ПО на
всех стадиях ЖЦ.
Конфигурация ПО – совокупность его функциональных и
физических характеристик, установленных в технической
документации и реализованных в ПО (Стандарт IEEE-90)

10. Вспомогательные процессы ЖЦ

3) Процесс обеспечения качества (quality assurance
process)
Он обеспечивает соответствующие гарантии того, что ПО и
процессы его ЖЦ соответствуют заданным требованиям и
утвержденным планам.
Качество ПО – совокупность свойств, которые
характеризуют способность ПО удовлетворять заданным
требованиям.
Для получения достоверных оценок создаваемого ПО
процесс обеспечения его качества должен происходить
независимо от субъектов, непосредственно связанных с
разработкой ПО. При этом могут использоваться
результаты других вспомогательных процессов
(верификация, аттестация, совместная оценка, аудит и
разрешение проблем).

11. Вспомогательные процессы ЖЦ

4) Процесс верификации (verification process)
Верификация – процесс определения того, отвечает
ли текущее состояние разработки, достигнутое на
данном этапе, требованиям этого этапа.
Верификация в узком смысле означает формальное
доказательство правильности ПО. Если процесс
верификации осуществляется организацией, не
зависящей от поставщика, разработчика, или службы
сопровождения, то он называется процессом
независимой верификации.
Так
как задание на создание ПО обычно
формулируется неформально, а также из-за того, что
понятия ошибки в информационной системе не
формализовано, то нельзя доказать формальными
методами (математически) правильность ПС.

12. Вспомогательные процессы ЖЦ

6) Процесс аттестации (validation process)
Аттестация должна гарантировать полное соответствие
заданных требований и созданной системы или
программного
продукта
их
конкретному
функциональному назначению.
Под
аттестацией
ПО
обычно
понимается
подтверждение и оценка достоверности проведенного
тестирования ПО.
7) Процесс совместной оценки (joint review process)
- предназначен для оценки состояния работ по проекту
и ПО, создаваемого при выполнении данных работ.
Данный процесс может выполняться двумя любыми
сторонами, участвующими в договоре, при этом одна
сторона проверяет другую.

13. Вспомогательные процессы ЖЦ

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

14. Организационные процессы ЖЦ ПО

1) Процесс управления (management process)
Менеджер отвечает за управление выпуском
продукта, управление проектом и управление
задачами соответствующих процессов, таких, как
приобретение, поставка, разработка, эксплуатация,
сопровождение и др.
2) Процесс создания инфраструктуры (infrastructure
process)
- охватывает выбор и поддержку технологии,
стандартов и инструментальных средств, выбор и
установку аппаратных и программных средств,
используемых для разработки, эксплуатации или
сопровождения ПО.

15. Организационные процессы ЖЦ ПО

3) Процесс усовершенствования (improvement process) усовершенствование процессов ЖЦ ПО направлено на
повышение производительности труда всех участвующих в
них специалистов за счет совершенствования используемой
технологии, методов управления, выбора инструментальных
средств и обучения персонала.
4) Процесс обучения (training process)
- охватывает первоначальное обучение и последующее
постоянное повышение квалификации персонала.
Приобретение, поставка, разработка, эксплуатация и
сопровождение ПО в значительной степени зависят от
уровня знаний и квалификации персонала. Например,
разработчики ПО должны пройти необходимое обучение
методам и средствам программной инженерии.

16. Модели жизненного цикла ПО

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

17. Модели жизненного цикла ПО

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

18. Модели жизненного цикла ПО

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

19. Формирование требований к ПО

На стадии формирования требований к ПО выполняются следующие
работы:
Планирование работ, предваряющее работы над проектом. Основные
задачи
этапа:
определение
целей
разработки,
предварительная
экономическая оценка проекта, построение плана-графика выполнения
работ, создание и обучение рабочей группы;
Проведение обследования деятельности объекта/организации предварительное выявление требований к будущей системе; выявление
функциональных взаимодействий и информационных потоков в объекте,
анализ существующих средств автоматизации в организации;
Построение
моделей
деятельности
объекта/организации
предусматривающее построение двух видов моделей: модели «AS-IS» («как
есть»), отражающей существующее положение дел в организации и
позволяющей
понять,
каким
образом
функционирует
данная
организация/объект и модели «TO-BE» («как должно быть»), отражающей
представление о новых технологиях работы организации/объекта.

20. Анализ и Проектирование

Данная стадия включает в себя:
Разработку системного проекта, основу которого составляют модели
проектируемой системы, которые строятся на основе модели «TO-BE».
На данном этапе дается ответ на вопрос «Что должна делать будущая
система?», а именно определяются архитектура системы, ее функции,
интерфейсы и распределение функций между пользователями и
системой, требования к программным и информационным компонентам,
сроки разработки. Результатом данного этапа является документ
«техническое задание».
Разработку технического проекта. На основе системного проекта
осуществляется собственно проектирование системы, включающее
проектирование архитектуры системы и детальное проектирование.
Содержание последующих стадий совпадает в основном с
соответствующими процессами ЖЦ ПО. На каждой стадии могут
выполняться несколько процессов, определенных в стандарте ISO/IEC
12207, и, наоборот, один и тот же процесс может выполняться на
различных стадиях.

21.

К настоящему времени наибольшее распространение получили
следующие две основные модели ЖЦ:
каскадная модель (1970–1985 гг);
спиральная модель (1986–1990 гг.).
Каскадная модель
Формирование
требований
Анализ
Проектирование
Реализация
Тестировани
е
Рис 1. Каскадная модель разработки ПО
Внедрение

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

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

23.

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

24.

Процесс создания ПО носит итерационный характер: результаты
очередной стадии часто вызывают изменения в проектных решениях
более ранних стадий. Уточненную модель называют моделью с
промежуточным контролем или с обратной связью (рис.2). Это
обеспечивает большую надежность по сравнению с классической
каскадной моделью, хотя и увеличивает весь период разработки.
Формирование
требований
Анализ
Анализ
Проектирование
Реализация
Тестирование
Внедрение
Рис 2. Каскадная модель с обратной связью

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

Для решения перечисленных проблем Боэм в 1986 г. предложил
использовать новую спиральную модель ЖЦ (рис. 3).
Ее принципиальная особенность - разработка представляется как
итеративный процесс, состоящий из тех же этапов, но повторяющихся
много раз.
Формирование
новая
итерация
…
требований
Внедрение
Анализ
Тестирование
Проектирование
Реализация
Рис 3. Спиральная модель разработки ПО

26.

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

27. Подход RAD

Одним из возможных подходов к разработке прикладного ПО в рамках
спиральной модели является способ так называемой быстрой разработки
приложений, или RAD (Rapid Application Development). Данный подход
предусматривает наличие трех составляющих:
небольших групп разработчиков (от 3 до 7 человек), выполняющих работы
по проектированию отдельных подсистем;
короткого, но тщательно проработанного производственного графика (до 3
месяцев);
повторяющегося цикла, при котором разработчики по мере того, как
приложение начинает обретать форму, запрашивают и реализуют требования
заказчика.
Жизненный цикл ПО в соответствии с данным подходом включает 4
стадии:
Анализ и планирование требований;
Проектирование;
Реализация (Кодирование)
Внедрение.

28.

1) Стадия анализа и планирования требований
Действия:
Определение пользователем функций системы с выделением
наиболее приоритетных;
Описание информационных потребностей и формулирование (с
помощью разработчиков) требований к системе.
Задачи:
Ограничение масштаба проекта;
Установление временных рамок для каждой стадии;
Определение возможности реализации проекта в заданных
условиях.
Результаты:
Приоритетный список функций будущего ПО;
Предварительные модели ПО.

29.

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

30.

Результаты Стадии проектирования:
Общая информационная модель системы;
Функциональные модели системы в целом и отдельных подсистем;
Точно определенные интерфейсы между автономно работающими подсистемами;
Построенные прототипы экранных форм, диалогов, отчетов.
3) Стадия реализации
На этой стадии выполняется непосредственно разработка приложения
Действия:
Итеративное построение разработчиками реальной системы на основе полученных
моделей и требований по надежности и производительности;
Оценка заказчиком полученных результатов и внесение корректив;
Интегрированное тестирование, осуществляемое в процессе разработки;
Физическое проектирование базы данных;
Установление способов повышения производительности;
Завершение разработки документации.
Результаты:
Готовая система, удовлетворяющая всем согласованным требованиям.

31.

4) Стадия внедрения
- производится внедрение системы параллельно с эксплуатацией
существующей системы и обучение пользователей. Планирование и
подготовка к данной стадии должны осуществляться заранее, на стадии
проектирования системы.
Подход RAD не применим для построения сложных расчетных программ
или программ управления сложными объектами в реальном масштабе
времени; для приложений, в которых отсутствует ярко выраженная
интерфейсная часть.
Оценка размера приложений производится на основе совокупности
функциональных точек. Подобная метрика не зависит от языка
программирования, на котором ведется разработка. Размер приложения,
выполненного по методологии RAD, для хорошо отлаженной среды
разработки с максимальным повторным использованием программных
компонентов, определяется следующим образом:
< 1000 функциональных элементов
один человек
1000-4000 функциональных элементов
одна команда разработчиков
> 4000 функциональных элементов
4000 элементов на одну
команду разработчиков

32.

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

33.

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