Лекция 3. Жизненный цикл программных средств.
В основе деятельности по созданию и использованию программного обеспечения лежит понятие жизненного цикла.
Жизненный цикл является моделью создания и использования программного средства, отражающей его различные состояния, начиная с момента возникновения необходимости в данном ПО и заканчивая моментом его полного выхода из употребления у пользователей.
На основе международного стандарта, регламентирующего ЖЦ ПС ISO/IEC 12207 разработан отечественный стандарт ГОСТ Р ИСО/МЭК 12207. Он введен в действие с 1 июля 2001г.
В стандарте обобщаются опыт и результаты исследований множества специалистов и сосредатачиваются наиболее эффективные современные методы и процессы. В результате таких обобщений обрабатываются технологические процессы и приемы разработки ПС, что способствует повышению технико-экономических показателей создания ПС.
ЖЦ ПСв стандартах представляет собой:
- набор этапов, частных работ и операций в последовательности их выполнения и взаимосвязи, регламентирующих ведение работ от подготовки технического задания до завершения испытаний ряда версий и окончания эксплуатации ПС.
Стандарт включает:
- правила описания исходной информации, способов и методов выполнения операций, устанавливает правила контроля технологических процессов, требования к оформлению их результатов, а также
- регламентирует содержание технологических и эксплуатационных документов на комплексы программ. Он определяет организационную структуру коллектива, обеспечивает распределение и планирование заданий, а также контроль за ходом создания ПС.
Согласно стандарту ГОСТ Р ИСО/МЭК 12207 структура ЖЦ состоит из трех групп процессов:
основные; вспомогательные; организационные.
· основные процессы жизненного цикла ПС и определяющие работы (раздел 5);
· вспомогательные процессы и работы, обеспечивающие выполнение основных процессов (раздел 6);
· организационные процессы и управление жизненным циклом ПС (раздел 7).
Эти разделы стандарта состоят из ряда подразделов, в которых подробно раскрывается содержание каждой работы и комментируются особенности их выполнения. Рекомендации к каждому подразделу состоят в среднем из 3-6 пунктов — работ (процедур). Общее число работ и комментариев к ним в стандарте свыше 220.
Рассмотрим подробнее группу основных процессов. Дадим определение основным процессам.
Основные процессыопределяются как совокупность взаимосвязанных действий, преобразующих некоторые входные данные в выходные.
Основные процессы ЖЦ реализуются ответственным субъектом, вовлеченным в ЖЦ ПС. Ответственным субъектом является одно из юридических лиц (или подразделений, или должностных физических лиц), которые реализуют соответствующий процесс. Ответственными субъектами являются заказчик, поставщик, разработчик, эксплуатационный (оператор) и сопровождающий персонал. Основные процессы определяют следующее.
Группа основных процессов включает в себя процессы: приобретение; поставка; разработка; эксплуатация; сопровождение.
· Процесс приобретения (заказа) — работы заказчика (субъекта, приобретающего систему, ПС или получающего программную услугу).
· Процесс поставки — работы поставщика (субъекта, поставляющего систему, ПС или программную услугу заказчику).
· Процесс разработки — работы разработчика (субъекта, проектирующего и разрабатывающего ПС).
· Процесс эксплуатации — работы эксплуатационного персонала (субъекта, обеспечивающего эксплуатационное обслуживание вычислительной системы в заданных условиях в интересах пользователей).
· Процесс сопровождения — работы персонала сопровождения (субъекта, предоставляющего услуги по сопровождению ПС, обеспечивающие контролируемое изменение программного продукта в целях сохранения его исходного состояния и функциональных возможностей). Данный процесс охватывает перенос ПС в другую среду и снятие его с эксплуатации.
Рассмотрим подробнее каждый из этих процессов.
Процесс приобретения(acquisition process) состоит из действий и задач заказчика, приобретающего программное средство.
1. Инициирование приобретения включает следующие задачи:
• определение заказчиком своих потребностей в приобретении, разработке или усовершенствовании системы, программных продуктов или услуг;
• анализ требований к системе;
• принятие решения относительно приобретения, разработки или усовершенствования существующего ПС;
• проверку наличия необходимой документации, гарантий, сертификатов, лицензий и поддержки в случае приобретения программного продукта;
• подготовку и утверждение плана приобретения, включающего требования к системе, тип договора, ответственность сторон и т. д.
Заявочные предложения должны содержать:
• требования к системе;
• перечень программных продуктов;
• условия и соглашения;
• технические ограничения (например, среда функционирования системы).
2.Заявочные предложения направляются выбранному поставщику (или нескольким поставщикам в случае проведения тендера). Поставщик — это организация, которая заключает договор с заказчиком на поставку системы, ПС или программной услуги на условиях, оговоренных в договоре.
3. Подготовка и корректировка договора включают следующие задачи:
• определение заказчиком процедуры выбора поставщика, включающей критерии оценки предложений возможных поставщиков;
• выбор конкретного поставщика на основе анализа предложений;
• подготовку и заключение договора с поставщиком;
• внесение изменений (при необходимости) в договор в процессе его выполнения.
4.Надзор за деятельностью поставщика осуществляется в соответствии с действиями, предусмотренными в процессах совместной оценки и аудита.
5. В процессе приемки подготавливаются и выполняются необходимые тесты. Завершение работ по договору осуществляется в случае удовлетворения всех условий приемки.
Процесс поставки(supply process) охватывает действия и задачи, выполняемые поставщиком, который снабжает заказчика программным продуктом или услугой.
1.Инициирование поставки заключается в рассмотрении поставщиком заявочных предложений и принятии решения о согласии с выставленными требованиями и условиями или предложение своих.
2. Планирование включает следующие задачи:
• принятие решения поставщиком относительно выполнения работ своими силами или с привлечением субподрядчика;
• разработку поставщиком плана управления проектом, содержащего организационную структуру проекта, разграничение ответственности, технические требования к среде разработки и ресурсам, управление субподрядчиками и др.
Процесс разработки(development process) предусматривает действия и задачи, выполняемые разработчиком, и охватывает работы по созданию ПС и его компонентов в соответствии с заданными требованиями, включая оформление проектной и эксплуатационной документации; подготовку материалов, необходимых для проверки работоспособности и соответствующего качества программных продуктов, материалов, необходимых для организации обучения персонала, и т. д.
1.Подготовительная работа начинается с выбора модели ЖЦ ПС, соответствующей масштабу, значимости и сложности проекта. Действия и задачи процесса разработки должны соответствовать выбранной модели. Разработчик должен выбрать, адаптировать к условиям проекта и использовать согласованные с заказчиком стандарты, методы и средства разработки, а также составить план выполнения работ.
2. Анализ требований к системе подразумевает определение ее функциональных возможностей, пользовательских требований, требований к надежности и безопасности, требований к внешним интерфейсам и т. д. Требования к системе оцениваются исходя из критериев реализуемости и возможности проверки при тестировании.
3.Проектирование архитектуры системы на высоком уровне заключается в определении компонентов ее оборудования, ПС и операций, выполняемых эксплуатирующим систему персоналом. Архитектура системы должна соответствовать требованиям, предъявляемым к системе, а также принятым проектным стандартам и методам.
4.Анализ требований к ПС предполагает определение следующих характеристик для каждого компонента ПС:
• функциональных возможностей, включая характеристики производительности и среды функционирования компонента;
• внешних интерфейсов;
• спецификаций надежности и безопасности;
• эргономических требований;
• требований к используемым данным;
• требований к установке и приемке;
• требований к пользовательской документации;
• требований к эксплуатации и сопровождению.
Требования к ПС оцениваются исходя из критериев соответствия требованиям к системе, реализуемости и возможности проверки при тестировании.
5.Проектирование архитектуры ПС включает следующие задачи (для каждого компонента ПС):
• трансформацию требований к ПС в архитектуру, определяющую на высоком уровне структуру ПС и состав его компонентов;
• разработку и документирование программных интерфейсов ПС и баз данных;
• разработку предварительной версии пользовательской документации;
• разработку и документирование предварительных требований к тестам и плана интеграции ПС.
Архитектура компонентов ПС должна соответствовать требованиям, предъявляемым к ним, а также принятым проектным стандартам и методам.
6. Детальное проектирование ПС включает следующие задачи:
• описание компонентов ПС и интерфейсов между ними на более низком уровне, достаточном для их последующего самостоятельного кодирования и тестирования;
• разработку и документирование детального проекта базы данных;
• обновление (при необходимости) пользовательской документации;
• разработку и документирование требований к тестам и плана тестирования компонентов ПС;
• обновление плана интеграции ПС.
7.Кодирование и тестирование ПС охватывают следующие задачи:
• разработку (кодирование) и документирование каждого компонента ПС и базы данных, а также совокупности тестовых процедур и данных для их тестирования;
• тестирование каждого компонента ПС и базы данных на соответствие предъявляемым к ним требованиям. Результаты тестирования компонентов должны быть документированы;
• обновление (при необходимости) пользовательской документации;
• обновление плана интеграции ПС.
8.Интеграция ПС предусматривает сборку разработанных компонентов ПС в соответствии с планом интеграции и тестирование агрегированных компонентов. Для каждого из агрегированных компонентов разрабатываются наборы тестов и тестовые процедуры, предназначенные для проверки каждого из квалификационных требований при последующем квалификационном тестировании. Квалификационное требование — это набор критериев или условий, которые необходимо выполнить, чтобы квалифицировать программный продукт как соответствующий своим спецификациям и готовый к использованию в условиях эксплуатации.
9.Квалификационное тестирование ПС проводится разработчиком в присутствии заказчика (по возможности) для демонстрации того, что ПС удовлетворяет своим спецификациям и готово к использованию в условиях эксплуатации. Квалификационное тестирование выполняется для каждого компонента ПС по всем разделам требований при широком варьировании тестов. При этом также проверяются полнота технической и пользовательской документации и ее адекватность самим компонентам ПС.
10 Интеграция системы заключается в сборке всех ее компонентов, включая ПС и оборудование. После интеграции система, в свою очередь, подвергается
11. квалификационному тестированию на соответствие совокупности требований к ней. При этом также производятся оформление и проверка полного комплекта документации на систему.
12.Установка ПС осуществляется разработчиком в соответствии с планом в той среде и на том оборудовании, которые предусмотрены договором. В процессе установки проверяется работоспособность ПС и баз данных. Если устанавливаемое ПС, заменяет существующую систему, разработчик должен обеспечить их параллельное функционирование в соответствии с договором.
13. Приемка ПС предусматривает оценку результатов квалификационного тестирования ПС и системы и документирование результатов оценки, которые проводятся заказчиком с помощью разработчика. Разработчик выполняет окончательную передачу ПС заказчику в соответствии с договором, обеспечивая при этом необходимое обучение и поддержку.