ГОССТАНДАРТ РОССИИ: Процессы жизненного цикла программных средств

d. обеспечения качества (см. 6.3 настоящего стандарта). Выполняется персоналом, независимым от кадров, непосредственно отвечающих за разработку программного продукта или за реализацию процесса. Целью этой работы является представление независимой гарантии соответствия программных продуктов и процессов требованиям договора и соблюдению установленных планов. Данный процесс может использовать результаты по перечислениям а), b) и с) в качестве исходных данных и может координировать свои работы с работами по этим перечислениям;

e. усовершенствования (см. 7.3 настоящего стандарта). Выполняется организацией для эффективного управления реализуемыми процессами и усовершенствования их. Проводится без учета требований проекта или договора.

В настоящем разделе в общих чертах рассматриваются вопросы адаптации и применения для основных характеристик проекта. Ни рассматриваемые вопросы, ни характеристики не являются исчерпывающими и отражают только современное понимание. На рисунке B.I представлен пример применения настоящего стандарта.

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

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

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

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

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

Работа жизненного цикла системы. Должно быть определено, какая из работ жизненного цикла существующей системы уместна и применима, например, подготовка проекта заказчиком, разработка поставщиком и сопровождение. Ниже приведены некоторые сценарии:

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