Файл: Инфрам.pdf

87 нить, чтобы квалифицировать программный продукт как соответст- вующий своим спецификациям и готовый к использованию в условиях эксплуатации.
Квалификационное тестирование ПС проводится разработчиком в присутствии заказчика (по возможности) для демонстрации того, что
ПС удовлетворяет своим спецификациям и готова к использованию в заданных условиях эксплуатации. Такое тестирование выполняется для каждого компонента программного продукта по всем разделам требова- ний при широком варьировании тестов. При этом также проверяется полнота технической и пользовательской документации и ее адекват- ность самим компонентам ПС.
Интеграция системы заключается в сборке всех ее компонентов, включая ПС и оборудование. После интеграции система, в свою оче- редь, подвергается квалификационному тестированию на соответствие предъявляемым к ней требованиям. При этом также производится оформление и проверка полного комплекта документации на систему.
Установка ПС осуществляется разработчиком в соответствии с пла- ном в той среде и на том оборудовании, которые предусмотрены дого- вором. В процессе установки проверяется работоспособность ПС и БД.
Если устанавливаемая ПС заменяет существующую систему, разработ- чик должен обеспечить их параллельное функционирование в соответ- ствии с договором.
Приемка ПС предусматривает оценку результатов квалификацион- ного тестирования ПС и системы и документирование результатов оценки, которые производятся заказчиком с помощью разработчика.
Разработчик выполняет окончательную передачу ПС заказчику в соот- ветствии с договором, обеспечивая при этом необходимое обучение и поддержку.
3.2.4. Процесс эксплуатации охватывает действия и задачи органи- зации-оператора, эксплуатирующего систему. Процесс эксплуатации включает следующие действия:
1) подготовительную работу, которая включает проведение оператором следующих задач: планирование действий и работ, выполняемых в процессе эксплуа- тации, и установку эксплуатационных стандартов; определение процедур локализации и разрешения проблем, возни- кающих в процессе эксплуатации;
2) эксплуатационное тестирование, осуществляемое для каждой оче- редной редакции программного продукта, после чего эта редакция передается в эксплуатацию;
3) собственно эксплуатацию системы, которая выполняется в предна- значенной для этого среде в соответствии с пользовательской доку- ментацией;
4) поддержку пользователей – оказание помощи и консультаций при обнаружении ошибок в процессе эксплуатации ПС.
3.2.5. Процесс сопровождения представляет собой действия и зада- чи, выполняемые сопровождающей организацией, при изменениях (мо-

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

89
Согласно стандарту IEEE-90 под конфигурацией ПС понимается со- вокупность ее функциональных и физических характеристик, установ- ленных в технической документации и реализованных в ПС. Управле- ние конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПС на всех стадиях ЖЦ. Общие принципы и рекомендации по управлению конфигурацией ПС отраже- ны в стандарте ISO/IEC 15288 “Information Technology. Software Life
Cycle Process. Configuration Management for Software” [4].
Процесс управления конфигурацией включает следующие действия:
1) подготовительную работу, заключающуюся в планировании управ- ления конфигурацией;
2) идентификацию конфигурации, устанавливающую правила, с помо- щью которых однозначно идентифицируются компоненты ПС и их версии. При этом каждому компоненту однозначно соответствует комплект документации;
3) контроль конфигурации – действие, предназначенное для система- тической оценки предлагаемых модификаций ПС и координирован- ной их реализации с учетом эффективности каждой модификации и затрат на ее выполнение;
4) учет состояния конфигурации, представляющий собой регистрацию состояния компонентов ПС. Обеспечивает подготовку отчетов о реа- лизованных и отвергнутых модификациях версий компонентов ПС.
Совокупность отчетов дает однозначное отражение текущего со- стояния системы и ее компонентов, а также обеспечивает ведение истории модификаций;
5) оценку конфигурации, заключающуюся в определении функцио- нальной полноты компонентов ПС, а также соответствия их физиче- ского состояния текущему техническому описанию;
6) управление выпуском и поставку, охватывающие изготовление эта- лонных копий программ и документации, их хранение и поставку пользователям в соответствии с порядком, принятом в организации.
3.3.3. Процесс обеспечения качества должен обеспечивать гарантии того, что ПС и процессы ее ЖЦ соответствуют заданным требованиям и утвержденным планам. Под качеством ПС понимается совокупность
свойств, которая характеризует способность ПС удовлетворять за-
данным требованиям. Для получения достоверных оценок о создавае- мой ПС процесс обеспечения ее качества должен происходить незави- симо от субъектов, непосредственно связанных с разработкой про- граммного продукта. При этом могут использоваться результаты других вспомогательных процессов, таких, как верификация, аттестация, со-
вместная оценка, аудит и разрешение проблем.
Процесс обеспечения качества включает следующие действия:
1) подготовительную работу (координацию с другими вспомогатель- ными процессами и планирование самого процесса обеспечения ка- чества ПС с учетом используемых стандартов, методов, процедур и средств);

90 2) обеспечение качества продукта, подразумевающего гарантированное полное соответствие ПС и ее документации требования заказчика, предусмотренным в договоре;
3) обеспечение качества процесса, предполагающее гарантированное соответствие процессов ЖЦ ПС, методов разработки, среды разра- ботки и квалификации персонала условиям договора, установлен- ным стандартам и процедурам;
4) обеспечение прочих показателей качества ПС, осуществляемое в соответствии с условиями договора и стандартом качества ISO 9001.
3.3.4. Процесс верификации состоит в определении того факта, что
ПС, являющаяся результатом некоторой деятельности, полностью удов- летворяет требованиям или условиям, обусловленным предшествую- щими действиями. Для повышения эффективности всего процесса ЖЦ
ПС верификация должна как можно раньше интегрироваться с исполь- зующими ее процессами (т.е. с поставкой, разработкой, эксплуатацией).
Процесс верификации может включать анализ, оценку и тестирование.
Верификация может проводиться с различными степенями незави- симости (от самого исполнителя до специалистов другой организации, не зависящей от поставщика, разработчика и т.д.). В процессе верифи- кации проверяются следующие условия:
1) непротиворечивость требований, предъявляемых к системе и сте- пень учета потребностей пользователей;
2) возможность поставщика выполнить заданные требования;
3) соответствие выбранных процессов ЖЦ ПС условиям договора;
4) адекватность стандартов, процедур и среды разработки процессам
ЖЦ ПС;
5) соответствие проектных спецификаций ПС заданным требованиям;
6) корректность описания в проектных спецификациях входных и вы- ходных данных, последовательности событий, интерфейсов, логики и т.д.;
7) соответствие кода проектным спецификациям и требованиям;
8) тестируемость и корректность кода, его соответствие принятым стандартам кодирования;
9) корректность интеграции компонентов ПС в систему;
10) адекватность, полнота и непротиворечивость документации.
3.3.5. Процесс аттестации предназначен для определения полноты соответствия заданных требований и созданной ПС их конкретному функциональному назначению (тому, что требуется потребителю). Под аттестацией обычно понимается подтверждение и оценка достоверности проведенного тестирования программного продукта. Аттестация долж- на гарантировать полное соответствие ПО спецификациям, требованиям и документации, а также возможность безопасного и надежного приме- нения ПО пользователем.
Аттестация, как и верификация, может осуществляться с различны- ми степенями независимости (вплоть до организации, не зависящей от поставщика, разработчика, оператора или службы сопровождения).

91 3.3.6. Процесс совместной оценки предназначен для оценки состоя- ния работ по проекту и программному продукту, создаваемому при вы- полнении этих работ. Он сосредоточен в основном на контроле плани- рования и управления ресурсами, персоналом, аппаратурой и инстру- ментальными средствами проекта.
Оценка применяется как на уровне управления проектом, так и на уровне технической реализации проекта и проводится в течение всего срока действия договора. Данный процесс может выполняться двумя сторонами, участвующими в договоре, при этом одна сторона проверяет другую.
3.3.7. Процесс аудита представляет собой определение соответствия проекта и продукта требованиям, планам и условиям договора. Аудит может выполняться двум любыми сторонами, участвующими в догово- ре, когда одна сторона проверяет другую.
Аудит – это ревизия (проверка), проводимая компетентным органом
(лицом) в целях обеспечения независимой оценки степени соответствия
ПС или процессов установленным требованиям.
Аудит служит для установления соответствия реальных работ и от- четов требованиям, планам и контракту. Аудиторы не должны иметь прямой зависимости от разработчиков ПС. Они определяют состояние работ, использование ресурсов, соответствие документации специфика- циям и стандартам, корректность тестирования и др.
3.3.7. Процесс разрешения проблем предусматривает анализ и раз- решение проблем (включая обнаруженные несоответствия), которые обнаружены в ходе разработки, эксплуатации или других процессов независимо от их происхождения или источника.
3.4. Организационные процессы ЖЦ ПС
3.4.1. Процесс управления состоит из действий и задач, которые мо- гут выполняться любой стороной, управляющей своими процессами.
Данная сторона (менеджер) отвечает за управление выпуском продукта, управление проектом и управление задачами соответствующих процес- сов, таких, как приобретение, поставка, разработка, эксплуатация, со- провождение и др.
Процесс управления включает следующие действия:
1) инициирование и определение области управления – менеджер дол- жен убедиться, что необходимые для управления ресурсы (персонал, оборудование и технология) имеются в его распоряжении в доста- точном количестве;
2) планирование, как действие, подразумевает выполнение следующих задач: составление графиков выполнения работ; оценку затрат; выделение требуемых ресурсов; распределение ответственности; оценку рисков, связанных с конкретными задачами;