Реферат: Международный iso/iec стандарт 12207

МЕЖДУНАРОДНЫЙ ISO/IEC

СТАНДАРТ 12207

Первое издание

1995-08-01





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

Процессы жизненного цикла программного обеспечения
ПРЕДИСЛОВИЕ

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

В области информационной технологии ISO и IEC образовали объединенный технический комитет ISO /IEC JTC 1. Проекты международных стандартов, принятые объединенным техническим комитетом, рассылаются национальным органам с целью их принятия. Публикация в качестве международного стандарта требует подтверждения от не менее чем 75% национальных органов, принимавших участие в принятии решения.

Международный стандарт ISO/IEC 12207 был подготовлен объединенным техническим комитетом ISO/IEC JTC1,"Информационные технологии, подкомитет SC7, проектирование программного обеспечения".

Дополнение А образует неотъемлемую часть международного стандарта. Дополнение В и С представлены только для информации.
ВВЕДЕНИЕ

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

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

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

^ 1Область действия. 1.1Назначение

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

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

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

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

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

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

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

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

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

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

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

В описании данного Международного Стандарта термин "должен" (shell) используется для того, чтобы выразить соглашение между двумя и более сторонами, термин "будет" (will) - чтобы выразить объявление цели или намерения одной стороны, термин "следует" (should) - чтобы выразить рекомендацию в сфере других возможностей, и термин "может" (may) - чтобы обозначить образ действий, допустимый с учетом ограничений данного Международного Стандарта.

В рамках данного Международного Стандарта существует некоторое количество списков задач; ни один из них нельзя рассматривать как исчерпывающий - они введены как примеры.
^ 2Нормативные ссылки
Следующие стандарты содержат положения, которые, в соответствии со ссылками в этом тексте, определяют положения данного Международного Стандарта. Приведенные здесь издания были действительны во время публикации этой статьи. Все стандарты являются субъектами пересмотра, и стороны-участники соглашений, основанных на данном Международном Стандарте, должны способствовать достижению возможности применения наиболее свежих изданий нижеприведенных стандартов. Члены IEC и ISO осуществляют поддержку реестров текущих версий Международных Стандартов.


ISO/AFNOR: 1989, Словарь компьютерной науки.

ISO/IEC 2382-1: 1993, Информационная технология - Словарь - Часть 1: Фундаментальные термины.

ISO/IEC 2382-20: 1990, Информационная технология - Словарь - Часть 20: Разработка системы.

ISO 8402: 1994, Управление качеством и гарантия качества - Словарь.

ISO 9001:1994, Системы качества - Модель обеспечения качества при проектировании, разработке, производстве, установке и обслуживании.

ISO/IEC 9126: 1991 Информационные технологии - Оценка программного продукта -Характеристика качества и порядок их применения.

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

В данном МС наряду с определениями, представленными в ISO 8402, ISO/IEC 2382-1 и ISO/IEC 2382-20, используются следующие определения.

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

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

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

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

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

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

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

3.6. Элемент конфигурации: объект внутри конфигурации, который удовлетворяет функции конечного пользователя и может быть однозначно идентифицирован в данной указанной точке.

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

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

3.9. Оценка систематическое определение, в какой степени объект отвечает установленным критериям.

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

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

3.12. Персонал сопровождения: организация, которая осуществляет сопровождение программного продукта.

3.13.Текущий контроль: анализ деятельности поставщика и его результатов заказчиком или третьим лицом.

3.14. Непоставляемый элемент: аппаратное средство или программный продукт который не требуется поставлять в соответствии с контрактом, но может быть использовано при разработке программного продукта.

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

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

3.17. Процесс: набор взаимосвязанных действий, который трансформирует вводы (информ. на входе) в выводы.

Примечание - термин "действия" охватывает использование ресурсов (см. ICO8402:1994,1.2.)

3.18. Квалификация: Демонстрирование, способен ли объект выполнять определенные требования (см. ISO8402:1994, 2.13.)

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

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

3.21. Гарантия качества: Все запланированные и систематические действия, осуществляемые внутри качественной системы и демонстрирующиеся как необходимые для обеспечения адекватной уверенности, что объект удовлетворяет требованиям качества.

Примечания:

1. Для гарантии качества существуют как внутренние, так и внешние цели:

а) Внутренняя гарантия качества: внутри организации гарантия качества (обеспечивает) дает уверенность в управлении;

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

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

3. До тех пор, пока требования о качестве полностью не отразят нужды пользователя, гарантия качества не имеет права обеспечить адекватное доверие (уверенность) (ISO 8402:1994,3.5)

3.22. Выпуск (версия): специфическая (детальная, подробная) версия единицы конфигурации, которая сделана доступной для выполнения специфической цели (например - версия теста).

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

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

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

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

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

3.28. Модуль программного обеспечения: Отдельно комплектуемый фрагмент кода.

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

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

Примечания:

1. Термин "поставщик" является синонимом с терминами подрядчик, производитель, продавец.

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

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

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

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

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

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

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

Примечания:

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

2.Утверждение (аттестация) обычно выполняется на конечном (готовом) продукте под действием определенных операционных режимов (условий). Это может быть необходимо на более ранних стадиях.

3. "Утвержденный (аттестованный)" используется, чтобы обозначить соответствующее состояние.

4. Многократные утверждения (аттестации) могут осуществляться, если есть различные цели (замыслы) использования (ISO 8402:1994,2.18)

3.36. Проверка: Подтверждение исследованием и предоставлением объективных данных, что специфицированные требования удовлетворены.

Примечания:

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

2. "Проверенный" используется для обозначения соответствующего состояния (ISO8402:1994, 2.17)

3.37. Версия: Идентифицированный пример (изделия) единицы.

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

Этот раздел представляет процессы жизненного цикла программного обеспечения, которые могут быть использованы при приобретении, поставке, разработке, эксплуатации и сопровождения программных изделий. Целью настоящего раздела является предоставление пользователю возможности самостоятельно использовать данный стандарт.
^ 4.1Принцип построения Международного стандарта 4.1.1Процессы жизненного цикла
Этот международный стандарт определяет действия, которые могут быть выполнены на протяжении жизненного цикла программного обеспечения. Выделяют 5 основных процессов, 8 вспомогательных процессов и 4 организационных процессах.

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

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

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

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

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

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

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

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

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

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

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

4.1.3. Соотношение между процессами и организациями.

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





Рис.1. Структура Международного Стандарта


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

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

1). Процесс приобретения;

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

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

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

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

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

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

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

Этот процесс состоит из следующих действий:

1) инициирование;

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

3) подготовка контракта и модернизация;

4) текущий контроль (мониторинг) поставщика;

5) принятие и завершение.
5.1.1Инициирование
Эта деятельность состоит из следующих задач:

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

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

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

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

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

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

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

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

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

г) комбинация а, б, в;

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

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

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

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

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

г) удовлетворена будущая поддержка программного продукта.

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

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

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

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

г) обязательства вспомогательных организаций;

д) поддержка используемой концепции;

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

5.1.1.9. Покупатель должен определить и документировать принятие стратегии и критериев.
^ 5.1.2Заявка на подготовку предложения
Эта деятельность состоит из задач:

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

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

б) область действия;

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

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

д) сроки и условия приобретения;

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

ж) технические ограничения.

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).

Этот процесс состоит из следующих действий:

Инициирование (начало);

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

Заключение контракта;

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

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

Оценка и проверка;

Поставка и завершение.
5.2.1Инициирование
Эта деятел