В.4 Вопросы адаптации и применения

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

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

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

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

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

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

Работы (этапы) жизненного цикла системы. Определяется, какая из текущих служб жизненного цикла системы уместна и применима: инициация проекта покупателя, разработка поставщика и сопровождение. Некоторые сценарии:

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

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

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

Характеристики Уровня Системы. Определяется, какие из характеристик уровня системы уместны и применимы: количество элементов программного обеспечения, типы, размер и критичность программных продуктов и технические риски. Если программный продукт имеет много программных элементов, компонентов и единиц, то Процесс Разработки (5.3) следует тщательно адаптировать к каждому программному элементу. Следует рассмотреть все требования к интерфейсу и интеграции. Определяется, какие типы программных продуктов включены, так как различные типы программных продуктов могут требовать различных решений по адаптации. Некоторые примеры:

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

b) Использование программного продукта "с полки" "как есть". Весь Процесс разработки может быть излишним. Должны быть оценены выполнение, документация, присваивание права собственности, использование, гарантийные и лицензионные права и дальнейшая поддержка, относящиеся к программному продукту.

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

d) Программный или микропрограммный продукт встроен или присоединен к системе. Так как такой программный продукт является частью большой системы, то следует рассматривать службы Процесса Разработки (5.3), относящиеся к системе. В службах, относящихся к системе, необходимо выбрать только один из глаголов: "осуществлять" или "поддерживать". Если программный или микропрограммный продукт, скорее всего, не будет модифицироваться в дальнейшем, то следует тщательно исследовать размер документации.

e) Отдельный программный продукт. Так как такой программный продукт не является частью системы, то не требуется рассматривать службы Процесса Разработки (5.3), относящиеся к системе. Следует тщательно исследовать потребности в документации, особенно для поддержки.

f) Программный продукт, не предназначенный для поставки. Так как никакие его элементы не должны покупаться, поставляться или разрабатываться, то не следует рассматривать никакие положения данного Международного Стандарта, исключая 5.3.1.5 в Процессе Разработки (5.3). Тем не менее, если покупатель решает купить часть такого программного продукта для дальнейшего применения и поддержки, то этот продукт следует трактовать как в вышеперечисленных случаях b) или c).

Другие рассмотрения.

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

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