Основы управления информационными технологиями

Процессные стандарты. ГОСТ Р ИСО/МЭК 12

Показывать лекцию целиком

Среди процессных стандартов в области ИТ есть несколько основополагающих разработок ISO, сыгравших важнейшую роль в становлении процессного подхода к управлению ИТ.

Далее будут рассмотрены российские аналоги стандартов ISO, т. е. ГОСТы, в названии которых присутствует сочетание "Р ИСО". Они представляют собой аутентичные официальные переводы стандартов ISO на русский язык. В области управления ИТ это прежде всего ГОСТ Р ИСО/МЭК 12207-99 "Процессы жизненного цикла программных систем" и тесно связанные с ним ГОСТ Р ИСО/МЭК 16326-2002, ГОСТ Р ИСО/МЭК 15271-2002 и ГОСТ Р ИСО/МЭК 14764-2002.

Появившиеся в конце 1990-х - начале 2000-х годов, эти стандарты демонстрируют совершенно иной подход к управлению ИТ и качественно иной теоретический уровень, чем ГОСТ 34. Это проявляется в первую очередь в ориентированности на процессы, современном взгляде на управление качеством, проектном подходе к деятельности по созданию информационных систем. Одно из центральных мест здесь занимает стандарт ГОСТ Р ИСО/МЭК 12207 "Процессы жизненного цикла программных систем" (ГОСТ 12207, 1999) - один из самых известных и распространенных процессно-ориентированных стандартов в области управления ИТ. Ссылки на него встречаются практически во всех работах и методиках, относящихся к процессам управления ИТ.

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

Методологическая основа ГОСТ Р ИСО/МЭК 12207 - разбиение процессов на группы, которых в стандарте вводится три.

  • ОсновныеНе следует путать основные и вспомогательные процессы в смысле стандарта ГОСТ Р ИСО/МЭК 12207 с основными и вспомогательными процессами, показанными в цепи добавленной стоимости на рис 1.2. С точки зрения цепи добавленной стоимости, все процессы, описанные в ГОСТ Р ИСО/МЭК 12207, относятся к вспомогательным. . Это процессы, непосредственно относящиеся к жизненному циклу информационной системы. Можно считать, что это производственные процессы организации.
  • Вспомогательные. Это процессы, предназначенные для поддержки основных процессов. Сами по себе эти процессы организации не нужны - только в связи с основными процессами, которые они обслуживают. Несколько процессов из этой группы связано с управлением качеством.
  • Организационные. Это общекорпоративные процессы, такие как "Обучение" или "Управление". Эти процессы существуют в организации независимо от того, как организовано производство и как устроены вспомогательные процессы.
    •

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

    Номера процессов в таблице 3.1 соответствуют номерам разделов документа.

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

    Структура процессов жизненного цикла программных систем по ГОСТ Р ИСО/МЭК 12207

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

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

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

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

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

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

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

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

    Возникает вопрос: а как быть, если общекорпоративный процесс, скажем, обучения отсутствует? Существует как минимум три варианта ответа:

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

    Какой вариант выбрать - дело организации, но сам выбор сделать придется, и одно из привлекательных свойств ГОСТ Р ИСО/МЭК 12207 состоит как раз в том, что он явно говорит о необходимости такого выбора. Как следствие, при планировании проекта автоматизации необходимо будет запланировать соответствующие работы.

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

    "5.1. Процесс заказа

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

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

  • подготовка;
  • подготовка заявки на подряд;
  • подготовка и корректировка договора;
  • надзор за поставщиком;
  • приемка и закрытие договора.
    •

    5.1.1. Подготовка

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

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

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

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

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

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

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

  • a) покупка готового программного продукта, удовлетворяющего определенным требованиям;
  • b) разработка программного продукта или получение программной услуги собственными силами;
  • c) разработка программного продукта или получение программной услуги на договорной основе;
  • d) комбинации по перечислениям a), b), c);
  • e) модернизация существующего программного продукта или услуги.
    •

    (Как видим, стандарт не включает таких вариантов, как приобретение прав абонентского доступа к стандартному программному обеспечению или доработку удаленного ПО под требования заказчика с последующим абонентским доступом. Нет и варианта аренды ПО, как компонента более сложного объекта аренды. Вряд ли возможно перечислить все существующие и будущие варианты реализации заказа в стандарте, но задача 5.1.1.6 разработки такого списка в любом случае имеет смысл. - АБ).

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

    Приведенный отрывок хорошо иллюстрирует стиль стандарта: описательный характер определения процессов, скорее рекомендательный, чем директивный порядок работ и полное отсутствие форматов документов, возникающих в ходе выполнения работ и задач. Последнее, с одной стороны, оставляет свободу при внедрении стандарта, с другой - резко затрудняет процесс внедрения. Фактически это означает, что управленцы должны будут самостоятельно разработать формы основных документов, согласовать и утвердить их у руководства. И это при полном отсутствии подсказок со стороны стандарта. По сравнению с ГОСТ 34, где форматы документов определены достаточно детально, ГОСТ Р ИСО/МЭК 12207-00 требует значительно более высокой квалификации управленцев и более эффективной работы организации в целом. Возможно поэтому, несмотря на ряд достоинств, стандарт остается пока уделом немногих продвинутых организаций и предприятий.

    Отдельно стоит сказать о том, как рассматриваемый стандарт подходит к управлению качеством.

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

    Процесс обеспечения качества (6.3)

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

    Процесс верификации (6.4)

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

  • "a) соответствие и своевременность установления проектных требований к планированию;
  • b) пригодность, реализуемость, выполнимость в соответствии с планом и условиями договора выбранных для проекта процессов;
  • с) применимость стандартов, процедур и условий к процессам проектирования;
  • d) укомплектованность и обученность персонала в соответствии с условиями договора".
    •

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

    Процесс аттестации (6.5)

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

    Процесс совместного анализа (6.6)

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

    Процесс аудита (6.7)

    Процесс аудита

    "является процессом определения соответствия требованиям, планам и условиям договора".

    Процесс может

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

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

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

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

    Чрезвычайно важный раздел стандарта - Приложение А "Процесс адаптации". Процессом адаптации называется "процесс применения положений настоящего стандарта к условиям реализации конкретного программного проекта". Описан этот процесс в том же стиле, что и остальные процессы. Адаптация - обязательная деятельность в ходе применения стандарта на практике. Наличие процесса адаптации подразумевает, что ГОСТ Р ИСО/МЭК 12207 сначала внедряется в организации в целом, а затем для каждого проекта из него "выкраивается" подмножество необходимых процессов. О том, как организовать внедрение стандарта в организации, ГОСТ Р ИСО/МЭК 12207 умалчивает.

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

    Рассмотрен ГОСТ Р ИСО/МЭК 12207 - один из наиболее удачных и широко известных процессных стандартов последнего времени. Проанализированы новые идеи, впервые появившиеся в этом стандарте, и его ограничения. Особо отмечается сложность организации внедрения стандарта.

    Вопросы

  • Чем отличается стандарт ГОСТ Р ИСО/МЭК 12207 от ГОСТ 34 (одно предложение)?
  • Какова структура ГОСТ Р ИСО/МЭК 12207?
  • Какие конкретные критерии и методы оценки поставщика в процессе заказа предлагает ГОСТ Р ИСО/МЭК 12207?
  • В чем разница между процессами аттестации, верификации, аудита и обеспечения качества?
  • Что такое адаптация в терминологии ГОСТ Р ИСО/МЭК 12207?
  • Каковы практические недостатки ГОСТ Р ИСО/МЭК 12207 по сравнению с ГОСТ 34?
    •
    Предыдущее занятие Следующее занятие
    Вернуться к учебному плану
    ^