Процессы жизненного цикла программных средств

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

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

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

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

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

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

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

c. персонал сопровождения модифицирует программные продукты. Учитывается процесс сопровождения (см. 5.5 настоящего стандарта). Части процесса разработки (см. 5.3) могут быть использованы в качестве мини-процессов.

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

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

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

a. Новая разработка. Должны быть учтены все требования, особенно к процессу разработки (см. 5.3);