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

Данная работа состоит из следующей задачи:

А.1.1 Должны быть определены характеристики условий выполнения проекта, влияющие на адаптацию. К числу таких характеристик можно отнести:

a. модель жизненного цикла;

b. влияние жизненного цикла существующей системы;

c. требования к системе и программным средствам;

d. организационные подходы, процедуры и цели;

e. размер, критичность и типы системы, программного продукта или услуги;

f. количество задействованного персонала и участвующих в проекте сторон.

А.2 Запрос исходных данных

Данная работа состоит из следующей задачи:

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

А.З Выбор процессов, работ и задач

Данная работа состоит из следующих задач:

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

А.З.2 Дополнительные процессы, работы и задачи, выбранные по А.3.1, но не описанные в настоящем стандарте, следует установить в самом договоре. Следует оценить организационные процессы жизненного цикла (раздел 7 настоящего стандарта) с точки зрения их соответствия выбранным процессам, работам и задачам.

А.3.3 В настоящем стандарте имеются задачи, требования к которым содержат слова «должен» или «должны». Эти задачи следует тщательно проанализировать на предмет сохранения или исключения из проекта или данной области деятельности. К обязательно рассматриваемым факторам относятся: риск, стоимость, график работ, выполнимость, объем, критичность и интерфейс с пользователем.

А.4 Документирование решений по адаптации и их обоснование

Данная работа состоит из следующей задачи:

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

ПРИЛОЖЕНИЕ В (справочное)

Руководство по адаптации

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

B.1 Общее руководство по адаптации

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

В.2 Адаптация процесса разработки

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

a. для программного продукта, встроенного или присоединенного к системе, следует рассмотреть все работы в процессе и выяснить, требуется ли от разработчика выполнение или обеспечение работ по созданию системы;

b. для отдельно поставляемого программного продукта работы по созданию системы (см. 5.3.2, 5.3.3, 5.3.10 и 5.3.11 настоящего стандарта) могут не потребоваться, но должны быть рассмотрены.

В.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 настоящего стандарта). Выполняется организацией для эффективного управления реализуемыми процессами и усовершенствования их. Проводится без учета требований проекта или договора.

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

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

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

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

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

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

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