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

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

Внесен Техническим комитетом по стандартизации ТК 22 "Информационная технология".

2. Принят и введен в действие Постановлением Госстандарта России от 23 декабря 1999 г. N 675-ст.

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

4. Введен впервые.

5. Переиздание. Июль 2003 г.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

------------------------------------

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

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

В настоящем стандарте применяются термины с соответствующими определениями по ИСО/МЭК 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. Существуют как внешние, так и внутренние цели обеспечения качества:

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

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 servise): Выполнение работ, заданий или обязанностей, связанных с программным продуктом, таких как разработка, сопровождение или эксплуатация.

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.1.1. Процессы жизненного цикла

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

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

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

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. Заказчик должен рассмотреть варианты реализации заказа, начиная с анализа соответствующих критериев, включая рискованность и стоимость проекта и выгоды от каждого варианта. Анализируются следующие варианты:

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

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

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

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

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

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

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

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. Данные, использовавшиеся или связанные со снятым с эксплуатации программным продуктом, должны быть доступными для защиты и аудиторской проверки в соответствии с условиями договора.

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

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. Верификация процесса

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

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

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

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

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. Должно быть обеспечено, чтобы соответствующим образом подобранный и обученный персонал своевременно был готов к правильному выполнению запланированных работ и задач.

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

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

1) определение условий выполнения проекта;

2) запрос исходных данных;

3) выбор процессов, работ и задач;

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

А.1. Определение условий выполнения проекта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

------------------------------------

<*> С 1 января 2002 г. введен в действие ГОСТ Р ИСО/МЭК 12119-2000.

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

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

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

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

С.1. Процессы с ключевых точек зрения

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

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

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

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

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

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

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

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

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

С.2. Процессы, организации и взаимоотношения

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

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

Организация или сторона получает свое наименование от процесса, который она выполняет, например, она называется "заказчик", если она выполняет процесс заказа.

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

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

[1] ИСО/МЭК 12119-94 <*>. Информационная технология. Пакеты программ. Требования качества и тестирование

------------------------------------

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