64,07 
74,18 
ГОСТ Р ИСО/МЭК 12207-99 Информационная технология. Процессы жизненного цикла программных средств
ГОСТ Р ИСО/МЭК12207-99
ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
Информационнаятехнология
ПРОЦЕССЫ ЖИЗНЕННОГО ЦИКЛА
ПРОГРАММНЫХ СРЕДСТВ
ГОССТАНДАРТ РОССИИ
Москва
Предисловие
1 РАЗРАБОТАН Всероссийским научно-исследовательским институтомстандартизации (ВНИИстандарт) Госстандарта России
ВНЕСЕН Техническим комитетом по стандартизации ТК 22 «Информационнаятехнология»
2 ПРИНЯТ И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 23декабря 1999 г. № 675-ст
3 Настоящий стандарт содержит полный аутентичный текст международногостандарта ИСО/МЭК 12207-95 «Информационная технология. Процессы жизненногоцикла программных средств»
4 ВВЕДЕН ВПЕРВЫЕ
5ПЕРЕИЗДАНИЕ. Июль 2003 г.
СОДЕРЖАНИЕ
Введение
Программные средстваявляются неотъемлемыми частями информационных технологий и традиционных систем,таких как транспортные, военные, здравоохранения и финансовые. При этомподразумевается усиление роли стандартов, процедур, методов, средств(инструментария) и внешних условий для разработки и сопровождения программныхсредств (программного обеспечения). Подобная многоплановость подходов создаетзначительные трудности при управлении программными средствами и в технологияхпрограммирования, особенно при интеграции продуктов и услуг. Требуетсяопределенное упорядочение вопросов создания программных средств при переходе отподобной многоплановости к общей структуре, которая может быть использованапрофессионалами для «разговора на одном языке» при создании и управлениипрограммными средствами. Настоящий стандарт устанавливает такую общуюструктуру.
Данная структура охватываетжизненный цикл программных средств от концепции замыслов через определение иобъединение процессов для заказа и поставки программных продуктов и услуг.Кроме того, данная структура предназначена для контроля и модернизации данныхпроцессов.
Процессы, определенные внастоящем стандарте, образуют множество общего назначения. Конкретнаяорганизация, в зависимости от своих целей, может выбрать соответствующееподмножество процессов для выполнения своих конкретных задач. Поэтому настоящийстандарт следует адаптировать для конкретной организации, проекта илиприложения. Настоящий стандарт предназначен для использования как в случаеотдельно поставляемых программных средств, так и для программных средств,встраиваемых или интегрируемых в общую систему.
ГОСУДАРСТВЕННЫЙСТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
Информационная технология
ПРОЦЕССЫ ЖИЗНЕННОГО ЦИКЛА ПРОГРАММНЫХСРЕДСТВ
Information technology.
Software life cycle processes
Дата введения 2000-07-01
1 Область применения
1.1. Назначение
Настоящий стандартустанавливает, используя четко определенную терминологию, общую структурупроцессов жизненного цикла программных средств, на которую можноориентироваться в программной индустрии. Настоящий стандарт определяетпроцессы, работы и задачи, которые используются: при приобретении системы,содержащей программные средства, или отдельно поставляемого программногопродукта; при оказании программной услуги, а также при поставке, разработке,эксплуатации и сопровождении программных продуктов. Понятие программных средствтакже охватывает программный компонент программно-аппаратных средств.
Настоящий стандарт такжеопределяет процесс, который может быть использован при определении, контроле имодернизации процессов жизненного цикла программных средств.
1.2 Область распространения
Настоящий стандартприменяется при приобретении систем, программных продуктов и оказаниисоответствующих услуг; а также при поставке, разработке, эксплуатации исопровождении программных продуктов и программных компонентов программно-аппаратныхсредств как в самой организации, так и вне ее. Стандарт содержит также теаспекты описания системы, которые необходимы для обеспечения понимания сутипрограммных продуктов и услуг.
Примечание - Процессы, реализуемые вжизненном цикле программных средств, должны быть совместимы с процессами,реализуемыми в жизненном цикле системы.
Стандарт также применяетсяпри двусторонних отношениях сторон и может в равной степени применяться, еслиобе стороны принадлежат к одной и той же организации. Диапазон применения можетпростираться от неформального соглашения о сотрудничестве до официальнозаключаемого контракта (договора). Стандарт может использоваться одной изсторон для самоконтроля.
Стандарт не распространяетсяна готовые программные продукты, если они не входят в поставляемый продукт.
Стандарт предназначен для:заказчиков систем, программных продуктов и услуг; поставщиков; разработчиков;операторов; персонала сопровождения; администраторов проектов; администраторов,отвечающих за качество, и пользователей программных продуктов.
1.3 Адаптация настоящего стандарта
Настоящий стандартопределяет набор процессов, работ и задач, предназначенных для адаптации кусловиям конкретных программных проектов. Процесс адаптации заключается в исключениинеприменяемых в условиях конкретного проекта процессов, работ и задач.
Примечание - В договоре могут бытьдополнительно предусмотрены уникальные или специальные процессы, работы изадачи.
1.4 Соответствие
Соответствие настоящемустандарту определяется как выполнение всех процессов, работ и задач, выбранныхиз настоящего стандарта в процессе адаптации (приложение А),для конкретного программного проекта. Выполнение процесса или работы считаетсязавершенным, когда выполнены все требуемые для них задачи в соответствии спредварительно установленными в договоре критериями и требованиями.
Любая организация (например,национальная, промышленная ассоциация, компания), применяющая настоящийстандарт в качестве условия обеспечения торговых сделок, обязана определить иопубликовать минимальный набор требуемых процессов, работ и задач, которыйобеспечивает проверку соответствия поставщика настоящему стандарту.
1.5 Ограничения
Настоящий стандарт описываетархитектуру процессов жизненного цикла программных средств, но не определяетдетали реализации или выполнения работ и задач, входящих в данные процессы.
Стандарт не предназначен дляопределения наименований, форматов или подробного содержания выпускаемой документации.Стандарт может требовать разработки документов одного класса или типа, напримерразличных планов, но не предусматривает, чтобы такие документы разрабатывалисьили комплектовались раздельно или совместно. Решение этих вопросов оставлено наусмотрение пользователей настоящего стандарта.
Стандарт не предопределяетконкретной модели жизненного цикла или метода разработки программного средства.Пользователи, применяющие настоящий стандарт, должны сами выбирать модельжизненного цикла применительно к своему программному проекту и распределятьпроцессы, работы и задачи, выбранные из настоящего стандарта, на данной модели;выбирать и применять методы разработки программных средств и выполнять работы изадачи, соответствующие конкретному программному проекту.
Стандарт не имеетпротиворечий с существующими в организациях стратегиями, стандартами илипроцедурами. Однако любые возникающие конфликтные ситуации должны бытьразрешены, а любые противоречащие условия и ситуации должны быть упомянуты впримечаниях как исключения при применении настоящего стандарта.
В тексте настоящегостандарта слово «должны» используется для выражения соглашения между двумя илиболее сторонами; слово «должна» - для выражения объявления цели или намеренияодной из сторон; слово «следует» - для выражения рекомендации из имеющихсявозможных вариантов; слово «может» - для обозначения образа действий,допускаемого в рамках ограничений настоящего стандарта.
В тексте настоящегостандарта приведен ряд перечней задач, однако ни один из перечней нельзясчитать исчерпывающим, и они приведены в качестве примеров.
2 Нормативные ссылки
В настоящем стандартеиспользованы ссылки на следующие стандарты:
ГОСТР ИСО 9001-96* Системы качества. Модель обеспечения качества припроектировании, разработке, производстве, монтаже и обслуживании
*Действует до 15 декабря 2003 г.
ГОСТ Р ИСО 9001-2001Системы менеджмента качества. Требования
ГОСТР ИСО/МЭК 9126-93 Информационная технология. Оценка программной продукции.Характеристики качества и руководства по их применению
ИСО/МЭК 2382-1-93**Информационная технология. Словарь. Часть 1. Основополагающие термины
ИСО/МЭК 2382-20-90**Информационная технология. Словарь. Часть 20. Разработка систем
ИСО 8402-94**Управление качеством и обеспечение качества. Словарь
** Оригиналы международных стандартовИСО/МЭК - во ВНИИКИ Госстандарта России.
3 Определения
В настоящем стандартеприменяются термины с соответствующими определениями по ИСО/МЭК 2382-1, ИСО/МЭК2382-20 и ИСО 8402, атакже приведенные ниже:
Примечание - Продукт может рассматриватьсякак часть системы или как приложение.
3.1 заказчик (acquirer):Организация, которая приобретает или получает систему, программный продукт илипрограммную услугу от поставщика.
Примечание - Заказчиком может быть: оптовыйили розничный покупатель, клиент, владелец, пользователь.
3.2 заказ (acquisition):Процесс приобретения системы, программного продукта или программной услуги.
3.3 соглашение (agreement):Определение границ и условий, при которых будут осуществляться рабочиевзаимоотношения.
3.4 аудит (audit):Проверка, выполняемая компетентным органом (лицом) с целью обеспечениянезависимой оценки степени соответствия программных продуктов или процессовустановленным требованиям.
3.5 базовая линия (baseline):Официально принятая версия элемента конфигурации, независимая от среды,формально обозначенная и зафиксированная в конкретный момент времени жизненногоцикла элемента конфигурации.
3.6 элемент конфигурации (configuration item): Объект внутри конфигурации, который удовлетворяетфункции конечного использования и может быть однозначно определен в даннойэталонной точке.
3.7 договор (contract):Обязательное соглашение между двумя сторонами, подкрепленное законодательно,или аналогичное соглашение внутри данной организации: по предоставлениюпрограммной услуги; на поставку, разработку, производство, эксплуатацию илисопровождение программного продукта.
3.8 разработчик (developer):Организация, выполняющая работы по разработке (включая анализ требований,проектирование, приемочные испытания) в процессе жизненного цикла программныхсредств.
3.9 оценка (evaluation):Систематическое определение степени соответствия объекта установленнымкритериям.
3.10 программно-аппаратноесредство (firmware): Сочетание технических устройств и машинных командили используемых вычислительной машиной данных, постоянно хранящихся натехническом устройстве в виде постоянного программного средства. Данноепрограммное средство не может изменяться только средствами программирования.
3.11 модель жизненногоцикла (life cycle model):Структура, состоящая из процессов, работ и задач, включающих в себя разработку,эксплуатацию и сопровождение программного продукта, охватывающая жизнь системыот установления требований к ней до прекращения ее использования.
3.12 персоналсопровождения (maintainer): Организация, которая выполняет работы посопровождению.
3.13 надзор (monitoring):Проверка заказчиком или третьей стороной состояния работ, выполняемыхпоставщиком, и их результатов.
3.14 непоставляемоеизделие (non-deliverable item):Техническое или программное средство, которое не поставляется по условиямдоговора, но может быть применено при создании программного продукта.
3.15 готовый продукт (off-the-shelf product): Ранее разработанный и доступный для приобретенияпродукт, пригодный для использования в поставляемом или модифицированном виде.
3.16 оператор (operator):Организация, эксплуатирующая систему.
3.17 процесс (process):Набор взаимосвязанных работ, которые преобразуют исходные данные в выходныерезультаты.
Примечание - Термин «работы» подразумеваетиспользование ресурсов (См. 1.2 ИСО8402).
3.18 квалификация (qualification): Процесс демонстрации возможности объекта выполнять установленныетребования (См. 2.13 ИСО 8402).
3.19 квалификационноетребование (qualification requirement): Набор критериев илиусловий, которые должны быть удовлетворены для того, чтобы квалифицироватьпрограммный продукт на соответствие установленным требованиям и готовность киспользованию в заданных условиях эксплуатации.
3.20 квалификационноеиспытание (qualification testing): Испытание (тестирование),проводимое разработчиком, при необходимости санкционированное заказчиком, длядемонстрации того, что программный продукт удовлетворяет установленнымтребованиям и готов к использованию в заданных условиях эксплуатации.
3.21 обеспечение качества(quality assurance): Все запланированные исистематически выполняемые в рамках системы качества работы; при необходимостиобъективные доказательства, обеспечивающие уверенность в том, что объект будетполностью соответствовать установленным требованиям качества.
Примечания
1 Существуюткак внешние, так и внутренние цели обеспечения качества:
a) внутреннееобеспечение качества - внутри организации обеспечение качества создаетуверенность у руководства;
b) внешнееобеспечение качества - в договорных или других ситуациях обеспечение качествасоздает уверенность у потребителя или других лиц.
2 Некоторыевиды работ по управлению качеством и обеспечению качества взаимосвязаны.
3 Еслитребования к качеству не полностью отражают потребности пользователя, тообеспечение качества может не создать достаточной уверенности. (См. 3.5 ИСО8402).
3.22 выпуск (release): Конкретная версияэлемента конфигурации, которая доступна для реализации конкретной цели(например, тестируемый выпуск).
3.23 заявка на подряд (request for proposal [tender]): Документ, используемыйзаказчиком в качестве средства для объявления о своих намерениях выступить вкачестве потенциального покупателя конкретной системы, программного продуктаили программной услуги.
3.24 снятие сэксплуатации (retirement): Прекращение активной поддержки действующейсистемы со стороны эксплуатирующей или сопровождающей организации, частичнаяили полная замена ее новой системой или ввод в действие модернизированнойсистемы.
3.25 защита (security):Сохранение информации и данных так, чтобы недопущенные к ним лица или системыне могли их читать или изменять, а допущенные лица или системы неограничивались в доступе к ним.
3.26 программный продукт (software product): Набор машинных программ, процедур и, возможно,связанных с ними документации и данных.
3.27 программная услуга (software service): Выполнение работ, заданий или обязанностей,связанных с программным продуктом, таких как разработка, сопровождение илиэксплуатация.
3.28 программный модуль (software unit): Отдельно компилируемая часть программного кода(программы).
3.29 техническое задание (statement of work): Документ, используемыйзаказчиком в качестве средства для описания и определения задач, выполняемыхпри реализации договора.
3.30 поставщик (supplier):Организация, которая заключает договор с заказчиком на поставку системы,программного продукта или программной услуги на условиях, оговоренных вдоговоре.
Примечания
1 Синонимамитермина «поставщик» являются термины «подрядчик», «производитель», «оптовик»или «продавец».
2 Заказчикможет определить в качестве поставщика подразделение собственной организации.
3.31 система (system): Комплекс, состоящий изпроцессов, технических и программных средств, устройств и персонала, обладающийвозможностью удовлетворять установленным потребностям или целям.
3.32 тестовое покрытие (test coverage): Степень, до которой с помощью контрольныхпримеров проверяют требования к системе или программному продукту.
3.33 тестируемость (testability):Степень, до которой могут быть запланированы объективность и реализуемостьтестирования, проверяющего соответствие требованию.
3.34 пользователь (user):Лицо или организация, которое использует действующую систему для выполненияконкретной функции.
Примечание - Пользователь может такжевыполнять и другие роли, например, заказчика, разработчика или сопровождающегоперсонала.
3.35 аттестация (validation):Подтверждение экспертизой и представлением объективных доказательств того, чтоконкретные требования к конкретным объектам полностью реализованы.
Примечания
1 В процессепроектирования и разработки аттестация связана с экспертизой продукта в целяхопределения его соответствия потребностям пользователя.
2 Аттестациюобычно проводят для конечного продукта в установленных условиях эксплуатации.При необходимости аттестация может проводиться на более ранних стадиях.
3 Термин«аттестован» используется для обозначения соответствующих состояний объекта.
4 Может бытьпроведен ряд аттестаций, если они преследуют различные цели. (См. 2.18 ИСО8402).
3.36 верификация (verification): Подтверждение экспертизойи представлением объективных доказательств того, что конкретные требования полностьюреализованы.
Примечания
1 В процессепроектирования и разработки верификация связана с экспертизой результатовданной работы в целях определения их соответствия установленным требованиям.
2 Термин«верифицирован» используется для обозначения соответствующих состоянийпроверенного объекта. (См. 2.17 ИСО 8402).
3.37 версия (version): Определенный экземпляробъекта.
Примечание - В результате модификацииверсии программного продукта появляется новая версия, подвергающаяся управлениюконфигурацией.
4 Прикладное применение настоящего стандарта
В настоящем разделеопределяются процессы жизненного цикла программных средств, которые могут бытьреализованы при заказе, поставке, разработке, эксплуатации и сопровождениипрограммных продуктов. Целью настоящего раздела является создание«путеводителя» для пользователей настоящего стандарта, который поможеториентироваться в стандарте и осмысленно применять его.
4.1 Построение стандарта
4.1.1Процессы жизненного цикла
В настоящем стандартеработы, которые могут выполняться в жизненном цикле программных средств,распределены по пяти основным, восьми вспомогательным и четырем организационнымпроцессам. Каждый процесс жизненного цикла разделен на набор работ; каждаяработа разделена на набор задач. Нумерация подразделов (пунктов) означает: а.b -процесс; а.b.с - работа; a.b.c.d - задача. Все процессыжизненного цикла описаны ниже и изображены на рисунке 1.
Рисунок 1 - Структура стандарта
4.1.1.1 Основные процессыжизненного цикла
Основные процессы жизненногоцикла (раздел 5)состоят из пяти процессов, которые реализуются под управлением основных сторон,вовлеченных в жизненный цикл программных средств. Под основной сторонойпонимают одну из тех организаций, которые инициируют или выполняют разработку,эксплуатацию или сопровождение программных продуктов. Основными сторонами являютсязаказчик, поставщик, разработчик, оператор и персонал сопровождения программныхпродуктов. Основными процессами являются:
1) Процесс заказа (подраздел5.1).Определяет работы заказчика, то есть организации, которая приобретает систему,программный продукт или программную услугу.
2) Процесс поставки(подраздел 5.2).Определяет работы поставщика, то есть организации, которая поставляет систему, программныйпродукт или программную услугу заказчику.
3) Процесс разработки(подраздел 5.3).Определяет работы разработчика, то есть организации, которая проектирует иразрабатывает программный продукт.
4) Процесс эксплуатации(подраздел 5.4).Определяет работы оператора, то есть организации, которая обеспечиваетэксплуатационное обслуживание вычислительной системы в заданных условиях винтересах пользователей.
5) Процесс сопровождения(подраздел 5.5).Определяет работы персонала сопровождения, то есть организации, котораяпредоставляет услуги по сопровождению программного продукта, состоящие вконтролируемом изменении программного продукта с целью сохранения его исходногосостояния и функциональных возможностей. Данный процесс охватывает перенос иснятие с эксплуатации программного продукта.
4.1.1.2 Вспомогательныепроцессы жизненного цикла
Вспомогательные процессыжизненного цикла (раздел 6) состоят из восьми процессов. Вспомогательныйпроцесс является целенаправленной составной частью другого процесса,обеспечивающей успешную реализацию и качество выполнения программного проекта.Вспомогательный процесс, при необходимости, инициируется и используется другимпроцессом. Вспомогательными процессами являются:
1) Процесс документирования(подраздел 6.1).Определяет работы по описанию информации, выдаваемой в процессе жизненногоцикла.
2) Процесс управленияконфигурацией (подраздел 6.2). Определяет работы по управлениюконфигурацией.
3) Процесс обеспечениякачества (подраздел 6.3). Определяет работы по объективномуобеспечению того, чтобы программные продукты и процессы соответствовалитребованиям, установленным для них, и реализовывались в рамках утвержденныхпланов. Совместные анализы, аудиторские проверки, верификация и аттестациямогут использоваться в качестве методов обеспечения качества.
4) Процесс верификации(подраздел 6.4).Определяет работы (заказчика, поставщика или независимой стороны) поверификации программных продуктов по мере реализации программного проекта.
5) Процесс аттестации(подраздел 6.5).Определяет работы (заказчика, поставщика или независимой стороны) по аттестациипрограммных продуктов программного проекта.
6) Процесс совместногоанализа (подраздел 6.6). Определяет работы по оценке состояния ирезультатов какой-либо работы. Данный процесс может использоваться двумя любымисторонами, когда одна из сторон (проверяющая) проверяет другую сторону(проверяемую) на совместном совещании.
7) Процесс аудита (подраздел6.7).Определяет работы по определению соответствия требованиям, планам и договору.Данный процесс может использоваться двумя сторонами, когда одна из сторон(проверяющая) контролирует программные продукты или работы другой стороны(проверяемой).
8) Процесс решения проблемы(подраздел 6.8).Определяет процесс анализа и устранения проблем (включая несоответствия),независимо от их характера и источника, которые были обнаружены во времяосуществления разработки, эксплуатации, сопровождения или других процессов.
4.1.1.3 Организационныепроцессы жизненного цикла
Организационные процессыжизненного цикла (раздел 7) состоят из четырех процессов. Они применяются в какой-либоорганизации для создания и реализации основной структуры, охватывающейвзаимосвязанные процессы жизненного цикла и соответствующий персонал, а такжедля постоянногосовершенствования данной структуры и процессов. Эти процессы, как правило,являются типовыми, независимо от области реализации конкретных проектов идоговоров; однако уроки, извлеченные из таких проектов и договоров,способствуют совершенствованию организационных вопросов. Организационнымипроцессами являются:
1) Процесс управления (подраздел7.1).Определяет основные работы по управлению, включая управление проектом, приреализации процессов жизненного цикла.
2) Процесс созданияинфраструктуры (подраздел 7.2). Определяет основные работы по созданиюосновной структуры процесса жизненного цикла.
3) Процессусовершенствования (подраздел 7.3). Определяет основные работы, которыеорганизация (заказчика, поставщика, разработчика, оператора, персоналасопровождения или администратора другого процесса) выполняет при создании,оценке, контроле и усовершенствовании выбранных процессов жизненного цикла.
4) Процесс обучения(подраздел 7.4).Определяет работы по соответствующему обучению персонала.
4.1.2 Процесс адаптации
Основные работы, которыедолжны быть выполнены при адаптации настоящего стандарта к условиям конкретногопрограммного проекта, определены в приложении А. Краткое руководство поадаптации требований настоящего стандарта приведено в приложении В; оносодержит перечни основных показателей, по которым могут быть приняты решения поадаптации.
4.1.3 Взаимосвязи междупроцессами и организациями
Настоящий стандартопределяет различные процессы, которые реализуются в жизненном циклепрограммных средств различными организациями, в зависимости от их потребностейи целей. Для лучшего понимания материала настоящего стандарта в приложении Спредставлены взаимосвязи между процессами жизненного цикла и соответствующимисторонами, вовлеченными в жизненный цикл.
5Основные процессы жизненного цикла
В настоящем разделеопределены следующие основные процессы жизненного цикла:
1) процесс заказа;
2) процесс поставки;
3) процесс разработки;
4) процесс эксплуатации;
5) процесс сопровождения.
Ответственность за выполнениеработ и задач в основном процессе несет организация, создающая и реализующаяданный процесс. Данная организация гарантирует реальность существования ифункциональные особенности конкретного процесса.
5.1Процесс заказа
Процесс заказа состоит из работи задач, выполняемых заказчиком. Процесс начинается с определения потребностейзаказчика в системе, программном продукте или программной услуге. Далее следуютподготовка и выпуск заявки на подряд, выбор поставщика и управление процессомзаказа вплоть до завершения приемки системы, программного продукта илипрограммной услуги.
Конкретная организация,имеющая соответствующую потребность, может быть названа собственником.Собственник может заключить договор на выполнение части или всех работ позаказу с посредником, который будет поочередно проводить данные работы всоответствии с процессом заказа. В данном подразделе под заказчиком понимаетсясобственник или посредник.
Заказчик управляет процессомзаказа на проектном уровне в соответствии с процессом управления (подраздел 7.1),который конкретизируется в данном процессе; определяет инфраструктуру дляданного процесса в соответствии с процессом создания инфраструктуры (подраздел 7.2);адаптирует данный процесс к условиям проекта в соответствии с процессомадаптации (приложение А) и управляет процессом заказа наорганизационном уровне в соответствии с процессами усовершенствования(подраздел 7.3)и обучения (подраздел 7.4).
Список работ. Данный процесссостоит из следующих работ:
1) подготовка;
2) подготовка заявки наподряд;
3) подготовка икорректировка договора;
4) надзор за поставщиком;
5) приемка и закрытиедоговора.
5.1.1 Подготовка
Данная работа состоит изследующих задач:
5.1.1.1 Заказчик начинает процессзаказа, описывая концепцию или потребность в заказе, разработке илимодернизации системы, программного продукта или программной услуги.
5.1.1.3 Если заказчикпоручает поставщику выполнение анализа требований к системе, то заказчик долженсогласовать требования, сформулированные в результате анализа.
5.1.1.5 При решении задач,определенных в 5.1.1.2 и 5.1.1.4, должениспользоваться процесс разработки (подраздел 5.3).
a) покупка готовогопрограммного продукта, удовлетворяющего определенным требованиям;
b) разработка программногопродукта или обеспечение программной услуги собственными силами;
c) разработка программногопродукта или получение программной услуги на договорной основе;
d) комбинации поперечислениям а), b), с);
e) модернизациясуществующего программного продукта или услуги.
5.1.1.7 При приобретенииготового программного продукта заказчик должен получить гарантии того, чтоудовлетворены следующие условия:
a) программный продуктсоответствует установленным требованиям;
b) имеется в наличиисоответствующая документация;
c) соблюдены правасобственности, использования, лицензирования и гарантии;
d) предусмотрена последующаяподдержка программного продукта.
5.1.1.8 Заказчик долженподготовить, документально оформить и выполнить план заказа. План долженсодержать:
a) требования к системе;
b) планируемую загрузкусистемы;
c) тип реализуемогодоговора;
d) обязанности организаций,участвующих в договоре;
e) обеспечение подходов креализации договора;
f) анализ возможныхрискованных ситуаций, а также методы управления такими ситуациями.
5.1.1.9 Заказчик долженопределить и документально оформить принятые правила и условия (критерии)реализации договора.
5.1.2 Подготовка заявки наподряд
Данная работа состоит изследующих задач:
5.1.2.1 Заказчик должендокументально оформить требования к заказу (например, в виде заявки на подряд),состав которых зависит от вариантов реализации заказа, выбранных в соответствиис 5.1.1.6.Соответствующая документация по заказу должна содержать:
a) требования к системе;
b) описание областиприменения системы;
c) указания для участниковторгов;
d) список программныхпродуктов;
e) сроки и условияреализации заказа;
f) правила контроля надсубподрядчиками;
g) технические ограничения(например, по условиям эксплуатации).
5.1.2.2 Заказчик долженопределить, какие из процессов, работ и задач, описанных в настоящем стандарте,применимы к условиям проекта, и соответствующим образом их адаптировать. Впервую очередь заказчик должен определить применяемые вспомогательные процессы(раздел 6)и организации, реализующие данные процессы, включая обязанности этихорганизаций (если это не организация поставщика) так, чтобы потенциальныепоставщики могли в своих предложениях определить подход к каждому из выбранныхвспомогательных процессов. Заказчик должен определить содержание тех задач,которые предполагается сформулировать в договоре.
5.1.2.3 В документации позаказу должны быть также определены контрольные пункты договора, при выполнениикоторых анализируется и проверяется деятельность поставщика (см. подразделы 6.6 и6.7).
5.1.2.4 Требования к заказудолжны быть представлены организации, выбранной для выполнения работ в процессезаказа.
5.1.3 Подготовка икорректировка договора
Данная работа состоит изследующих задач:
5.1.3.1 Заказчик долженопределить процедуру для выбора поставщика, включая критерии оценки поступающихпредложений по реализации заказа и их соответствие установленным требованиям.
5.1.3.2 Заказчик долженвыбрать поставщика, исходя из оценки предложений, поступивших от потенциальныхпоставщиков, их возможностей и других рассматриваемых факторов.
5.1.3.3 Заказчик может дозаключения договора привлекать другие стороны, включая потенциальныхпоставщиков, для адаптации настоящего стандарта к условиям проекта. Однакоокончательное решение по адаптации должен принимать заказчик. Заказчик долженвключить в текст договора или сослаться в нем на адаптированный настоящийстандарт.
5.1.3.4 Заказчик долженподготовить и обсудить условия договора с поставщиком, который согласился стребованиями к заказу (включая стоимость и календарный план) на поставкупрограммного продукта или услуги. В договоре должны быть оговорены правасобственности, использования, лицензирования и гарантии, связанные с используемымив заказе готовыми программными продуктами.
5.1.3.5 В ходе реализациидоговора заказчик должен контролировать изменения, вносимые в договор, обсуждаяих с поставщиком. Изменения, вносимые в договор, должны быть изучены с точкизрения их влияния на договорные планы и цены, эффективность и качество.
Примечание - Заказчик определяет,используется ли при применении настоящего стандарта термин «договор» или«соглашение».
5.1.4 Надзор за поставщиком
Данная работа состоит изследующих задач:
5.1.4.1 Заказчик долженосуществлять надзор за работами поставщика в соответствии с процессамисовместного анализа (подраздел 6.6) и аудита (подраздел 6.7). При необходимостизаказчик должен дополнять текущий надзор процессами верификации (подраздел 6.4)и аттестации (подраздел 6.5).
5.1.4.2 Заказчик долженвзаимодействовать с поставщиком по вопросам своевременного взаимообмена всейнеобходимой информацией и решения всех возникающих проблем.
5.1.5 Приемка и закрытиедоговора
Данная работа состоит изследующих задач:
5.1.5.1 Заказчик должен подготовитьсяк приемке на основе установленных правил и критерием проведения приемки. Приэтом должны быть подготовлены контрольные примеры, контрольные данные,процедуры тестирования и условий проведения испытаний. Заказчик долженопределить степень участия поставщика при проведении приемки.
5.1.5.2 Заказчик долженпроверить готовность поставщика к проведению приемки и провести приемочныеиспытания поставляемого программного продукта или услуги, а затем принять их отпоставщика при выполнении всех условий приемки. Процедура приемки должнасоответствовать условиям 5.1.1.9.
5.1.5.3 После приемкизаказчик должен принять на себя ответственность за управление конфигурациейпоставленного программного продукта (см. подраздел 6.2).
Примечание - Заказчик может самостоятельноввести в действие программный продукт или выполнить программную услугу всоответствии с инструкциями, предоставленными поставщиком.
5.2Процесс поставки
Процесс поставки состоит изработ и задач, выполняемых поставщиком. Процесс может быть начат с решения оподготовке предложения в ответ на заявку на подряд, присланную заказчиком, илис подписания договора и вступления с заказчиком в договорные отношения попоставке системы, программного продукта или программной услуги. Процесспродолжается определением процедур и ресурсов, необходимых для управления иобеспечения проекта, включая разработку проектных планов и их выполнение посредствомпоставки системы, программного продукта или программной услуги заказчику.
Поставщик управляетпроцессом поставки на проектном уровне в соответствии с процессом управления(подраздел 7.1),который конкретизируется в данном процессе; определяет инфраструктуру для данногопроцесса в соответствии с процессом создания инфраструктуры (подраздел 7.2);адаптирует данный процесс к условиям проекта в соответствии с процессомадаптации (приложение А) и управляет процессом поставки наорганизационном уровне в соответствии с процессами усовершенствования(подраздел 7.3)и обучения (подраздел 7.4).
Список работ. Данный процесссостоит из следующих работ:
1) подготовка;
2) подготовка ответа;
3) подготовка договора;
4) планирование;
5) выполнение и контроль;
6) проверка и оценка;
7) поставка и закрытиедоговора.
5.2.1 Подготовка
Данная работа состоит изследующих задач:
5.2.1.1 Поставщик проводитанализ требований, установленных в заявке на подряд, принимая во вниманиеорганизационные вопросы и другие установленные правила.
5.2.1.2 Поставщик долженпринять решение об участии в конкурсе на подряд или о подписании договора.
5.2.2 Подготовка ответа
Данная работа состоит изследующей задачи:
5.2.2.1 Поставщик долженсформулировать и подготовить предложение в ответ на заявку о подряде, включаясвои рекомендации по адаптации настоящего стандарта.
5.2.3 Подготовка договора
Данная работа состоит изследующих задач:
5.2.3.1 Поставщик долженпровести переговоры и вступить в договорные отношения с организацией заказчикас целью обеспечения поставки программного продукта или услуги.
5.2.3.2 Поставщик можетпредложить внести изменения в текст договора по согласованию с заказчиком.
Данная работа состоит изследующих задач:
5.2.4.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) документально оформить ирешить возникающие проблемы и устранять несоответствия, об