В.3 Адаптация работ, относящихся к оценке

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

a) оценок внутри процесса (задачи оценки см. в 5.1—5.5 настоящего стандарта). Данные оценки проводятся персоналом, выполняющим определенные в процессе задачи во время своих ежедневных работ;

b) верификации (см. 6.4 настоящего стандарта) и аттестации (см. 6.5 настоящего стандарта). Выполняются заказчиком, поставщиком или независимой стороной для того, чтобы верифицировать или аттестовать продукты с различной степенью зависимости от проекта. Эти оценки не дублируют и не заменяют другие оценки, а напротив дополняют их;

c) совместных анализов (см. 6.6 настоящего стандарта) и аудиторских проверок (см. 6.7 настоящего стандарта). Они проводятся на совместном совещании проверяемой и проверяющей сторон для того, чтобы оценить состояние и соответствие продуктов и работ предварительно установленному графику;

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

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

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

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

Рисунок B.1 - Пример применения настоящего стандарта

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

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

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

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

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

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

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

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

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

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

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

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

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

d) Программный или программно-аппаратный продукт, встроенный или подключенный к системе. Так как такой программный продукт является частью большой системы, то следует учитывать работы процесса разработки (см. 5.3), связанные с системой. Из работ, связанных с системой, необходимо выбрать только те, которые описаны глаголами «выполнять» или «поддерживать». Если программный или программно-аппаратный продукт, скорее всего, не будет в дальнейшем изменяться, то следует тщательно проверить необходимую степень его документируемости;

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

f) Непоставляемый программный продукт. Так как данные объекты не заказываются, не поставляются или не разрабатываются, то не следует учитывать положения настоящего стандарта, за исключением 5.3.1.5 процесса разработки по 5.3. Однако если заказчик желает приобрести часть такого программного продукта для дальнейших эксплуатации и сопровождения, то данный программный продукт следует рассматривать в перечислениях b) или с) настоящего пункта.

Другие соображения.

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

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

Поиск по сайту: