Общая характеристика стандарта ISO/IEC 12207

Общие сведения о семействе стандартов 12207

• •    В основе практически всех современных промышленных технологий создания ПС лежит международный стандарт ISO/IEC 12207 «Системная и программная инженерия. Процессы жизненного цикла программных средств.»

• •    В состав семейства входят:

o ISO/IEC 12207:1995 «Information technology– Software life cycle processes» с дополнениями и изменениями ISO/IEC 12207:1995/AMD 1:2002 и ISO/IEC 12207:2002/AMD 2:2004 (принят в новой редакции в 2008 году)

o ISO/IEC 12207:2008 «Systems and software engineering–Software life cycle processes»

o ISO/IEC TR 15271:1998 Information technology – Guide for ISO/IEC 12207 (Software Life Cycle Processes)

o ISO/IEC TR 16326:1999 Software engineering – Guide for the application of ISO/IEC 12207 to project management o Спецификации ISO/IEC 12207:1995, ISO/IEC TR 15271:1998 и ISO/IEC TR 16326:1999 введены в качестве национальных стандартов РФ

Развитие стандарта

Стандарт ISO/IEC 12207 был опубликован 1 августа 1995 года и явился первым международным стандартом, содержавшим представительный набор процессов ЖЦ, действий и задач в отношении ПО, которое рассматривалось как часть большей системы, а также применительно к программным продуктам и услугам. За стандартом ISO/IEC 12207 в ноябре 2002 года последовал стандарт ISO/IEC 15288, посвященный процессам ЖЦ систем. Широта применения ПС привела к тому, что ПО и процессы его разработки не могли рассматриваться в отрыве от систем, но только как составная часть системы и процесса её создания. В Дополнениях к стандарту ISO/IEC 12207 были введены цель процесса и его выходы и определена эталонная модель процесса, отвечающая требованиям стандарта ISO/IEC 15504-2. Международный стандарт ISO/IEC 12207:2008, представляет собой переработан- ные и исправленные дополнения к стандарту ISO/IEC 12207 и является первым шагом в стратегии SC7 по гармонизации спецификаций, имеющей целью создание полностью интегрированного набора процессов ЖЦ систем и программных средств и руководства по их применению.

Главные особенности редакции 2008 года

Данная редакция:

• •    включает и развивает положения Дополнений 2002 г. и 2004 г.

• •    использует терминологию, согласованную со стандартом ISO/IEC 15288:2008;

• •    по возможности использует наименование и структуру процессов аналогичную той, что содержится в стандарте ISO/IEC 15288:2008;

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

• •    использует результаты десятилетнего опыта разработки и применения стандартов ISO/IEC 12207 и ISO/IEC 15288.

ISO/IEC 12207:2008Основные процессы жизненного цикла

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

• •    Заказ.

• •    Поставка.

• •    Разработка.

• •    Эксплуатация.

• •    Сопровождение.

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

Заказ

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

Каждый этап подразумевает, что предыдущий завершен.

Подготовка

• •    Собрана информация, объясняющая необходимость разработки или модифицирования продукта;

• •    Составлен и утвержден список системных требований;

• •    Определены глобальные требования к программному обеспечению;

• •    Рассмотрены варианты покупки готового программного продукта, покупки и модернизации, создания «с нуля»;

• •    Проанализированы технические требования;

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

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

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

• o    тип реализуемого договора;

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

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

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

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

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

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

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

• o    описание области применения системы;

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

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

• o    сроки и условия реализации заказа;

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

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

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

• •    Определены контрольные пункты договора, при выполнении которых анализируется и проверяется деятельность поставщика.

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

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

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

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

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

Корректировка договора

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

Подписание договора

• •    Подписан обновленный контракт с учётом корректировок, внесенных при обсуждении заказчика и поставщика.

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

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

• •    Проконтролирована своевременность взаимообмена всей необходимой информацией и решения всех возникающих проблем.

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

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

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

• •    Заказчиком принят от поставщика продукт (при выполнении всех условий приемки).

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

Поставка

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

Разработка

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

• •    Подготовка программного средства.

• •    Анализ требований технического задания.

• •    Проектирование архитектуры программного средства.

• •    Детальное проектирование программного средства.

• •    Конструирование программного средства.

• •    Комплексирование программного средства.

• •    Тестирование.

Подготовка ПС

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

• •    Оформление выходных результатов в соответствии с процессом документирования.

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

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

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

Анализ ТЗ

• •    Анализ области применения разрабатываемой системы с точки зрения определения требований к ней.

  
  
  

• •    Оформление требований к программному средству, которые должны описывать:

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

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

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

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

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

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

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

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

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

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

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

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

• o    учёт потребностей заказчика;

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

• o    тестируемость;

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

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

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

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

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

• o    учёт требований к системе;

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

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

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

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

Детальное проектирование программного средства

• •    Трансформирование требований к программному объекту в архитектуру, которая описывает общую структуру объекта и определяет компоненты программного объекта.

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

• •    Разработка и оформление общего проекта базы данных.

• •    Разработка и оформление предварительной версии документации пользователя.

• •    Разработка и оформление предварительных общих требований к тестированию программного объекта и графику сборки программного продукта.

• •    Оценка архитектуры программного объекта и эскизные проекты интерфейсов и базы данных по следующим критериям:

• o    учёт требований к программному объекту;

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

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

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

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

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

Конструирование программного средства

• •    Разработка технического проекта для каждого компонента программного объекта.

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

• •    Разработка технического проекта базы данных.

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

• •    Оценка технического проекта тестирования по следующим критериям:

• o    учёт требований к программному объекту;

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

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

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

• o    возможность тестирования;

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

Комплексирование программного средства

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

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

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

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

  
  

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

• •    Сбор объектов программной в единую систему вместе с объектами технической конфигурации, ручными операциями и, при необходимости, с другими системами.

Тестирование

• •    Тестирование в соответствии квалификационным требованиям к программному объекту.

• •    Оценка проекта, запрограммированного программного объекта, тестирование по следующим критериям:

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

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

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

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

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

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

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

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

• •    Проведение аудиторской проверки и доработка

Эксплуатация

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

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

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

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

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

• •    процесс документирования:

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

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

o выпуск;

o сопровождение.

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

• o    подготовка процесса;

• o    определение конфигурации;

• o    контроль конфигурации;

• o    учёт состояний конфигурации;

• o    оценка конфигурации;

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

• •    процесс обеспечения качества:

• o    подготовка процесса;

• o    обеспечение продукта;

• o    обеспечение процесса;

• o    обеспечение систем качества.

• •    процесс верификации:

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

o верификация.

• •    процесс аттестации:

o подготовка процесса; o аттестация.

• •    процесс совместного анализа:

• o    подготовка процесса;

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

• o    технические анализы.

• •    процесс аудита:

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

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

• •    процесс решения проблем:

o подготовка процесса; o решение проблемы.

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

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

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

• o    подготовка и определение области управления;

• o    планирование;

• o    выполнение и контроль;

• o    проверка и оценка;

• o    завершение.

• •    процесс создания инфраструктуры:

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

o создание инфраструктуры;

o сопровождение инфраструктуры.

• •    процесс усовершенствования:

o создание процесса;

o оценка процесса;

o усовершенствование процесса.

• •    процесс обучения:

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

o разработка учебных материалов;

o  реализация плана обучения.

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