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

Анализ требований к системе подразумевает определение ее функциональных возможностей, пользовательских требований, требований к надежности и безопасности, требований к внешним интерфейсам и т.д. Требования к системе оцениваются исходя из критериев реализуемости и возможности проверки при тестировании на основе предварительной оценки рисков.

Анализ требований к ПО предполагает определение следующих характеристик для каждого компонента ПО:

• функциональных возможностей, включая характеристики производительности и среды функционирования компонента;

• внешних интерфейсов;

• спецификаций функциональной надежности и безопасности;

• эргономических требований;

• требований к используемым данным;

• требований к установке и приемке;

• требований к пользовательской документации;

• требований к эксплуатации и сопровождению.

Требования к ПО оцениваются исходя из критериев соответствия ими требованиям к системе, реализуемости и возможности проверки при тестировании.

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

Проектирование архитектуры ПО включает следующие задачи (для каждого компонента ПО):

• трансформацию требований к программным средствам в архитектуру, определяющую на высоком уровне структуру программных средств и состав его компонентов;

• разработку и документирование программных интерфейсов программных средств и баз данных;

• разработку предварительной версии пользовательской документации;

• разработку и документирование предварительных требований к тестам и плана интеграции программных средств.

Архитектура компонентов программных средств должна соответствовать требованиям, предъявляемым к ним, а также принятым проектным стандартам и методам.

Детальное проектирование программных средств включает следующие задачи:

• описание компонентов программных средств и интерфейсов между ними на более низком уровне, достаточном для их последующего самостоятельного кодирования и тестирования;

• разработку и документирование детального проекта базы данных;

• обновление (при необходимости) пользовательской документации;

• разработку и документирование требований к тестам и плана тестирования компонентов программных средств;

• обновление плана интеграции программных средств.

Кодирование и тестирование программных средств охватывают

следующие задачи:

• разработку (кодирование) и документирование каждого компонента программных средств и базы данных, а также совокупности тестовых процедур и данных для их тестирования;

• тестирование каждого компонента программных средств и базы данных на соответствие предъявляемым к ним требованиям. Результаты тестирования компонентов должны быть документированы;

• обновление (при необходимости) пользовательской документации

• обновление плана интеграции ПО.

Кодирование может производиться либо с помощью графической среды, библиотеки программных модулей, либо с помощью языков высокого уровня, либо с помощью ассемблера. Затем, следуя восходящей ветви V-диаграммы, необходимо провести испытания и связанную с ними верификацию всех разработанных программных модулей.

Верификация

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

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

Верификация может проводиться с различными степенями независимости. Степень независимости может варьироваться от выполнения верификации самим исполнителем или другим специалистом данной организации до ее выполнения специалистом другой организации с различными вариациями. Если процесс верификации осуществляется организацией, не зависящей от поставщика, разработчика, оператора или службы сопровождения, то он называется независимой верификацией.

В процессе верификации проверяются следующие условия:

• непротиворечивость требований к системе и степень учета потребностей пользователей;

• возможности поставщика выполнить заданные требования;

• соответствие выбранных процессов жизненного цикла программных средств условиям договора;

• адекватность стандартов, процедур и среды разработки процессам жизненного цикла программных средств;

• соответствие проектных спецификаций программных средств заданным требованиям;

• корректность описания в проектных спецификациях входных и выходных данных, последовательности событий, интерфейсов, логики и т.д.;

• соответствие кода проектным спецификациям и требованиям;

• тестируемость и корректность кода, его соответствие принятым стандартам кодирования;

• корректность интеграции компонентов программных средств в систему;

• адекватность, полнота и непротиворечивость документации.

ИНТЕГРАЦИОННЫЕ ИСПЫТАНИЯ

На уровне групп модулей и системы должны проводиться так называемые интеграционные испытания, которые предназначены для комплексной проверки совместимости правильного взаимодействия программных и аппаратных средств системы.

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

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

ВАЛИДАЦИЯ

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

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

Валидация, так же как верификация, может осуществляться с различными степенями независимости. Если процесс валидации выполняется организацией, не зависящей от поставщика, разработчика, оператора или службы сопровождения, то он называется независимой валидацией.

Затем производятся установка и приемка ПО.

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

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

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

Каждый документ программного обеспечения должен быть написан в соответствии со следующими правилами:

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

• каждый документ ПО не должен противоречить предшествующему документу;

• каждый термин, акроним и аббревиатура должны иметь одно и то же значение во всех документах;

• на каждый пункт или понятие нужно ссылаться в каждом документе по одному и тому же имени или описанию.