ГОСТ Р ИСО/МЭК ТО 16326-2002

Программная инженерия

РУКОВОДСТВО ПО ПРИМЕНЕНИЮ
ГОСТ Р ИСО/МЭК 12207
ПРИ УПРАВЛЕНИИ ПРОЕКТОМ

ГОССТАНДАРТ РОССИИ

Москва

Предисловие

1 РАЗРАБОТАН И ВНЕСЕН Всероссийским научно-исследовательским институтом стандартизации (ВНИИстандарт) Госстандарта России

2 ПРИНЯТ И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 5 июня 2002 г. № 226-ст

3 Настоящий стандарт содержит полный аутентичный текст международного стандарта ИСО/МЭК ТО 16326-99 «Программная инженерия. Руководство по применению ИСО/МЭК 12207 при управлении проектом»

4 ВВЕДЕН ВПЕРВЫЕ

СОДЕРЖАНИЕ

Введение

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

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

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

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

Настоящий стандарт не предназначен для установления каких-либо ролей или обязанностей организации.

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

Настоящий стандарт состоит из шести основных разделов и приложений А-Е.

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

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

Программная инженерия

РУКОВОДСТВО ПО ПРИМЕНЕНИЮ ГОСТ Р ИСО/МЭК 12207
ПРИ УПРАВЛЕНИИ ПРОЕКТОМ

Дата введения 2003-07-01

1 Область применения

Настоящий стандарт уточняет и дополняет ГОСТ Р ИСО/МЭК 12207 в части процесса управления (далее - управление программным проектом или УПП). Настоящий стандарт разработан на основе (см. рисунок 1):

- применения процесса управления из ГОСТ Р ИСО/МЭК 12207 для УПП;

- использования Руководства РМВОК™ [1] для определения и описания областей сведений по управлению, применяемых при УПП;

- использования ИСО 10006 [2] для управления проектом.

Рисунок 1 - Основные источники для настоящего стандарта

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

- общие рекомендации для УПП по применению работ процесса управления (см. 7.1 ГОСТ Р ИСО/МЭК 12207) в части их реализации в каждом из основных процессов;

- применимость УПП для каждого основного процесса;

- ключевые вопросы, относящиеся к УПП в целом;

- уточненные рекомендации для администраторов проектов (АП) программных средств в части задач управления проектом из:

- Руководства РМВОК™ [1] в части определения и описания общепризнанного подмножества из данного руководства. Общее признание означает, что описанные знания и опыт применены во многих проектах и единодушно признаны их значимость и полезность;

- ИСО 10006 [2] в части рекомендаций по реализации основных концепций, элементов и опыта применения систем качества, влияющих на практику управления проектом.

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

1.1 Круг пользователей

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

- администраторов, ответственных за организацию и постоянное совершенствование процессов жизненного цикла программных средств по ГОСТ Р ИСО/МЭК 12207;

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

- организаций или лиц, являющихся субподрядчиками при реализации УПП.

Приведены соображения для лиц:

- вовлеченных в программные проекты, но не являющихся АП;

- являющихся администраторами непрограммных проектов, но связанных с АП программных средств.

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

1.2 Предпосылки

Предпосылками для применения настоящего стандарта являются:

- наличие ГОСТ Р ИСО/МЭК 12207 и знание его;

- знание стратегий и процедур соответствующих организаций;

- знание посреднических и договорных требований (необходимых и предполагаемых).

2 Соответствие

Требования соответствия настоящему стандарту не установлены.

3 Нормативные ссылки

В настоящем стандарте использованы ссылки на следующий стандарт:

ГОСТ Р ИСО/МЭК 12207-99 Информационная технология. Процессы жизненного цикла программных средств.

Примечание - В приложении Е указаны некоторые справочные документы ([1] - [33]), относящиеся к области применения настоящего стандарта.

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

В настоящем стандарте применены термины с соответствующими определениями, установленные в ГОСТ Р ИСО/МЭК 12207, Руководстве РМВОК™ [1] и ИСО 10006 [2].

5 Обозначения

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

КСКИ (ССВ)¹⁾ - контрольный совет по конфигурации и изменениям (configuration/change control board);

РГУИ (ICWG)¹⁾ - рабочая группа по управлению интерфейсами (interface control working group);

МЭК (IEC) - Международная электротехническая комиссия (International electrotechnical commission);

ИСО (ISO) - Международная организация по стандартизации (International organization for standardization);

АП (РМ) - администратор проекта (project manager);

СПИ (SEE) - среда программной инженерии (software engineering environment);

УПП (SPM) - управление программным проектом (software project management);

СКР (WBS) - структура классификации работ (work breakdown structure).

¹⁾ В зависимости от объема и сложности проекта это может быть группа лиц, отдельное лицо или функция.

6 Руководство

6.1 Введение в управление проектом программного средства

Проект охватывает деятельность по созданию индивидуального продукта или услуги (Руководство РМВОК™ [1]). Таким образом, в проект вовлекают группу лиц, ресурсы и мероприятия, характеризуемые следующими общими свойствами:

- основными целями проекта является создание продуктов, услуг и выходных результатов;

- проект имеет начало и конец, то есть носит временной характер;

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

Программные проекты относятся к проектам, связанным с созданием программных средств, услуг или выдачей соответствующих результатов. Вопрос об отличии программных проектов от проектов, связанных с созданием других продуктов, услуг или результатов, рассмотрен Уоттом Хемпреем (Watts Haumphrey) [3] и охватывает следующие аспекты:

- программные средства являются наиболее сложными;

- внести изменения в программное средство достаточно просто;

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

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

- программирование не связано с традиционными естественными науками и отсутствуют соответствующие методы тестирования и проектного моделирования;

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

- программные средства наиболее доступны для пользователей и поэтому являются основным объектом их претензий.

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

В Руководстве РМВОК™ [1] дана важная информация по управлению проектами в целом. ГОСТ Р ИСО/МЭК 12207 содержит важную информацию о программных проектах в целом, вспомогательных процессах (5.2 ГОСТ Р ИСО/МЭК 12207) и описание большинства подлежащих реализации работ (видов деятельности) и задач (заданий). В ИСО 10006 [2] приведена информация, относящаяся к повышению качества управления проектом. Основными целями настоящего стандарта являются определение вышеописанных особенностей, с которыми сталкивается администратор программного проекта, демонстрация взаимодополняемости трех вышеуказанных документов и помощь АП программных проектов в принятии адекватных решений.

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

Реализация методологии УПП зависит от многих факторов, например персонала, организационных и договорных требований и сложности проекта.

Администраторы программного проекта определяют методологию и методы (технологию) реализации проекта, необходимые для:

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

- принятия временных и постоянных решений;

- решения возникающих проблем;

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

Администратор программного проекта должен постоянно влиять на ход работ, например санкционируя работу или приостанавливая ее, если эта работа может повлиять на другие области деятельности.

6.2 Процесс управления

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

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

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

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

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

6.2.1 Подготовка и определение области управления

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

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

- документирования обоснования проекта, его целей и задач;

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

- обеспечения персонала заданиями в рамках данной области;

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

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

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

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

Должны быть предусмотрены специальные мероприятия по определению и документированию характеристик качества (ГОСТ Р ИСО/МЭК 9126 [4]); например, когда программное средство встраивается в систему более высокого уровня, некоторые функции распределяются между программными и техническими средствами или между данным программным средством и другими, внешне взаимосвязанными с ним программными средствами или системами.

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

При этом очень важно установить критерии завершения проекта. Целью является определение успешности завершения проекта, работы или задачи в соответствии с Руководством РМВОК™[1].

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

Советы по специфике программных средств:

- должны быть детально определены требования по тиражированию, распространению, вводу в действие (инсталляции) и тестированию программного средства;

- должна быть установлена и отслежена взаимосвязь (трассировка) между требованиями к системе и программному средству, требованиями к программному средству и проекту и требованиями к программному средству и тестированию;

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

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

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

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

Должны быть определены обязанности по подготовке и утверждению (согласованию) планов.

Планы должны устанавливать модель жизненного цикла программного средства, задачи, распределение задач, их блокировку и соответствующие ресурсы. В программном проекте должен быть определен один основной график работ, а все вспомогательные графики должны быть связаны и согласованы с основным графиком. С помощью СКР можно эффективно проверять ход процесса и обеспечивать контроль этих процессов и продуктов. Метод СКР должен быть четко реализован, потому что он организует и определяет общую область управления проектом (Руководство РМВОК™ [1]). Метод СКР должен быть применен так, чтобы обеспечить управление программным проектом на соответствующих уровнях его детализации с использованием соответствующих технологий в зависимости от объема, сложности, критичности и риска проекта.

Оценки проекта, используемые при планировании, должны охватывать:

- стоимость реализации соответствующих процессов;

- инфраструктуру;

- потребности в ресурсах, включая соответствующее управление и контроль;

- оценку и контроль качества;

- управление риском;

- обеспечение СПИ;

- задания, выполняемые в каждом процессе и (или) работе.

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

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

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

- роли и обязанностях соответствующих субъектов;

- подлежащих выполнению работах и задачах;

- перечнях всех проектных результатов (продуктов), подлежащих поставке и определенных в СКР;

- критериях завершения соответствующей деятельности (работ, задач и т.д.);

- окончательных отчетных материалах;

- отчетных материалах по стоимости и графикам проведения работ;

- средствах организации работ по управлению, выпуску продукта или синхронизации работ;

- периодичности и средствах (способах) выдачи отчетных материалов;

- отчетных материалах по проблемам или выполнению деятельности;

- требованиях к ресурсам и их наличии.

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

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

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

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

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

Советы по специфике программных средств:

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

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

- использование пакетов изменений, облегчающее их внесение в программное средство с минимальной корректировкой графика работ и обеспечивающее максимальную стабильность данного средства;

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

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

- данные (для модели) собирают по ранее реализованным проектам;

- для реализации и интерпретации модели используют экспертов;

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

- ни при каких обстоятельствах при оценке окончательной стоимости проекта не следует использовать только модель стоимости;

- программные системы затруднительно представить умозрительно, поэтому трудно прогнозировать последствия внесения изменений в программные системы и управлять этими последствиями;

- программное средство следует представлять в виде «пакета», что повышает его эффективность в целом, а также эффективность его тиражирования, распространения, ввода в действие (инсталляции), тестирования и эксплуатации;

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

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

- при представлении программных ресурсов определяют:

- проведено ли сопровождение данного средства и допустимы ли его модификации;

- права собственности, например гарантии, интеллектуальные права, патенты и авторские права.

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

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

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

Примечание - Например, рабочие группы по управлению интерфейсами (РГУИ) необходимы для соблюдения и оценки ограничений на интерфейсы и контроля программных проектов. В состав РГУИ должны входить представители от каждой организации, связанной с интерфейсами. В РГУИ обсуждают программные и системные интерфейсы, рассматривают их варианты и согласовывают оптимальные методы реализации интерфейсов. Выработанные в РГУИ рекомендации по изменениям проекта до их реализации должны быть направлены для согласования в контрольный совет по конфигурации и изменениям (КСКИ).

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

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

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

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

Советы по специфике программных средств:

- исправление ошибочного графика работ необходимо тщательно проанализировать, и оно не должно оказывать негативного влияния на эффективность, стоимость или риск проекта;

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

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

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

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

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

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

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

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

- необходимы постоянные контакты с посредниками во избежание неожиданных изменений в стоимости, графике работ и эффективности проекта.

6.2.4 Проверка и оценка

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

Администратор программного проекта должен отвечать за проведение оценок программных продуктов и планов:

- по результатам анализа программных продуктов, работ и задач;

- на соответствие планам, принципам, методологии и технологии УПП;

- в части документирования планов и обязательств;

- в части удовлетворения их установленным требованиям;

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

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

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

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

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

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

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

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

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

Советы по специфике программных средств:

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

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

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

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

- необходим единый (интегрированный) план сборки системы и модулей программных средств в соответствии со стратегией выпуска редакции системы;

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

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

6.2.5 Завершение

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

В работе «завершение» следует использовать полученные ранее результаты с соответствующими данными и отчетными материалами, например такие, как:

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

- отчеты об обеспечении качества программного средства и результаты эксплуатационного тестирования;

- отчеты о неисправностях программного средства;

- результаты аудиторских проверок;

- результаты приемки и окончания процесса, работы или задачи;

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

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

Данная работа может быть проведена между процессами, работами и задачами. В Руководстве РМВОК™ [1] (для ГОСТ Р ИСО/МЭК 12207 вместо термина «фаза» следует подставить термины «процесс», «работа» или «задача») определено:

По окончании проектной фазы обычно проводят анализ ее результатов и состояния проекта, чтобы:

а) определить возможность перехода к следующей фазе и

b) обнаружить и должным образом скорректировать неправильную стоимость фазы.

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

ПРИЛОЖЕНИЕ А
(справочное)

Обеспечение процесса управления по ГОСТ Р ИСО/МЭК 12207

В таблице А.1 показано, как основные процессы жизненного цикла из ГОСТ Р ИСО/МЭК 12207 обеспечивают (поддерживают) работы процесса управления.

Примечания

1 Отметка на более высоком уровне (например, 5.2) распространяется все нижние уровни (например, 5.2.3).

2 В данной таблице X обозначает безусловное применение, О - условное (могут быть некоторые нюансы).

Таблица А.1 - Обеспечение работ процесса управления основными процессами (по ГОСТ Р ИСО/МЭК 12207)

ПРИЛОЖЕНИЕ В
(справочное)

Работы УПП, связанные с работами процесса управления

В таблице В.1 определены процессы из Руководства РМВОК™ [1], применяемые при работах процесса управления из ГОСТ Р ИСО/МЭК 12207.

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

ПРИЛОЖЕНИЕ С
(справочное)

Процессы управления проектом, соответствующие работам процесса управления по ГОСТ Р ИСО/МЭК 12207

В таблице С.1 определены процессы управления проектом из ИСО 10006 [2], применяемые при работах процесса управления из ГОСТ Р ИСО/МЭК 12207.

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

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

ПРИЛОЖЕНИЕ D
(справочное)

Дополнительная информация

D.1 Введение

В настоящем приложении приведена дополнительная информация по управлению из ИСО 10006 [2] и Руководства РМВОК™ [1]. В таблице D.1 использованы данные из ГОСТ Р ИСО/МЭК 12207 на уровне работ, из ИСО 10006 [2] на уровне процессов и из Руководства РМВОК™ [1] на уровне областей сведений по управлению проектом. Термины, использованные в таблице D.1, определены в D.2 (из Руководства РМВОК™ [1]) и D.3 (из ИСО 10006 [2]).

Таблица D.1 - Соотношения между ГОСТ Р ИСО/МЭК 12207, ИСО 10006 [2] и Руководством РМВОК™ [1]