Лекция 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. Приемка ПС предусматривает оценку результатов квалифи­кационного тестирования ПС и системы и документирование результатов оценки, которые проводятся заказчиком с помощью разработчика. Разработчик выполняет окончательную передачу ПС заказчику в соответствии с договором, обеспечивая при этом необходимое обучение и поддержку.

Дата добавления: 2014-01-14