ГОСТ Р ИСО/МЭК 12207-99 Информационная технология. Процессы жизненного цикла программных средств

Информационнаятехнология

ПРОЦЕССЫ ЖИЗНЕННОГО ЦИКЛА
ПРОГРАММНЫХ СРЕДСТВ

ГОССТАНДАРТ РОССИИ

Москва

Предисловие

1 РАЗРАБОТАН Всероссийским научно-исследовательским институтомстандартизации (ВНИИстандарт) Госстандарта России

ВНЕСЕН Техническим комитетом по стандартизации ТК 22 «Информационнаятехнология»

2 ПРИНЯТ И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 23декабря 1999 г. № 675-ст

3 Настоящий стандарт содержит полный аутентичный текст международногостандарта ИСО/МЭК 12207-95 «Информационная технология. Процессы жизненногоцикла программных средств»

4 ВВЕДЕН ВПЕРВЫЕ

5ПЕРЕИЗДАНИЕ. Июль 2003 г.

СОДЕРЖАНИЕ

Введение

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

Данная структура охватываетжизненный цикл программных средств от концепции замыслов через определение иобъединение процессов для заказа и поставки программных продуктов и услуг.Кроме того, данная структура предназначена для контроля и модернизации данныхпроцессов.

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

Информационная технология

ПРОЦЕССЫ ЖИЗНЕННОГО ЦИКЛА ПРОГРАММНЫХСРЕДСТВ

Дата введения 2000-07-01

1 Область применения

1.1. Назначение

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

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

1.2 Область распространения

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

Примечание - Процессы, реализуемые вжизненном цикле программных средств, должны быть совместимы с процессами,реализуемыми в жизненном цикле системы.

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

Стандарт не распространяетсяна готовые программные продукты, если они не входят в поставляемый продукт.

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

1.3 Адаптация настоящего стандарта

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

Примечание - В договоре могут бытьдополнительно предусмотрены уникальные или специальные процессы, работы изадачи.

1.4 Соответствие

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

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

1.5 Ограничения

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

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

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

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

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

В тексте настоящегостандарта приведен ряд перечней задач, однако ни один из перечней нельзясчитать исчерпывающим, и они приведены в качестве примеров.

2 Нормативные ссылки

В настоящем стандартеиспользованы ссылки на следующие стандарты:

ГОСТР ИСО 9001-96* Системы качества. Модель обеспечения качества припроектировании, разработке, производстве, монтаже и обслуживании

^*Действует до 15 декабря 2003 г.

ГОСТ Р ИСО 9001-2001Системы менеджмента качества. Требования

ГОСТР ИСО/МЭК 9126-93 Информационная технология. Оценка программной продукции.Характеристики качества и руководства по их применению

ИСО/МЭК 2382-1-93^**Информационная технология. Словарь. Часть 1. Основополагающие термины

ИСО/МЭК 2382-20-90^**Информационная технология. Словарь. Часть 20. Разработка систем

ИСО 8402-94**Управление качеством и обеспечение качества. Словарь

^** Оригиналы международных стандартовИСО/МЭК - во ВНИИКИ Госстандарта России.

3 Определения

В настоящем стандартеприменяются термины с соответствующими определениями по ИСО/МЭК 2382-1, ИСО/МЭК2382-20 и ИСО 8402, атакже приведенные ниже:

Примечание - Продукт может рассматриватьсякак часть системы или как приложение.

3.1 заказчик (acquirer):Организация, которая приобретает или получает систему, программный продукт илипрограммную услугу от поставщика.

Примечание - Заказчиком может быть: оптовыйили розничный покупатель, клиент, владелец, пользователь.

3.2 заказ (acquisition):Процесс приобретения системы, программного продукта или программной услуги.

3.3 соглашение (agreement):Определение границ и условий, при которых будут осуществляться рабочиевзаимоотношения.

3.4 аудит (audit):Проверка, выполняемая компетентным органом (лицом) с целью обеспечениянезависимой оценки степени соответствия программных продуктов или процессовустановленным требованиям.

3.5 базовая линия (baseline):Официально принятая версия элемента конфигурации, независимая от среды,формально обозначенная и зафиксированная в конкретный момент времени жизненногоцикла элемента конфигурации.

3.6 элемент конфигурации (configuration item): Объект внутри конфигурации, который удовлетворяетфункции конечного использования и может быть однозначно определен в даннойэталонной точке.

3.7 договор (contract):Обязательное соглашение между двумя сторонами, подкрепленное законодательно,или аналогичное соглашение внутри данной организации: по предоставлениюпрограммной услуги; на поставку, разработку, производство, эксплуатацию илисопровождение программного продукта.

3.8 разработчик (developer):Организация, выполняющая работы по разработке (включая анализ требований,проектирование, приемочные испытания) в процессе жизненного цикла программныхсредств.

3.9 оценка (evaluation):Систематическое определение степени соответствия объекта установленнымкритериям.

3.10 программно-аппаратноесредство (firmware): Сочетание технических устройств и машинных командили используемых вычислительной машиной данных, постоянно хранящихся натехническом устройстве в виде постоянного программного средства. Данноепрограммное средство не может изменяться только средствами программирования.

3.11 модель жизненногоцикла (life cycle model):Структура, состоящая из процессов, работ и задач, включающих в себя разработку,эксплуатацию и сопровождение программного продукта, охватывающая жизнь системыот установления требований к ней до прекращения ее использования.

3.12 персоналсопровождения (maintainer): Организация, которая выполняет работы посопровождению.

3.13 надзор (monitoring):Проверка заказчиком или третьей стороной состояния работ, выполняемыхпоставщиком, и их результатов.

3.14 непоставляемоеизделие (non-deliverable item):Техническое или программное средство, которое не поставляется по условиямдоговора, но может быть применено при создании программного продукта.

3.15 готовый продукт (off-the-shelf product): Ранее разработанный и доступный для приобретенияпродукт, пригодный для использования в поставляемом или модифицированном виде.

3.16 оператор (operator):Организация, эксплуатирующая систему.

3.17 процесс (process):Набор взаимосвязанных работ, которые преобразуют исходные данные в выходныерезультаты.

Примечание - Термин «работы» подразумеваетиспользование ресурсов (См. 1.2 ИСО8402).

3.18 квалификация (qualification): Процесс демонстрации возможности объекта выполнять установленныетребования (См. 2.13 ИСО 8402).

3.19 квалификационноетребование (qualification requirement): Набор критериев илиусловий, которые должны быть удовлетворены для того, чтобы квалифицироватьпрограммный продукт на соответствие установленным требованиям и готовность киспользованию в заданных условиях эксплуатации.

3.20 квалификационноеиспытание (qualification testing): Испытание (тестирование),проводимое разработчиком, при необходимости санкционированное заказчиком, длядемонстрации того, что программный продукт удовлетворяет установленнымтребованиям и готов к использованию в заданных условиях эксплуатации.

3.21 обеспечение качества(quality assurance): Все запланированные исистематически выполняемые в рамках системы качества работы; при необходимостиобъективные доказательства, обеспечивающие уверенность в том, что объект будетполностью соответствовать установленным требованиям качества.

Примечания

1 Существуюткак внешние, так и внутренние цели обеспечения качества:

a) внутреннееобеспечение качества - внутри организации обеспечение качества создаетуверенность у руководства;

b) внешнееобеспечение качества - в договорных или других ситуациях обеспечение качествасоздает уверенность у потребителя или других лиц.

2 Некоторыевиды работ по управлению качеством и обеспечению качества взаимосвязаны.

3 Еслитребования к качеству не полностью отражают потребности пользователя, тообеспечение качества может не создать достаточной уверенности. (См. 3.5 ИСО8402).

3.22 выпуск (release): Конкретная версияэлемента конфигурации, которая доступна для реализации конкретной цели(например, тестируемый выпуск).

3.23 заявка на подряд (request for proposal [tender]): Документ, используемыйзаказчиком в качестве средства для объявления о своих намерениях выступить вкачестве потенциального покупателя конкретной системы, программного продуктаили программной услуги.

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

3.25 защита (security):Сохранение информации и данных так, чтобы недопущенные к ним лица или системыне могли их читать или изменять, а допущенные лица или системы неограничивались в доступе к ним.

3.26 программный продукт (software product): Набор машинных программ, процедур и, возможно,связанных с ними документации и данных.

3.27 программная услуга (software service): Выполнение работ, заданий или обязанностей,связанных с программным продуктом, таких как разработка, сопровождение илиэксплуатация.

3.28 программный модуль (software unit): Отдельно компилируемая часть программного кода(программы).

3.29 техническое задание (statement of work): Документ, используемыйзаказчиком в качестве средства для описания и определения задач, выполняемыхпри реализации договора.

3.30 поставщик (supplier):Организация, которая заключает договор с заказчиком на поставку системы,программного продукта или программной услуги на условиях, оговоренных вдоговоре.

Примечания

1 Синонимамитермина «поставщик» являются термины «подрядчик», «производитель», «оптовик»или «продавец».

2 Заказчикможет определить в качестве поставщика подразделение собственной организации.

3.31 система (system): Комплекс, состоящий изпроцессов, технических и программных средств, устройств и персонала, обладающийвозможностью удовлетворять установленным потребностям или целям.

3.32 тестовое покрытие (test coverage): Степень, до которой с помощью контрольныхпримеров проверяют требования к системе или программному продукту.

3.33 тестируемость (testability):Степень, до которой могут быть запланированы объективность и реализуемостьтестирования, проверяющего соответствие требованию.

3.34 пользователь (user):Лицо или организация, которое использует действующую систему для выполненияконкретной функции.

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

3.35 аттестация (validation):Подтверждение экспертизой и представлением объективных доказательств того, чтоконкретные требования к конкретным объектам полностью реализованы.

Примечания

1 В процессепроектирования и разработки аттестация связана с экспертизой продукта в целяхопределения его соответствия потребностям пользователя.

2 Аттестациюобычно проводят для конечного продукта в установленных условиях эксплуатации.При необходимости аттестация может проводиться на более ранних стадиях.

3 Термин«аттестован» используется для обозначения соответствующих состояний объекта.

4 Может бытьпроведен ряд аттестаций, если они преследуют различные цели. (См. 2.18 ИСО8402).

3.36 верификация (verification): Подтверждение экспертизойи представлением объективных доказательств того, что конкретные требования полностьюреализованы.

Примечания

1 В процессепроектирования и разработки верификация связана с экспертизой результатовданной работы в целях определения их соответствия установленным требованиям.

2 Термин«верифицирован» используется для обозначения соответствующих состоянийпроверенного объекта. (См. 2.17 ИСО 8402).

3.37 версия (version): Определенный экземпляробъекта.

Примечание - В результате модификацииверсии программного продукта появляется новая версия, подвергающаяся управлениюконфигурацией.

4 Прикладное применение настоящего стандарта

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

4.1 Построение стандарта

4.1.1Процессы жизненного цикла

В настоящем стандартеработы, которые могут выполняться в жизненном цикле программных средств,распределены по пяти основным, восьми вспомогательным и четырем организационнымпроцессам. Каждый процесс жизненного цикла разделен на набор работ; каждаяработа разделена на набор задач. Нумерация подразделов (пунктов) означает: а.b -процесс; а.b.с - работа; a.b.c.d - задача. Все процессыжизненного цикла описаны ниже и изображены на рисунке 1.

 

Рисунок 1 - Структура стандарта

4.1.1.1 Основные процессыжизненного цикла

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

1) Процесс заказа (подраздел5.1).Определяет работы заказчика, то есть организации, которая приобретает систему,программный продукт или программную услугу.

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

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

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

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

4.1.1.2 Вспомогательныепроцессы жизненного цикла

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

1) Процесс документирования(подраздел 6.1).Определяет работы по описанию информации, выдаваемой в процессе жизненногоцикла.

2) Процесс управленияконфигурацией (подраздел 6.2). Определяет работы по управлениюконфигурацией.

3) Процесс обеспечениякачества (подраздел 6.3). Определяет работы по объективномуобеспечению того, чтобы программные продукты и процессы соответствовалитребованиям, установленным для них, и реализовывались в рамках утвержденныхпланов. Совместные анализы, аудиторские проверки, верификация и аттестациямогут использоваться в качестве методов обеспечения качества.

4) Процесс верификации(подраздел 6.4).Определяет работы (заказчика, поставщика или независимой стороны) поверификации программных продуктов по мере реализации программного проекта.

5) Процесс аттестации(подраздел 6.5).Определяет работы (заказчика, поставщика или независимой стороны) по аттестациипрограммных продуктов программного проекта.

6) Процесс совместногоанализа (подраздел 6.6). Определяет работы по оценке состояния ирезультатов какой-либо работы. Данный процесс может использоваться двумя любымисторонами, когда одна из сторон (проверяющая) проверяет другую сторону(проверяемую) на совместном совещании.

7) Процесс аудита (подраздел6.7).Определяет работы по определению соответствия требованиям, планам и договору.Данный процесс может использоваться двумя сторонами, когда одна из сторон(проверяющая) контролирует программные продукты или работы другой стороны(проверяемой).

8) Процесс решения проблемы(подраздел 6.8).Определяет процесс анализа и устранения проблем (включая несоответствия),независимо от их характера и источника, которые были обнаружены во времяосуществления разработки, эксплуатации, сопровождения или других процессов.

4.1.1.3 Организационныепроцессы жизненного цикла

Организационные процессыжизненного цикла (раздел 7) состоят из четырех процессов. Они применяются в какой-либоорганизации для создания и реализации основной структуры, охватывающейвзаимосвязанные процессы жизненного цикла и соответствующий персонал, а такжедля постоянногосовершенствования данной структуры и процессов. Эти процессы, как правило,являются типовыми, независимо от области реализации конкретных проектов идоговоров; однако уроки, извлеченные из таких проектов и договоров,способствуют совершенствованию организационных вопросов. Организационнымипроцессами являются:

1) Процесс управления (подраздел7.1).Определяет основные работы по управлению, включая управление проектом, приреализации процессов жизненного цикла.

2) Процесс созданияинфраструктуры (подраздел 7.2). Определяет основные работы по созданиюосновной структуры процесса жизненного цикла.

3) Процессусовершенствования (подраздел 7.3). Определяет основные работы, которыеорганизация (заказчика, поставщика, разработчика, оператора, персоналасопровождения или администратора другого процесса) выполняет при создании,оценке, контроле и усовершенствовании выбранных процессов жизненного цикла.

4) Процесс обучения(подраздел 7.4).Определяет работы по соответствующему обучению персонала.

4.1.2 Процесс адаптации

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

4.1.3 Взаимосвязи междупроцессами и организациями

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

5Основные процессы жизненного цикла

В настоящем разделеопределены следующие основные процессы жизненного цикла:

1) процесс заказа;

2) процесс поставки;

3) процесс разработки;

4) процесс эксплуатации;

5) процесс сопровождения.

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

5.1Процесс заказа

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

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

Заказчик управляет процессомзаказа на проектном уровне в соответствии с процессом управления (подраздел 7.1),который конкретизируется в данном процессе; определяет инфраструктуру дляданного процесса в соответствии с процессом создания инфраструктуры (подраздел 7.2);адаптирует данный процесс к условиям проекта в соответствии с процессомадаптации (приложение А) и управляет процессом заказа наорганизационном уровне в соответствии с процессами усовершенствования(подраздел 7.3)и обучения (подраздел 7.4).

Список работ. Данный процесссостоит из следующих работ:

1) подготовка;

2) подготовка заявки наподряд;

3) подготовка икорректировка договора;

4) надзор за поставщиком;

5) приемка и закрытиедоговора.

5.1.1 Подготовка

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

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

5.1.1.2Заказчик должен определить и проанализировать требования к системе. Требованияк системе должны охватывать функциональные, коммерческие, организационные ипотребительские аспекты системы, а также требования безопасности, защиты идругие критические требования наряду с требованиями к проектированию,тестированию и соответствующим стандартам и процедурам.

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

5.1.1.4Заказчик может выполнить определение и анализ требований к программнымсредствам сам или поручить решение этой задачи поставщику.

5.1.1.5 При решении задач,определенных в 5.1.1.2 и 5.1.1.4, должениспользоваться процесс разработки (подраздел 5.3).

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

a) покупка готовогопрограммного продукта, удовлетворяющего определенным требованиям;

b) разработка программногопродукта или обеспечение программной услуги собственными силами;

c) разработка программногопродукта или получение программной услуги на договорной основе;

d) комбинации поперечислениям а), b), с);

e) модернизациясуществующего программного продукта или услуги.

5.1.1.7 При приобретенииготового программного продукта заказчик должен получить гарантии того, чтоудовлетворены следующие условия:

a) программный продуктсоответствует установленным требованиям;

b) имеется в наличиисоответствующая документация;

c) соблюдены правасобственности, использования, лицензирования и гарантии;

d) предусмотрена последующаяподдержка программного продукта.

5.1.1.8 Заказчик долженподготовить, документально оформить и выполнить план заказа. План долженсодержать:

a) требования к системе;

b) планируемую загрузкусистемы;

c) тип реализуемогодоговора;

d) обязанности организаций,участвующих в договоре;

e) обеспечение подходов креализации договора;

f) анализ возможныхрискованных ситуаций, а также методы управления такими ситуациями.

5.1.1.9 Заказчик долженопределить и документально оформить принятые правила и условия (критерии)реализации договора.

5.1.2 Подготовка заявки наподряд

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

5.1.2.1 Заказчик должендокументально оформить требования к заказу (например, в виде заявки на подряд),состав которых зависит от вариантов реализации заказа, выбранных в соответствиис 5.1.1.6.Соответствующая документация по заказу должна содержать:

a) требования к системе;

b) описание областиприменения системы;

c) указания для участниковторгов;

d) список программныхпродуктов;

e) сроки и условияреализации заказа;

f) правила контроля надсубподрядчиками;

g) технические ограничения(например, по условиям эксплуатации).

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

5.1.2.3 В документации позаказу должны быть также определены контрольные пункты договора, при выполнениикоторых анализируется и проверяется деятельность поставщика (см. подразделы 6.6 и6.7).

5.1.2.4 Требования к заказудолжны быть представлены организации, выбранной для выполнения работ в процессезаказа.

5.1.3 Подготовка икорректировка договора

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

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

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

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

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

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

Примечание - Заказчик определяет,используется ли при применении настоящего стандарта термин «договор» или«соглашение».

5.1.4 Надзор за поставщиком

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

5.1.4.1 Заказчик долженосуществлять надзор за работами поставщика в соответствии с процессамисовместного анализа (подраздел 6.6) и аудита (подраздел 6.7). При необходимостизаказчик должен дополнять текущий надзор процессами верификации (подраздел 6.4)и аттестации (подраздел 6.5).

5.1.4.2 Заказчик долженвзаимодействовать с поставщиком по вопросам своевременного взаимообмена всейнеобходимой информацией и решения всех возникающих проблем.

5.1.5 Приемка и закрытиедоговора

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

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

5.1.5.2 Заказчик долженпроверить готовность поставщика к проведению приемки и провести приемочныеиспытания поставляемого программного продукта или услуги, а затем принять их отпоставщика при выполнении всех условий приемки. Процедура приемки должнасоответствовать условиям 5.1.1.9.

5.1.5.3 После приемкизаказчик должен принять на себя ответственность за управление конфигурациейпоставленного программного продукта (см. подраздел 6.2).

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

5.2Процесс поставки

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

Поставщик управляетпроцессом поставки на проектном уровне в соответствии с процессом управления(подраздел 7.1),который конкретизируется в данном процессе; определяет инфраструктуру для данногопроцесса в соответствии с процессом создания инфраструктуры (подраздел 7.2);адаптирует данный процесс к условиям проекта в соответствии с процессомадаптации (приложение А) и управляет процессом поставки наорганизационном уровне в соответствии с процессами усовершенствования(подраздел 7.3)и обучения (подраздел 7.4).

Список работ. Данный процесссостоит из следующих работ:

1) подготовка;

2) подготовка ответа;

3) подготовка договора;

4) планирование;

5) выполнение и контроль;

6) проверка и оценка;

7) поставка и закрытиедоговора.

5.2.1 Подготовка

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

5.2.1.1 Поставщик проводитанализ требований, установленных в заявке на подряд, принимая во вниманиеорганизационные вопросы и другие установленные правила.

5.2.1.2 Поставщик долженпринять решение об участии в конкурсе на подряд или о подписании договора.

5.2.2 Подготовка ответа

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

5.2.2.1 Поставщик долженсформулировать и подготовить предложение в ответ на заявку о подряде, включаясвои рекомендации по адаптации настоящего стандарта.

5.2.3 Подготовка договора

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

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

5.2.3.2 Поставщик можетпредложить внести изменения в текст договора по согласованию с заказчиком.

5.2.4Планирование

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

5.2.4.1 Поставщик долженпровести анализ требований к заказу в целях создания структуры управленияреализацией проекта и обеспечения качества поставляемого программного продуктаили услуги.

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

5.2.4.3 Поставщик долженустановить требования к планам управления и обеспечения проекта в целом,обеспечения качества поставляемого программного продукта или услуги. Требованияк планам должны охватывать потребности в используемых ресурсах иформулироваться с привлечением заказчика.

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

a) разработка программногопродукта или предоставление программной услуги с использованием внутреннихресурсов поставщика;

b) разработка программногопродукта или предоставление программной услуги путем заключения субподрядныхдоговоров;

c) получение готовыхпрограммных продуктов от внутренних или внешних источников;

d) комбинации поперечислениям а), b), с).

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

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

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

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

d) управленияхарактеристиками качества создаваемого программного продукта или предоставляемойпрограммной услуги. Допускается разработка отдельных планов по обеспечениюкачества;

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

f) управлениясубподрядчиками, включая выбор субподрядчиков и взаимоотношения междусубподрядчиком и заказчиком;

g) обеспечения качества (см.подраздел 6.3);

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

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

j) взаимоотношений спользователем, которые реализуются такими средствами, как выполнение требуемыхнастроек, демонстрация прототипов и оценки;

k)управления критическими ситуациями, то есть управления областями проекта,которые связаны с потенциальными техническими, финансовыми и плановымизатруднениями;

l)обеспечения защиты, включая правила доступа к информации на уровне каждойпроектной организации;

m) подтверждения статусапоставляемой продукции, обеспечиваемые такими средствами, как инструкции,обязательная сертификация, права собственности, использования ираспространения, гарантии и лицензионные права;

n) средств для планирования,надзора и отчетности;

p) обучения персонала (см.подраздел 7.4).

5.2.5 Выполнение и контроль

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

5.2.5.1 Поставщик должен реализоватьпланы управления проектом, разработанные в соответствии с 5.2.4.

5.2.5.2 Поставщик должен:

a) разработать программныйпродукт в соответствии с процессом разработки (подраздел 5.3);

b) провести опытнуюэксплуатацию программного продукта в соответствии с процессом эксплуатации(подраздел 5.4);

c) сопровождать программныйпродукт в соответствии с процессом сопровождения (подраздел 5.5).

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

a) надзор за техническойреализацией, расходами, выполнением планов и отчетностью о ходе проекта;

b) выявление возникающихпроблем, их документальное оформление, анализ и решение.

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

5.2.5.5 Поставщик долженвзаимодействовать с независимой верифицирующей, аттестующей или испытательнойорганизацией в соответствии с установленными договорными или проектнымипланами.

5.2.5.6 Поставщик долженвзаимодействовать с другими исполнителями договора в соответствии сустановленными договорными или проектными планами.

5.2.6 Проверка и оценка

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

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

5.2.6.2 Поставщик долженпроводить или участвовать в совещаниях, подготовке приемки, приемочных испытаниях,совместных анализах и аудиторских проверках вместе с заказчиком в соответствиис договором и проектными планами. Совместные анализы должны проводиться всоответствии с подразделом 6.6, а аудиторские проверки - в соответствии сподразделом 6.7.

5.2.6.3 Поставщик долженвыполнять верификацию и аттестацию в соответствии с подразделами 6.4 и 6.5 для того, чтобыпродемонстрировать заказчику полное соответствие программных продуктов илиуслуг и процессов установленным требованиям.

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

5.2.6.5 Поставщик долженобеспечить заказчику доступ к своим средствам и средствам субподрядчиков дляпроверки программных продуктов или услуг в соответствии с договорными ипроектными планами.

5.2.6.6 Поставщик долженвыполнять работы по обеспечению качества в соответствии с подразделом 6.3.

5.2.7 Поставка и закрытиедоговора

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

5.2.7.1 Поставщик долженпоставить программный продукт или услугу заказчику в соответствии с условиямидоговора.

5.2.7.2 Поставщик долженпомогать заказчику в поддержке поставленного программного продукта или услуги всоответствии с условиями договора.

5.3Процесс разработки

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

Разработчик управляетпроцессом разработки на проектном уровне в соответствии с процессом управления(подраздел 7.1),который конкретизируется в данном процессе; определяет инфраструктуру для данногопроцесса в соответствии с процессом создания инфраструктуры (подраздел 7.2);адаптирует данный процесс к условиям проекта в соответствии с процессомадаптации (приложение А) и управляет процессом разработки наорганизационном уровне в соответствии с процессами усовершенствования(подраздел 7.3)и обучения (подраздел 7.4). Если разработчиком является поставщикразрабатываемого программного продукта, то разработчик должен также выполнятьпроцесс поставки (подраздел 5.2).

Список работ. Данный процесссостоит из следующих работ:

1) подготовка процесса;

2) анализ требований ксистеме;

3) проектирование системнойархитектуры;

4) анализ требований кпрограммным средствам;

5) проектированиепрограммной архитектуры;

6) техническоепроектирование программных средств;

7) программирование итестирование программных средств;

8) сборка программныхсредств;

9) квалификационныеиспытания программных средств;

10) сборка системы;

11) квалификационныеиспытания системы;

12) ввод в действиепрограммных средств;

13) обеспечение приемкипрограммных средств.

5.3.1 Подготовка процесса

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

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

Примечание - Данные работы и задачи могутпересекаться или взаимодействовать и выполняться итерационно или рекурсивно.

5.3.1.2 Разработчик должен:

a) документально оформитьвыходные результаты в соответствии с процессом документирования (подраздел 6.1);

b) подвергнуть выходныерезультаты процессу управления конфигурацией (подраздел 6.2) и выполнятьконтроль изменений конфигурации в соответствии с данным процессом;

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

d)выполнить вспомогательные процессы (раздел 6) в соответствии с условиямидоговора.

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

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

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

5.3.2Анализ требований к системе

Данная работа состоит изследующих задач, которые разработчик должен выполнить или обеспечить ихвыполнение:

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

5.3.2.2 Требования к системедолжны быть оценены с учетом следующих критериев (при этом результаты оценокдолжны быть документально оформлены):

a) учет потребностейзаказчика;

b) соответствие потребностямзаказчика;

c) тестируемость;

d) выполнимость проектированиясистемной архитектуры;

e) возможность эксплуатациии сопровождения.

5.3.3Проектирование системной архитектуры

Данная работа состоит изследующих задач, которые разработчик должен выполнить или обеспечить ихвыполнение:

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

5.3.3.2 Системнаяархитектура и требования к объектам архитектуры должны быть оценены с учетомследующих критериев (при этом результаты оценок должны быть документальнооформлены):

a) учет требований ксистеме;

b) соответствие требованиямк системе;

c) соответствие используемыхстандартов и методов проектирования;

d) возможность программныхобъектов архитектуры выполнять установленные для них требования;

e) возможности эксплуатациии сопровождения.

5.3.4 Анализ требований кпрограммным средствам

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

5.3.4.1 Разработчик долженустановить и документально оформить следующие требования к программнымсредствам, включая технические требования к характеристикам качества(рекомендации по определению характеристик качества приведены в ГОСТР ИСО/МЭК 9126):

a) функциональные итехнические требования, включая производительность, физические характеристики иокружающие условия, под которые должен быть создан программный объектархитектуры (далее - программный объект);

b) требования к внешниминтерфейсам программного объекта архитектуры;

c) квалификационныетребования;

d) требования безопасности,включая требования, относящиеся к методам эксплуатации и сопровождения,воздействию окружающей среды и травмобезопасности персонала;

e) требования защиты,включая требования, относящиеся к допустимой точности информации;

f) эргономическиетребования, включая требования, относящиеся к ручным операциям, взаимодействию«человек-машина», персоналу и областям, требующим концентрации вниманиячеловека, связанным с чувствительностью объекта к ошибкам человека иобученности персонала;

g) требования к определениюданных и базе данных;

h) требования по вводу вдействие и приемке поставляемого программного продукта на объекте(ах)эксплуатации и сопровождения;

i) требования к документациипользователя;

j) требования к эксплуатацииобъекта пользователем;

k)требования к обслуживанию пользователя.

5.3.4.2 Разработчик долженоценить требования к программным средствам по следующим критериям (при этом результатыоценок должны быть документально оформлены):

a) учет требований к системеи проекту системы;

b) внешняя согласованность стребованиями к системе;

c) внутренняясогласованность требований к объектам между собой;

d) тестируемость требований;

e) выполнимость программногопроекта;

f) возможность эксплуатациии сопровождения.

5.3.4.3 Разработчик долженпровести совместный анализ(ы) в соответствии с подразделом 6.6.После успешного проведения анализа(ов) должно быть зафиксировано состояниетребований к программному объекту.

5.3.5 Проектированиепрограммной архитектуры

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

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

5.3.5.2 Разработчик долженразработать и документально оформить общий (эскизный) проект внешнихинтерфейсов программного объекта и интерфейсов между компонентами объекта.

5.3.5.3 Разработчик долженразработать и документально оформить общий (эскизный) проект базы данных.

5.3.5.4 Разработчик долженразработать и документально оформить предварительные версии документациипользователя.

5.3.5.5 Разработчик долженопределить и документально оформить предварительные общие требования киспытаниям (тестированию) программного объекта и график сборки программногопродукта.

5.3.5.6 Разработчик долженоценить архитектуру программного объекта и эскизные проекты интерфейсов и базыданных по следующим критериям (при этом результаты оценок должны бытьдокументально оформлены):

a) учет требований кпрограммному объекту;

b) внешняя согласованность стребованиями к программному объекту;

c) внутренняясогласованность между компонентами программного объекта;

d) соответствие методовпроектирования и используемых стандартов;

e) возможность техническогопроектирования;

f) возможность эксплуатациии сопровождения.

5.3.5.7 Разработчик долженпровести совместный анализ(ы) в соответствии с подразделом 6.6.

5.3.6 Техническоепроектирование программных средств

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

5.3.6.1 Разработчик долженразработать технический проект для каждого компонента программного объекта.Компоненты программного объекта должны быть уточнены на уровне программныхмодулей, которые можно программировать (кодировать), компилировать итестировать независимо. Должно быть обеспечено распределение техническихтребований к компонентам программного объекта между программными модулями.Технический проект должен быть документально оформлен.

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

5.3.6.3 Разработчик долженразработать и документально оформить технический проект базы данных.

5.3.6.4 Разработчик должен,при необходимости, уточнить документацию пользователя.

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

5.3.6.6 Разработчик долженуточнить общие требования к испытанию (тестированию) и программе сборкипрограммных средств.

5.3.6.7 Разработчик долженоценить технический проект и требования к тестированию по следующим критериям(при этом результаты оценок должны быть документально оформлены):

a) учет требований кпрограммному объекту;

b) внешнее соответствиеспроектированной архитектуре;

c) внутренняясогласованность между компонентами программного объекта и программнымимодулями;

d) соответствие методовпроектирования и используемых стандартов;

e) возможность тестирования;

f) возможность эксплуатациии сопровождения.

5.3.6.8 Разработчик долженпровести совместный анализ(ы) в соответствии с подразделом 6.6.

5.3.7 Программирование итестирование программных средств

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

5.3.7.1 Разработчик долженразработать и документально оформить следующие продукты:

a) каждый программный модульи базу данных;

b) процедуры испытаний(тестирования) и данные для тестирования каждого программного модуля и базы данных.

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

5.3.7.3 Разработчик, принеобходимости, должен уточнить документацию пользователя.

5.3.7.4 Разработчик долженуточнить общие требования к тестированию и программу сборки программныхсредств.

5.3.7.5 Разработчик долженоценить запрограммированные элементы программного объекта и результаты ихтестирования по следующим критериям (при этом результаты оценок должны бытьдокументально оформлены):

a) учет требований кпрограммному объекту и проекту объекта в целом;

b) внешнее соответствиетребованиям и проекту программного объекта;

c) внутреннее соответствие междутребованиями к программным модулям;

d) тестовое покрытие всехмодулей;

e) соответствие методовпрограммирования и используемых для них стандартов;

f) возможность сборки итестирования;

g) возможность эксплуатациии сопровождения.

5.3.8 Сборка программныхсредств

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

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

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

5.3.8.3 Разработчик, принеобходимости, должен уточнить документацию пользователя.

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

5.3.8.5 Разработчик долженоценить план сборки, проект, запрограммированный программный объект,проведенные испытания, результаты тестирования и документацию пользователя последующим критериям (при этом результаты оценок должны быть документальнооформлены):

a) учет требований ксистеме;

b) внешнее соответствиетребованиям к системе;

c) внутренняясогласованность между программными объектами;

d) тестовое покрытиетребований к программному объекту;

e) соответствие используемыхиспытательных стандартов и методов испытаний;

f) соответствие ожидаемымрезультатам;

g) выполнимостьквалификационного испытания программного объекта;

h) возможность эксплуатациии сопровождения.

5.3.8.6 Разработчик долженпроводить совместный анализ(ы) в соответствии с подразделом 6.6.

5.3.9 Квалификационныеиспытания программных средств

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

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

5.3.9.2 Разработчик, принеобходимости, должен уточнить документацию пользователя.

5.3.9.3 Разработчик долженоценить проект, запрограммированный программный объект, проведенные испытания,результаты испытаний и документацию пользователя по следующим критериям (приэтом результаты оценок должны быть документально оформлены):

a) тестовое покрытиетребований к программному объекту;

b) соответствие ожидаемымрезультатам;

c) возможность сборки итестирования системы (при их проведении);

d) возможность эксплуатациии сопровождения.

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

5.3.9.5 После успешногозавершения аудиторских проверок, если они проводились, разработчик должен:

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

b) определить состояниеконфигурации (базовую линию) проекта и программ данного программного объекта.

Примечание - Квалификационное испытаниеможет быть выполнено в процессах верификации (подраздел 6.4) илиаттестации (подраздел 6.5).

5.3.10Сборка системы

Данная работа состоит изследующих задач, которые разработчик должен выполнить или обеспечить ихвыполнение:

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

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

5.3.10.3 Собранная системадолжна быть оценена по следующим критериям (при этом результаты оценок должныбыть документально оформлены):

a) тестовое покрытиетребований к системе;

b) соответствие методовтестирования и используемых стандартов;

c) соответствие ожидаемымрезультатам;

d)выполнимость квалификационных испытаний системы;

e) возможность эксплуатациии сопровождения.

5.3.11Квалификационные испытания системы

Данная работа состоит изследующих задач, которые разработчик должен выполнить или обеспечить ихвыполнение:

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

5.3.11.2 Система должна бытьоценена по следующим критериям (при этом результаты оценок должны бытьдокументально оформлены):

a) тестовое покрытиетребований к системе;

b) соответствие ожидаемымрезультатам;

c) возможность эксплуатациии сопровождения.

5.3.11.3 Разработчик долженобеспечить проведение аудиторской проверки(ок) в соответствии с подразделом 6.7.Результаты аудиторской проверки(ок) должны быть документально оформлены.

Примечание - Этот подпункт не применяется ктем объектам программной конфигурации, для которых аудиторские проверки былипроведены ранее.

5.3.11.4 После успешного завершенияаудиторских проверок, если они проводились, разработчик должен:

a) доработать и подготовитьпоставляемый программный продукт для обеспечения приемки и ввода его вдействие;

b) определить состояниеконфигурации (базовую линию) проекта и программ каждого объекта программнойконфигурации.

Примечание - Квалификационное испытаниесистемы может быть выполнено в процессах верификации (подраздел 6.4)или аттестации (подраздел 6.5).

5.3.12 Ввод в действиепрограммных средств

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

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

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

5.3.13Обеспечение приемки программных средств

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

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

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

5.3.13.3 Разработчик должен,соблюдая условия договора, обеспечить первоначальное и непрерывное обучение иподдержку персонала заказчика.

5.4Процесс эксплуатации

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

Оператор управляет процессомэксплуатации на проектном уровне в соответствии с процессом управления(подраздел 7.1),который конкретизируется в данном процессе; определяет инфраструктуру дляданного процесса в соответствии с процессом создания инфраструктуры (подраздел 7.2);адаптирует данный процесс к условиям проекта в соответствии с процессомадаптации (приложение А) и управляет процессом эксплуатации наорганизационном уровне в соответствии с процессами усовершенствования (подраздел7.3)и обучения (подраздел 7.4). Если оператор является поставщикомпрограммной услуги, то оператор выполняет также процесс поставки (подраздел 5.2).

Список работ. Данный процесссостоит из следующих работ:

1) подготовка процесса;

2) эксплуатационныеиспытания;

3) эксплуатация системы;

4) поддержка пользователя.

5.4.1 Подготовка процесса

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

5.4.1.1 Оператор долженразработать план эксплуатации и определить набор стандартов по эксплуатации длявыполнения работ и задач данного процесса. План должен быть документальнооформлен и выполнен.

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

5.4.1.3 Оператор долженустановить процедуры для: тестирования программного продукта в эксплуатационнойсреде; ввода сообщений о проблемах и предложений об изменениях в процесссопровождения (подраздел 5.5); ввода программного продукта вэксплуатацию.

5.4.2 Эксплуатационныеиспытания

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

5.4.2.1 Для каждоговведенного в опытную эксплуатацию программного продукта оператор долженпровести эксплуатационные испытания и при соответствии результатов испытанийустановленным требованиям ввести программный продукт в промышленную эксплуатацию.

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

5.4.3 Эксплуатация системы

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

5.4.3.1 Система должнаэксплуатироваться в установленной для нее эксплуатационной среде в соответствиис документацией пользователя.

5.4.4 Поддержка пользователя

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

5.4.4.1 Оператор долженобеспечить помощь и консультации пользователям в установленном порядке. Запросыпользователей и последующие ответные действия должны быть документальнооформлены и контролируемы.

5.4.4.2 Оператор должен, принеобходимости, направлять запросы пользователя для анализа и ответа в процесссопровождения (подраздел 5.5). Данные запросы должны быть приняты, аответы по планируемым и выполняемым ответным действиям должны быть направленыинициаторам запросов. Все принимаемые решения должны контролироваться вплоть доих выполнения.

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

5.5Процесс сопровождения

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

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

Персонал сопровождения управляетпроцессом сопровождения на проектном уровне в соответствии с процессомуправления (подраздел 7.1), который конкретизируется в данномпроцессе; определяет инфраструктуру для данного процесса в соответствии спроцессом создания инфраструктуры (подраздел 7.2); адаптирует данныйпроцесс к условиям проекта в соответствии с процессом адаптации (приложение А) иуправляет процессом сопровождения на организационном уровне в соответствии спроцессами усовершенствования (подраздел 7.3) и обучения (подраздел 7.4).Если персонал сопровождения является поставщиком услуги по сопровождению, онреализует процесс поставки (подраздел 5.2).

Список работ. Данный процесссостоит из следующих работ:

1) подготовка процесса;

2) анализ проблем иизменений;

3) внесение изменений;

4) проверка и приемка присопровождении;

5) перенос;

6) снятие с эксплуатации.

5.5.1 Подготовка процесса

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

5.5.1.1 Персонал сопровождениядолжен разработать, документально оформить и выполнить планы и процедуры дляпроведения работ и задач процесса сопровождения.

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

5.5.1.3 Персоналсопровождения должен реализовать процесс управления конфигурацией (подраздел 6.2)для управления изменениями существующей системы (или определить организационныйинтерфейс с данным процессом).

5.5.2 Анализ проблем иизменений

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

5.5.2.1 Персоналсопровождения должен проанализировать сообщение о проблеме или заявку навнесение изменений по их влиянию на организационные вопросы, существующуюсистему и интерфейсные связи с другими системами по следующим аспектам:

a) типу, например:корректировка, модернизация, профилактика или адаптация к новым условиям;

b) объему, например: размеруизменения, стоимости, времени на реализацию изменения;

c) критичности, например:влиянию на производительность, безопасность или защиту.

5.5.2.2 Персоналсопровождения должен продублировать или верифицировать возникшую проблему.

5.5.2.3 На основепроведенного анализа персонал сопровождения должен разработать вариантыреализации изменения.

5.5.2.4 Персоналсопровождения должен документально оформить: сообщение о проблеме или заявку навнесение изменений; результаты их анализа и варианты реализации изменений.

5.5.2.5 Персоналсопровождения должен получить согласование выбранного варианта изменения всоответствии с договором.

5.5.3 Внесение изменений

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

5.5.3.1 Персоналсопровождения должен провести анализ и определить, какие документы, программныемодули или их версии требуют изменения. Полученные результаты должны бытьдокументально оформлены.

5.5.3.2 Персоналсопровождения должен использовать процесс разработки (подраздел 5.3)для реализации изменений. Требования к процессу разработки должны бытьдополнены следующим образом:

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

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

5.5.4 Проверка и приемка присопровождении

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

5.5.4.1 Персоналсопровождения должен провести проверку внесенного изменения совместно сорганизацией, утвердившей изменение в целях подтверждения работоспособностиизмененной системы.

5.5.4.2 Персоналсопровождения должен получить подтверждение того, что внесенное изменениеудовлетворяет требованиям, установленным в договоре.

5.5.5 Перенос

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

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

5.5.5.2 Должен быть разработан,документально оформлен и выполнен план переноса объекта. К планируемым работамдолжны привлекаться пользователи. В содержание плана должны быть включены:

a) анализ и установлениетребований к переносу;

b) разработкаинструментальных средств для выполнения переноса;

c) настройка программногопродукта и данных к новым условиям эксплуатации;

d) выполнение переноса;

e) верификация переноса;

f) последующая поддержкапрежней среды.

5.5.5.3 Пользователям должнобыть направлено уведомление о планах и работах по переносу объекта. Всодержание уведомления должно быть включено:

a) объяснение того, почемупрежняя среда не может больше поддерживаться;

b) описание новой среды суказанием даты, с которой она доступна для пользователей;

c) описание других доступныхвариантов поддержки в случае прекращения поддержки прежней среды.

5.5.5.4 Для плавногоперехода в новую среду параллельно могут выполняться работы в прежней и новойсреде. В течение этого периода должно быть обеспечено необходимое обучение персоналав соответствии с условиями договора.

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

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

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

5.5.6 Снятие с эксплуатации

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

Примечание - Программный продукт можетсниматься по заявке собственника.

5.5.6.1 Должен бытьразработан, документально оформлен и реализован план снятия с эксплуатации припрекращении активной поддержки объекта эксплуатирующими и сопровождающимиорганизациями. К запланированным работам должны привлекаться пользователи. Всодержание плана должны быть включены:

a) сроки прекращения полнойили частичной поддержки;

b) требования по архивациипрограммного продукта и соответствующей документации;

c) обязательства по любымоставшимся вопросам поддержки;

d) срокиперехода, при необходимости, к новому программному продукту;

e) требования по доступу кархивным копиям данных.

5.5.6.2 Пользователи должны получитьуведомление о планах и работах по снятию с эксплуатации. В содержаниеуведомления должны быть включены:

a) описание заменяющего илимодернизированного объекта с указанием даты его доступности для пользователей;

b) объяснение того, почемупрежний программный продукт не может больше поддерживаться;

c) описание других доступныхвариантов поддержки в случае прекращения поддержки прежнего объекта.

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

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

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

6Вспомогательные процессы жизненного цикла

В данном разделе определеныследующие вспомогательные процессы жизненного цикла:

1) процесс документирования;

2) процесс управленияконфигурацией;

3) процесс обеспечениякачества;

4) процесс верификации;

5) процесс аттестации;

6) процесс совместногоанализа;

7) процесс аудита;

8) процесс решения проблем.

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

Данная организация организуети выполняет управление вспомогательным процессом на проектном уровне всоответствии с процессом управления (подраздел 7.1); определяетинфраструктуру для данного процесса в соответствии с процессом созданияинфраструктуры (подраздел 7.2); адаптирует данный процесс к условиямпроекта в соответствии с процессом адаптации (приложение А) иуправляет вспомогательным процессом на организационном уровне в соответствии спроцессами усовершенствования (подраздел 7.3) и обучения (подраздел 7.4).В качестве методов обеспечения качества могут быть использованы: совместныеанализы, аудиторские проверки, верификация и аттестация.

6.1Процесс документирования

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

Список работ. Данный процесссостоит из следующих работ:

1) подготовка процесса;

2) проектирование иразработка;

3) выпуск;

4) сопровождение.

6.1.1 Подготовка процесса

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

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

a) заголовок или наименование;

b) назначение;

c) пользователи документа;

d)процедуры и обязанности по подготовке исходных материалов, разработке,проверке, изменению, утверждению, выпуску, хранению, распространению,сопровождению и управлению конфигурацией;

e) сроки выпускапромежуточных и окончательных редакций.

6.1.2 Проектирование иразработка

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

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

6.1.2.2 Должны бытьподтверждены источник и соответствие исходных материалов для документов. Приподготовке документов могут использоваться средства автоматизациидокументирования.

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

6.1.3 Выпуск

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

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

6.1.3.2 Средства управлениядокументированием должны быть определены в соответствии с процессомуправления конфигурацией (подраздел 6.2).

6.1.4 Сопровождение

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

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

6.2Процесс управления конфигурацией

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

Примечание - Когда данный процессприменяется к другим программным продуктам или объектам, термин «программныйобъект» интерпретируется ниже соответствующим образом.

Список работ. Данный процесссостоит из следующих работ:

1) подготовка процесса;

2) определение конфигурации;

3) контроль конфигурации;

4) учет состоянийконфигурации;

5) оценка конфигурации;

6) управление выпуском ипоставка.

6.2.1 Подготовка процесса

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

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

Примечание - Данный план может быть частьюплана управления конфигурацией системы.

6.2.2 Определениеконфигурации

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

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

6.2.3 Контроль конфигурации

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

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

6.2.4 Учет состоянийконфигурации

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

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

6.2.5 Оценка конфигурации

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

6.2.5.1 Должны бытьопределены и обеспечены: функциональная законченность программных объектов сточки зрения реализации установленных к ним требований; физическаязавершенность программных объектов с точки зрения реализации в проекте ипрограммах всех внесенных изменений.

6.2.6 Управление выпуском ипоставка

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

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

6.3Процесс обеспечения качества

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

Список работ. Данный процесссостоит из следующих работ:

1) подготовка процесса;

2) обеспечение продукта;

3) обеспечение процесса;

4) обеспечение системкачества.

6.3.1 Подготовка процесса

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

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

6.3.1.2 Процесс обеспечениякачества должен быть скоординирован с соответствующими процессами верификации(подраздел 6.4),аттестации (подраздел 6.5), совместного анализа (подраздел 6.6)и аудита (подраздел 6.7).

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

a) стандарты качества,методологии, процедуры и средства для выполнения работ по обеспечению качества(или содержать ссылки на соответствующую официальную документацию);

b) процедуры проведенияанализов качества при выполнении договора и координации этих работ;

c) процедуры дляобозначения, сбора, регистрации, сопровождения и распространения информации окачестве;

d)ресурсы, графики и обязанности при проведении работ по обеспечению качества;

e) выбранные работы и задачииз вспомогательных процессов, таких как верификация (подраздел 6.4),аттестация (подраздел 6.5), совместный анализ (подраздел 6.6),аудит (подраздел 6.7) и решение проблем (подраздел 6.8).

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

6.3.1.5 Отчеты о работах изадачах по обеспечению качества должны быть доступны заказчику в соответствии сусловиями договора.

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

6.3.2 Обеспечение продукта

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

6.3.2.1 Должно бытьобеспечено, чтобы все планы, предусмотренные договором, были документально оформлены,соответствовали условиям договора, были взаимно согласованы и выполнены должнымобразом.

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

6.3.2.3 При подготовке кпоставке программных продуктов должно быть обеспечено, чтобы данные продуктыполностью соответствовали требованиям, установленным в договоре, иудовлетворяли заказчика.

6.3.3 Обеспечение процесса

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

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

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

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

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

6.3.3.5 Должно быть обеспечено,чтобы характеристики программного продукта и процессов соответствовалиустановленным стандартам и процедурам.

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

6.3.4 Обеспечение системкачества

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

6.3.4.1 Должно быть обеспеченопроведение дополнительных работ по управлению качеством в соответствии сразделами ГОСТР ИСО 9001, указанными в договоре.

6.4Процесс верификации

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

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

Список работ. Данный процесссостоит из следующих работ:

1) подготовка процесса;

2) верификация.

6.4.1 Подготовка процесса

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

6.4.1.1 Должны бытьопределены необходимость наличия в проекте работ по верификации и степеньорганизационной независимости при проведении данных работ. Проектные требованиядолжны быть проанализированы на критичность. Критичность может быть оценена сточки зрения:

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

b) совершенства используемойтехнологии программирования и рисков, связанных с ее применением;

c) доступности фондов иресурсов.

6.4.1.2 Если проектпредусматривает работы по верификации, должен быть установлен процессверификации для проверки программного продукта.

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

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

6.4.1.5 Должен бытьразработан и документально оформлен план проведения верификации на основеустановленных задач верификации. План должен относиться к верифицируемым вжизненном цикле работам и программным продуктам; содержать требуемые задачиверификации для каждого объекта; определять соответствующие ресурсы,обязанности и график проведения работ. План должен предусматривать процедурыпередачи отчетов о верификации заказчику и другим заинтересованным сторонам.

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

6.4.2Верификация

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

6.4.2.1 Верификация договора

Договор должен бытьверифицирован по следующим критериям:

a) возможности поставщикаудовлетворить установленным требованиям;

b) непротиворечивоститребований и охвату ими потребностей пользователя;

c) наличия соответствующихпроцедур для внесения изменений в установленные требования и решения проблем;

d)наличия процедур и правил их применения по взаимодействию и кооперации междуучастниками договора, включая права собственности, гарантии, авторские права иконфиденциальность;

e) наличия соответствующих критериеви процедур, предусмотренных в соответствии с установленными требованиями.

Примечание - Данная работа может выполняться приоценке договора [см. 6.3.1.3.b)].

6.4.2.2 Верификация процесса

Процесс должен бытьверифицирован по следующим критериям:

a) соответствие исвоевременность установления проектных требований к планированию;

b) пригодность,реализуемость, выполнимость в соответствии с планом и условиями договоравыбранных для проекта процессов;

c) применимость стандартов,процедур и условий к процессам проектирования;

d)укомплектованность и обученность персонала в соответствии с условиями договора.

6.4.2.3 Верификациятребований

Требования должны бытьверифицированы по следующим критериям:

a) непротиворечивость,выполнимость и тестируемость требований к системе;

b) распределение требованийк системе между объектами технических и программных средств и ручных операций всоответствии с проектом;

c) непротиворечивость,выполнимость, тестируемость и точность отражения требований к системе втребованиях к программным средствам;

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

6.4.2.4 Верификация проекта

Проект должен бытьверифицирован по следующим критериям:

a) правильность проекта, егосоответствие установленным требованиям и учет этих требований в проекте;

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

c) возможность выборапроекта, исходя из установленных требований;

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

6.4.2.5 Верификацияпрограммы

Программа должна бытьверифицирована по следующим критериям:

a) учет в программе условийпроекта и установленных требований; ее тестируемость, правильность исоответствие установленным требованиям и стандартам программирования;

b) реализуемость впрограмме: соответствующей последовательности событий, соответствующихинтерфейсов, правильных данных и логики управления; распределения временных иматериальных ресурсов; обнаружения, локализации и восстановления ошибок, атакже ее завершенность;

c) возможность выборапрограммы, исходя из проекта или установленных требований;

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

6.4.2.6 Верификация сборки

Сборка должна бытьверифицирована по следующим критериям:

a) полнота и правильностьсборки программных компонентов и модулей каждого программного объекта всоответствующий программный объект;

b) полнота и правильностьсборки технических и программных объектов и ручных операций в систему;

c) выполнение задач сборки всоответствии с планом сборки.

6.4.2.7 Верификациядокументации

Документация должна бытьверифицирована по следующим критериям:

a) соответствие, полнота инепротиворечивость документации;

b) своевременностьподготовки документации;

c) соблюдение установленныхпроцедур управления конфигурацией документов.

6.5Процесс аттестации

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

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

Список работ. Данный процесссостоит из следующих работ:

1) подготовка процесса;

2) аттестация.

6.5.1 Подготовка процесса

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

6.5.1.1 Должны бытьопределены необходимость наличия в проекте работы по аттестации и степеньорганизационной независимости при проведении данных работ.

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

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

6.5.1.4 Должен бытьразработан и документально оформлен план проведения аттестации. План долженопределять (но не ограничиваться):

a) объекты, подлежащиеаттестации;

b) задачи, решаемые приаттестации;

c) ресурсы, обязанности играфик при проведении аттестации;

d)процедуры передачи отчетов об аттестации заказчику и другим сторонам.

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

6.5.2 Аттестация

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

6.5.2.1Подготовка выбранных требований к испытаниям (тестированию), контрольныхпримеров и технических условий испытаний к анализу результатов испытаний.

6.5.2.2Обеспечение того, чтобы требования к испытаниям (тестированию), контрольныепримеры и технические условия испытаний отражали конкретные требования кконкретным объектам аттестации.

6.5.2.3 Проведение испытанийс учетом 6.5.2.1и 6.5.2.2,включая:

a) испытания прикритических, граничных и особых значениях исходных данных;

b) испытание программногопродукта на способность изолировать и минимизировать эффект ошибок спостепенным понижением влияния сбоев и запросом помощи оператора прикритических, граничных и особых условиях;

c) испытание при участиирепрезентативно выбранных пользователей, могущих успешно решать свои задачи прииспользовании данного программного продукта.

6.5.2.4 Подтверждение того,что программный продукт удовлетворяет заявленным возможностям.

6.5.2.5 Испытаниепрограммного продукта в выбранных областях среды эксплуатации.

6.6Процесс совместного анализа

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

Список работ. Данный процесссостоит из следующих работ:

1) подготовка процесса;

2) анализы управленияпроектом;

3) технические анализы.

6.6.1 Подготовка процесса

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

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

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

6.6.1.3 Стороны должнысогласовать следующие вопросы проведения каждого анализа: план проведенияанализа; состав анализируемых программных продуктов (результатов работы) ипроблем; объем и процедуры проведения анализа; исходные и итоговые критерии припроведении анализа.

6.6.1.4 Проблемы, выявленныепри проведении анализа, должны быть документально оформлены и введены в процессрешения проблем (подраздел 6.8).

6.6.1.5 Результаты анализадолжны быть документально оформлены и разосланы заинтересованным сторонам.Анализирующая сторона должна довести до сведения анализируемой сторонысоответствующие результаты анализа (например, согласовано, не согласовано илисогласовано условно).

6.6.1.6 Стороны должнысогласовать итоговый результат анализа, любые принимаемые обязательства икритерии завершения анализа.

6.6.2 Анализы управленияпроектом

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

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

a) предложения поактивизации работ в соответствии с планом, основанные на оценке состояний работили программных продуктов;

b) предложения по проведениюобщего контроля проекта посредством соответствующего перераспределенияресурсов;

c) предложения по изменениюхода проекта или определению потребности в перепланировании проекта;

d)предложения по оценке и управлению критическими ситуациями, могущими угрожатьуспешному ходу проекта.

6.6.3 Технические анализы

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

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

a) они полностью реализованына данный момент;

b) они соответствуютпринятым стандартам и техническим требованиям;

c) изменения к ним выполненыдолжным образом и влияют только на те области, которые определены процессомуправления конфигурацией (подраздел 6.2);

d) ониполностью придерживаются установленных графиков работ;

e) они готовы к последующимработам;

f) их разработка,эксплуатация или сопровождение проводятся в соответствии с проектными планами,графиками, стандартами и руководствами.

6.7Процесс аудита

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

Список работ. Данный процесссостоит из следующих работ:

1) подготовка процесса;

2) аудиторская проверка.

6.7.1 Подготовка процесса

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

6.7.1.1 Аудиторские проверкидолжны проводиться в сроки, установленные проектным планом(ами).

6.7.1.2 Аудиторский персоналне должен нести какой-либо прямой ответственности за проверяемые программныепродукты и работы.

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

6.7.1.4 Стороны должнысогласовать следующие вопросы проведения каждой аудиторской проверки: планпроведения аудиторской проверки; состав проверяемых программных продуктов (ирезультатов работы); объем и процедуры проведения аудиторской проверки;исходные и итоговые критерии при проведении аудиторской проверки.

6.7.1.5 Проблемы, выявленныепри проведении аудиторской проверки, должны быть документально оформлены ивведены в процесс решения проблем (подраздел 6.8).

6.7.1.6 Результатыаудиторской проверки после ее завершения должны быть документально оформлены ипредставлены ревизуемой стороне. Ревизующая сторона должна довести до сведенияревизуемой стороны все проблемы, обнаруженные при проведении аудиторскойпроверки, и планируемые решения по соответствующим проблемам.

6.7.1.7 Стороны должнысогласовать итоговый результат аудиторской проверки, любые принимаемыеобязательства и критерии завершения аудиторской проверки.

6.7.2 Аудиторская проверка

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

6.7.2.1 Аудиторские проверкидолжны проводиться для обеспечения того, чтобы:

a) запрограммированныепрограммные продукты (такие, как программный объект) отражали проектнуюдокументацию;

b) подготовка приемки итребования к тестированию, установленные в документации, были пригодны дляприемки программных продуктов;

c) тестовые данныесоответствовали установленным техническим требованиям;

d)программные продукты были успешно протестированы и соответствовалиустановленным к ним требованиям;

e) отчеты об испытаниях(тестировании) были правильны и расхождения между фактическими и ожидаемымирезультатами были устранены;

f)документация пользователя соответствовала установленным стандартам;

g)работы были выполнены в соответствии с утвержденными требованиями, планами идоговором;

h)стоимости и графики проведения работ соответствовали утвержденным планам.

6.8Процесс решения проблем

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

Список работ. Данный процесссостоит из следующих работ:

1) подготовка процесса;

2) решение проблемы.

6.8.1 Подготовка процесса

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

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

a) процесс должен бытьциклически замкнутым, обеспечивающим в соответствии с условиями договора:своевременное документирование и ввод всех обнаруженных проблем в процессрешения проблем; организацию работ над ними; соответствующие уведомлениязаинтересованных сторон о данных проблемах; определение, анализ и возможноеустранение причин их возникновения; реализацию решения данных проблем и ихвнесение в соответствующие объекты; учет и документирование состояний проблем;сопровождение отчетов о проблемах;

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

c) в отчетах о проблемахдолжен быть приведен анализ причин их возникновения;

d)реализованные решения проблем и их введение в соответствующие объекты должныбыть оценены по следующим критериям: какие проблемы решены; какиенеблагоприятные причины их возникновения устранены; какие изменения правильновнесены в соответствующие программные продукты и работы; какие дополнительныепроблемы обнаружены.

6.8.2 Решение проблемы

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

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

7Организационные процессы жизненного цикла

В данном разделе определеныследующие организационные процессы жизненного цикла:

1) процесс управления;

2) процесс созданияинфраструктуры;

3) процессусовершенствования;

4) процесс обучения.

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

7.1Процесс управления

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

Список работ. Данный процесссостоит из следующих работ:

1) подготовка и определениеобласти управления;

2) планирование;

3) выполнение и контроль;

4) проверка и оценка;

5) завершение.

7.1.1 Подготовка иопределение области управления

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

7.1.1.1 Процесс управлениядолжен начинаться с установления требований к реализуемому процессу.

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

7.1.1.3 При необходимости ипо согласованию со всеми заинтересованными сторонами требования к процессумогут быть изменены с точки зрения удовлетворения критериев завершенияпроцесса.

7.1.2 Планирование

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

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

a) установление графиковсвоевременного решения задач;

b) оценка необходимыхтрудозатрат;

c) определение ресурсов,необходимых для выполнения задач;

d)распределение задач по исполнителям;

e) определение обязанностейисполнителей;

f)определение критических ситуаций, связанных с задачами или самим процессом;

g)установление используемых в процессе критериев управления качеством;

h)определение затрат, связанных с реализацией процесса;

i)обеспечение условий и определение инфраструктуры выполнения процесса.

7.1.3 Выполнение и контроль

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

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

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

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

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

7.1.4 Проверка и оценка

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

7.1.4.1 Администратор долженобеспечить оценку программных продуктов и планов на соответствие установленнымтребованиям.

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

7.1.5 Завершение

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

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

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

7.2Процесс создания инфраструктуры

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

Список работ. Данный процесссостоит из следующих работ:

1) подготовка процесса;

2) создание инфраструктуры;

3) сопровождениеинфраструктуры.

7.2.1 Подготовка процесса

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

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

7.2.1.2 Созданиеустановленной инфраструктуры должно быть спланировано и документальнооформлено.

7.2.2 Созданиеинфраструктуры

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

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

7.2.2.2 Инфраструктурадолжна быть создана к сроку, необходимому для реализации соответствующегопроцесса.

7.2.3 Сопровождениеинфраструктуры

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

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

7.3Процесс усовершенствования

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

1) создание процесса;

2) оценка процесса;

3) усовершенствованиепроцесса.

7.3.1 Создание процесса

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

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

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

7.3.2 Оценка процесса

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

7.3.2.1 Должна быть разработана,документально оформлена и применена процедура оценки процесса. Должнысохраняться и обновляться отчеты о выполненных оценках процесса.

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

7.3.3 Усовершенствованиепроцесса

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

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

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

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

7.4Процесс обучения

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

Список работ. Данный процесссостоит из следующих работ:

1) подготовка процесса;

2) разработка учебныхматериалов;

3) реализация планаобучения.

7.4.1 Подготовка процесса

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

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

7.4.2 Разработка учебныхматериалов

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

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

7.4.3 Реализация планаобучения

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

7.4.3.1 Должен бытьреализован план обучения для обеспечения обучения персонала. Отчеты овыполненном обучении персонала должны быть сохранены.

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