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