Программная инженерия. Руководство по ... · 2011-06-03 · guide...

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

ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙФЕДЕРАЦИИ

ПРОГРАММНАЯ ИНЖЕНЕРИЯ

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

ПРИ УПРАВЛЕНИИ ПРОЕКТОМ

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

Москва

Предисловие

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

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

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

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

СОДЕРЖАНИЕ

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

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

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

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

База нормативной документации: www.complexdoc.ru

1

www.princexml.com

Prince - Non-commercial License

This document was created with Prince, a great way of getting web content onto paper.

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

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

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

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

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

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

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

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

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

Приложение D. Дополнительная информация

D.1 Введение

D.2 Определения процессов из области сведений поуправлению проектом

D.3 Определения в части качества в процессах управленияпроектом

Приложение Е. Библиография

Введение

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


2

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

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

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

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

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

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

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


3

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

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

ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙФЕДЕРАЦИИ

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

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

Software engineering.Guide for the application of GOST R ISO/IEC 12207 to project

management

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

1 Область примененияНастоящий стандарт уточняет и дополняет ГОСТ Р ИСО/МЭК

12207 в части процесса управления (далее - управлениепрограммным проектом или УПП). Настоящий стандартразработан на основе (см. рисунок 1):

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

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

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


4

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

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

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

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

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

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

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

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

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


5

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

1.1 Круг пользователейНастоящий стандарт предназначен для субъектов,

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

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

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

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

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

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

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

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


6

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

являются:

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

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

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

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

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

стандарт:

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

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

4 ОпределенияВ настоящем стандарте применены термины с

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


7

5 ОбозначенияВ настоящем стандарте использованы следующие обозначения

(символы и сокращения):

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

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

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

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

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

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

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

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

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

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

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

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


8

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

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

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

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

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

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

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

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

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

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

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

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


9

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

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

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

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

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

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

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

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

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

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


10

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

6.2 Процесс управленияВ данном подразделе рассмотрен процесс управления из 7.1

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

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

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

ГОСТ Р ИСО/МЭК 12207

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

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


11

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

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


7.1.1 Подготовка и определение области управления. Даннаяработа состоит из следующих задач:

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

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

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

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


12

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

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

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

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

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

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

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

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


13

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

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

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

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

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

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

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

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


14

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

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

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

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


7.1.2 Планирование. Данная работа состоит из следующейзадачи:

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

a) установление графиков своевременного решения задач;

b) оценка необходимых трудозатрат;

c) определение ресурсов, необходимых для выполнения задач;

d) распределение задач по исполнителям;

e) определение обязанностей исполнителей;

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

g) установление используемых в процессе критериевуправления качеством;

h) определение затрат, связанных с реализацией процесса;


15

i) обеспечение условий и определение инфраструктурывыполнения процесса.

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

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

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

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

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

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

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

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

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

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

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


16

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

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

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

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

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

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

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

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

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

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

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

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


17

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

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

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

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

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


18

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

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


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

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

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

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

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


19

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

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

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

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

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

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

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

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

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

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

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


20

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


7.1.3 Выполнение и контроль. Данная работа состоит изследующих задач:

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

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

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

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

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

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


21

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

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

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

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

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

Процессы, связанные с риском (управление проектным риском),охватывают неопределенности при планировании проекта и


22

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


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

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

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

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

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

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

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

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


23

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

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

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

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


7.1.4 Проверка и оценка. Данная работа состоит из следующихзадач:

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

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

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

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

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

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

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

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


24

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

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

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

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

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

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


25

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

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

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

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


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

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

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


26

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

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

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

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

6.2.5 Завершение


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

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

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

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


27

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

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

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

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

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

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

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

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

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

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

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

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

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


28

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

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

МЭК 12207В таблице А.1 показано, как основные процессы жизненного

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

П р и м е ч а н и я

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

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

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

7.1 Работы процесса управления

5 Основныепроцессы

жизненного цикла

7.1.1Подготовка

иопределение

областиуправления

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

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

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

7.1.5Завершение

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


29











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

5.1.1.5Использованиепроцессаразработки

X

5.1.1.8 План заказа X

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

X X

5.1.3 Подготовка икорректировкадоговора

X X

5.1.3.5 Контроль иоценка изменений

X

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

X X

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

X X


30











5.2 Процесспоставки

5.2.1 Подготовка X

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

X

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

X О


X

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

X О

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

X

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

X

5.3 Процессразработки

X


31











5.3.1 Подготовкапроцесса

X

5.3.1.1 Выбормоделижизненного циклаи разметка работ

X

5.3.1.4 Разработкаи выполнениепланов процесса

X

5.3.2.2 Оценкасистемныхтребований

X

5.3.3.2 Оценкасистемнойархитектуры итребований к ней

X

5.3.4.2 Оценкатребований кпрограммнымсредствам

X


32











5.3.4.3 Проведениесовместныханализовтребований кпрограммнымсредствам

X

5.3.5.6 Оценкапрограммнойархитектуры ипроектовинтерфейсов и базданных

X

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

X

5.3.6.7 Оценкатехническогопрограммногопроекта итребований ктестированию

X


33











5.3.6.8 Проведениесовместныханализовтехническогопрограммногопроекта

X

5.3.7.5 Оценкамашинныхпрограмм ирезультатов ихтестирования

X

5.3.8.1 Разработкаплана сборки

Х

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

X

5.3.8.6 Проведениесовместныханализов сборки

X


34











программныхсредств

5.3.9.3 Оценкапроекта,программ, тестов,результатовтестирования идокументовпользователя

X

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

5.3.10.3 Оценкасобраннойсистемы

X

5.3.11.2 Оценкасистемы

X


35











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

X

5.3.12.1Разработка планаввода в действиепрограммныхсредств

О X

5.3.13.1Обеспечениепроведениязаказчикоманализаготовности кприемке иприемочныхиспытанийпрограммныхсредств

X

5.4 Процессэксплуатации

X


36












X

5.5 Процесссопровождения


X

5.5.1.1 Разработкаи выполнениепланов и процедурпо сопровождению

X

5.5.1.2Установлениепроцедур для:получения,документированияи контролясообщений опроблемах изаявок наизменения;обеспеченияобратной связи

X


37











5.5.2 Анализпроблем иизменений

X

5.5.2.1 Анализсообщений опроблемах илизаявок наизменения

X

5.5.2.3 Принятиевариантовреализацииизменений

X

5.5.3 Внесениеизменений

X

5.5.4 Проверка иприемка присопровождении

X

5.5.5 Перенос X


38











5.5.5.2 Разработкаи выполнениеплана переноса

X

5.5.5.6 Анализпоследствийпереноса

X

5.5.6 Снятие сэксплуатации

X X

5.5.6.1 Разработкаи выполнениеплана снятия сэксплуатации

X


39

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

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

управленияВ таблице В.1 определены процессы из Руководства РМВОК™ [1],

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

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

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

Областисведений поуправлению

проектом

Процессы изобласти сведений

по управлениюпроектом








4.1 Разработкаплана проекта

X X

4.2 Выполнениеплана проекта

X X

4 Управлениекомпоновкойпроекта

4.3 Общий контрольизменений

X X


40



проектом










5.1 Подготовка X X

5.2 Планированиеобласти

X X

5.3 Определениеобласти

X X

5.4 Проверкаобласти

X X X

5 Управлениеобластьюпроекта

5.5 Контрольизменений области

X X X X


41



проектом










6.1 Определениеработ

X X

6.2 Установлениепоследовательностиработ

X

6.3 Оценкапродолжительностиработ

X X X

6.4 Созданиеграфика работ

X

6 Управлениесрокамипроекта

6.5 Контрольвыполненияграфика

X X


42



проектом










7.1 Планированиересурсов

X X

7.2 Составлениесметы затрат

X X X

7.3 Выделениебюджетныхассигнований

X

7 Управлениестоимостьюпроекта

7.4 Контрольстоимости

X X

8.1 Планированиекачества

X X

8.2 Обеспечениекачества

X X

8 Управлениекачествомпроекта

8.3 Контролькачества

X X


43



проектом










9.1Организационноепланирование

X X

9.2 Формированиештатов

X X

9 Управлениелюдскимиресурсамипроекта

9.3 Организацияколлектива

X X

10.1 Планированиеобмена

X X

10.2Распространениеинформации

X

10.3 Подготовкаотчетныхматериалов

X X

10Управлениеобменом впроекте

10.4Административноезавершениепроекта

X X


44



проектом










11.1 Определениериска

X X

11.2Количественнаяоценка риска

X X

11.3 Разработкаответных действийна риск

X X X

11Управлениерискомпроекта

11.4 Контрольответных действий

X X X X


45



проектом










12.1 Планированиепотребности впроекте

X X

12.2 Планированиепредложений попроекту

X X

12.3 Рассмотрениезаявок

X X

12.4 Выборпроектанта

X X X

12.5 Заключениедоговора

X X

12Управлениеорганизациейпроекта

12.6 Реализациядоговора

X X

X - данный процесс применяют в данной работе.


46

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

Процессы управленияпроектом, соответствующие

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

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

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

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


47

Процессы из ИСО 10006 [2] 7.1 Работы процесса управления по ГОСТ Р ИСО/МЭК 12207

Группыпроцессов

управленияпроектом

Процессыуправленияпроектом








5.3.1 Подготовкапроекта иразработка планапроекта

X X X

5.3.2 Управлениевзаимодействием

X X X

5.3.3 Управлениеизменениями

X X X

5.3 Процессыуправлениявзаимосвязями

5.3.4 Завершение X X

5.4.1 Разработкаконцепции

X

5.4.2 Определениеобласти проекта иее контроль

X X X

5.4.3 Определениеработ

X

5.4 Процессы,связанные собластьюпроекта

5.4.4 Контрольработ

X X


48












5.5.1 Планированиевзаимосвязи работ

X

5.5.2 Оценкапродолжительности

X

5.5.3 Созданиеграфика (работ)

X

5.5 Процессы,связанные сосроками

5.5.4 Контрольвыполненияграфика

X X X

5.6.1 Оценкастоимости

X

5.6.2 Формированиебюджета

X

5.6 Процессы,связанные состоимостью

5.6.3 Контрольстоимости

X X X


49












5.7.1 Планированиересурсов

X5.7 Процессы,связанные сресурсами

5.7.2 Контрольресурсов

X X Х

5.8.1 Определениеорганизационнойструктуры проекта

X

5.8.2 Формированиештата

X О

5.8 Процессы,связанные сперсоналом

5.8.3Совершенствованиеколлектива

О

5.9.1 Планированиеобмена

О О

5.9.2 Управлениеинформацией

X X

5.9 Процессы,связанные собменом

5.9.3 Контрольобмена

О О


50












5.10.1Идентификацияриска

О X

5.10.2 Оценкариска

X

5.10.3 Выработкареакции на риск

X

5.10 Процессы,связанные сриском

5.10.4 Контрольриска

О О


51












5.11.1Планирование иконтроль закупки

О X

5.11.2Документированиетребований

О X

5.11.3 Оценкасубподрядчиков

О О X

5.11.4 Организациясубподряда

О X X X

5.11 Процессы,связанные сзакупкой

5.11.5 Контрольдоговора

X X


52

ПРИЛОЖЕНИЕ 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]

Работы процессов поГОСТ Р ИСО/МЭК

12207Уровни процессов по

ИСО 10006 [2]

Области сведенийпо управлению

проектом изРуководстваРМВОК™ [1]

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


53



ИСО 10006 [2]





5.4 Процессы,связанные с областьюпроекта

5 Управлениеобластью проекта


7 Управлениестоимостью проекта


9 Управлениелюдскимиресурсами проекта

5.10 Процессы,связанные с риском

11 Управлениериском проекта

5.1.1 Подготовка

5.11 Процессы,связанные с закупкой

12 Управлениеорганизациейпроекта


54



ИСО 10006 [2]





5.4 Процессы,связанные областьюпроекта


5.5 Процессы,связанные со сроками

6 Управлениесроками проекта



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




55



ИСО 10006 [2]










8 Управлениекачеством проекта


5.1.3 Подготовка икорректировкадоговора




56



ИСО 10006 [2]







5.7 Процессы,связанные с ресурсами


5.9 Процессы,связанные с обменом

10 Управлениеобменом в проекте

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






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




57



ИСО 10006 [2]



5.2 Процесспоставки

5.2.1 Подготовка 5.4 Процессы,связанные с областьюпроекта


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





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




58



ИСО 10006 [2]





















59



ИСО 10006 [2]






60



ИСО 10006 [2]





















61



ИСО 10006 [2]













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



5.3 Процессразработки


62



ИСО 10006 [2]
















5.4 Процессы.связанные с областьюпроекта

5.3.2 Анализтребований ксистеме




63



ИСО 10006 [2]




5.3.3Проектированиесистемнойархитектуры

-






5.3.4 Анализтребований кпрограммнымсредствам




64



ИСО 10006 [2]











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




65



ИСО 10006 [2]











5.3.6 Техническоепроектированиепрограммныхсредств




66



ИСО 10006 [2]











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




67



ИСО 10006 [2]











5.3.8 Сборкапрограммныхсредств




68



ИСО 10006 [2]











5.3.9Квалификационныеиспытанияпрограммныхсредств




69



ИСО 10006 [2]











5.3.10 Сборкасистемы




70



ИСО 10006 [2]











5.3.11Квалификационныеиспытания системы




71



ИСО 10006 [2]








5.3.12 Ввод вдействиепрограммныхсредств








5.3.13 Обеспечениеприемкипрограммныхсредств




72



ИСО 10006 [2]



5.4 Процессэксплуатации











5.4.2Эксплуатационныеиспытания

- 8 Управлениекачеством проекта

5.4.3 Эксплуатациясистемы

- 8 Управлениекачеством проекта


73



ИСО 10006 [2]






5.4.4 Поддержкапользователя



5.5 Процесссопровождения


74



ИСО 10006 [2]
















75



ИСО 10006 [2]










5.5.2 Анализпроблем иизменений






5.5.3 Внесениеизменений




76



ИСО 10006 [2]







5.5.4 Проверка иприемка присопровождении






5.5.5 Перенос




77



ИСО 10006 [2]






5.5.6 Снятие сэксплуатации



6.1 Процессдокументирования


78



ИСО 10006 [2]














6.1.2Проектирование иразработка




79



ИСО 10006 [2]





6.1.3 Выпуск



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



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








6.2.2 Определениеконфигурации




80



ИСО 10006 [2]








6.2.3 Контрольконфигурации



6.2.4 Учет состоянийконфигурации





6.2.5 Оценкаконфигурации



6.2.6 Управлениевыпуском и поставка




81



ИСО 10006 [2]



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











6.3.2 Обеспечениепродукта




82



ИСО 10006 [2]



53 Процессыуправлениявзаимосвязями





6.3.3 Обеспечениепроцесса



6.3.4 Обеспечениесистем качества



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


83



ИСО 10006 [2]
















84



ИСО 10006 [2]












6.4.2 Верификация



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


85



ИСО 10006 [2]














86



ИСО 10006 [2]








6.5.2 Аттестация



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









87



ИСО 10006 [2]










6.6.2 Анализыуправленияпроектом








6.6.3 Техническиеанализы




88



ИСО 10006 [2]



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














89



ИСО 10006 [2]








6.7.2 Аудиторскаяпроверка



6.8 Процессрешения проблем






6.8.2 Решениепроблемы




90



ИСО 10006 [2]



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


91



ИСО 10006 [2]















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




92



ИСО 10006 [2]





93



ИСО 10006 [2]





















94



ИСО 10006 [2]






95



ИСО 10006 [2]





















96



ИСО 10006 [2]





97



ИСО 10006 [2]





















98



ИСО 10006 [2]





7.1.5 Завершение 5.3 Процессыуправлениявзаимосвязями


7.2 Процесссозданияинфраструктуры











99



ИСО 10006 [2]











7.2.2 Созданиеинфраструктуры




100



ИСО 10006 [2]







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



7.3 Процессусовершенствования






7.3.1 Созданиепроцесса




101



ИСО 10006 [2]








7.3.2 Оценкапроцесса




102



ИСО 10006 [2]











7.3.3Усовершенствованиепроцесса



7.4 Процессобучения


103



ИСО 10006 [2]











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





7.4.3 Реализацияплана обучения



D.2 Определения процессов из областисведений по управлению проектом

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


104

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

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

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

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

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

управление качеством проекта (Project Quality Management):Подмножество управления проектом, охватывающее процессы,обеспечивающие соответствие проекта установленнымпотребностям. Управление качеством проекта включает в себяпланирование качества, обеспечение качества и контролькачества;


105

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

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

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

D.3 Определения в части качества впроцессах управления проектом

Ниже приведены термины с соответствующими определениямииз ИСО 10006 [2], использованные в таблицах С.1 и D.1:

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

- планирование обмена - планирование информационной икоммуникационной систем проекта;

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


106

- контроль обмена - контролирование обмена в соответствующейзапланированной коммуникационной системе;

процессы, связанные со стоимостью (cost-related processes):Данные процессы предназначены для прогнозирования стоимостипроекта и управления ею, а также для обеспечения выполненияпроекта в рамках установленного бюджета. Такими процессамиявляются:

- оценка стоимости - проведение оценок стоимости проекта;

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

- контроль стоимости - контролирование стоимости приреализации проекта и отклонений от проектного бюджета.

П р и м е ч а н и е - Более подробно эти процессы рассмотрены вИСО/ТО 10014 [5].

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

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

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

- управление изменениями и конфигурацией - прогнозированиеизменений и управление ими по всем процессам;

- завершение - окончание процессов и обеспечение обратнойсвязи;

процессы, связанные с персоналом (personnel-relatedprocesses): Люди, вовлекаемые в проект, определяют качество иуспешность его реализации. Процессы, связанные с персоналом,предназначены для создания соответствующей среды, в которой


107

люди могут эффективно работать над реализацией проекта.Такими процессами являются:

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

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

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

П р и м е ч а н и е - Количественные аспекты управленияперсоналом связаны с процессами управления ресурсами.

процессы, связанные с закупкой (purchasing-relatedprocesses): Эти процессы связаны с закупкой, заказом илиприобретением продуктов, созданных в проекте. Такимипроцессами являются:

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

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

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

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

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

П р и м е ч а н и я

1 Как отмечено в ИСО 8402 [6], термин «продукция (product)»охватывает услуги, технические средства, обрабатываемыематериалы, программные средства или их комбинации.


108

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

3 Дополнительные рекомендации по данному вопросу приведеныв ИСО 9004-1 [7].

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

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

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

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

процессы, связанные с риском (risk-related processes):Управление проектным риском связано с неопределенностями впроекте и требует структурированного подхода. Целямипроцессов, связанных с риском, являются минимизациявоздействия потенциально неблагоприятных событий и выработкапредложений по совершенствованию проекта. В ИСО 10006 [2]термин «риск» охватывает оба эти аспекта. Риск связан либо спроектными процессами, либо с проектными продуктами.Процессами, связанными с риском, являются:

- идентификация риска - определение риска в проекте;

- оценка риска - оценка вероятности возникновения рискованныхсобытий и влияния рискованных событий на проект;


109

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

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

процессы, связанные с областью проекта (scope-relatedprocesses): По ИСО 10006 [2] термин «область (проекта) (scope)»охватывает описание проектной продукции, ее характеристик испособы их измерения или оценки. Эти процессы предназначеныдля:

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

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

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

Процессами, связанными с областью проекта, являются:

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

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

- определение работ - установление и документирование работ иэтапов, необходимых для достижения целей проекта;

- контроль работ - контроль фактической работы, выполняемой впроекте;

процессы, связанные со сроками (time-related processes):Данные процессы предназначены для определениявзаимозависимостей между работами и продолжительностьюработ, а также для обеспечения выполнения всего проекта вустановленные сроки. Такими процессами являются:


110

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

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

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

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

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

Библиография[1] Руководство РМВОК™ Руководство по сведениям для органа

управления проектом. Комитет по стандартам институтауправления проектом (PMI), 1996

[2] ИСО 10006-971) Управление качеством. Руководства покачеству при управлении проектом

[3] Introduction of Software Process Improvement (CMU/SEl-92-Tr-7),Watts Humphrey, 1992

[4] ГОСТ Р ИСО/МЭК 9126-93 Информационная технология.Оценка программной продукции. Характеристики качества ируководства по их применению

[5] ИСО/ТО 10014-981) Руководство по управлению экономикойкачества

[6] ИСО 8402-941) Управление качеством и обеспечение качества.Словарь


111

[7] ИСО 9004-1-941) Управление качеством и элементы системкачества. Часть 1. Руководства

[8] ГОСТ Р ИСО/МЭК ТО 15271-2002 Информационная технология.Руководство по применению ГОСТ Р ИСО/МЭК 12207(Процессы жизненного цикла программных средств)

[9] ИСО/МЭК ТО 15504-1-981) Информационная технология.Аттестация процессов жизненного цикла программныхсредств. Часть 1. Общие понятия и вводное руководство

[10] ИСО/МЭК ТО 15504-2-981) Информационная технология.Аттестация процессов жизненного цикла программныхсредств. Часть 2. Эталонная модель процессов и ихфункциональных возможностей

[11] ИСО/МЭК ТО 15504-3-981) Информационная технология.Аттестация процессов жизненного цикла программныхсредств. Часть 3. Проведение аттестации

[12] ИСО/МЭК ТО 15504-4-981) Информационная технология.Аттестация процессов жизненного цикла программныхсредств. Часть 4. Указания по проведению аттестации

[13] ИСО/МЭК ТО 15504-5-981) Информационная технология.Аттестация процессов жизненного цикла программныхсредств. Часть 5. Модель аттестации и руководство попоказателям

[14] ИСО/МЭК ТО 15504-6-981) Информационная технология.Аттестация процессов жизненного цикла программныхсредств. Часть 6. Указания по компетентности экспертов

[15] ИСО/МЭК ТО 15504-7-981) Информационная технология.Аттестация процессов жизненного цикла программныхсредств. Часть 7. Указания по применению приусовершенствовании процессов

[16] ИСО/МЭК ТО 15504-8-981) Информационная технология.Аттестация процессов жизненного цикла программныхсредств. Часть 8. Указания по применению при определениивозможностей процессов поставщика


112

[17] ИСО/МЭК ТО 15504-9-981) Информационная технология.Аттестация процессов жизненного цикла программныхсредств. Часть 9. Словарь

[18] Application Strategies for Risk Analysis, R. Charette, 1990

[19] Assessment and Control of Software Risks, Capers Jones, 1994

[20] Continuous Risk Management Guidebook, Carnegie MellonUniversity Software Engineering Institute, 1996

[21] Guidelines for Successful Acquisition and Management ofSoftware Intensive Systems: Weapon Systems Command andControl Systems Management Information Systems Volumes 1and 2, Department of the Air Force, Software Technology SupportCenter, September 1994

[22] Managing Projects in Organizations, revised edition, J. DavidsonFrame and Jossey-Bass, 1995

[23] Managing Software Projects - Selecting and Using PC-BasedProject Management Systems, Lois Zells, 1990

[24] Managing the Software Process, Watts S. Humphrey, 1989

[25] Managing Uncertainty in Changing World, SEI Conference on RiskManagement, April 7, 1997

[26] Project Management - A Systems Approach to Planning,Scheduling, and Controlling, Harold Kersner, Ph. D., VanNorstrand Reinhold, 1998

[27] Quality Software Management, G. Weinberg, 1992

[28] Software Acquisition Management - Managing the Acquisition ofCustom Software Systems, John J. Marciniack and Donald J. Reifer,1990

[29] Software Management Guide, Software Technology Center (STSC)Hill Air Force Base, UT 84056, April 1992

[30] Software Engineering Project Management, Richard H. Thayer(Ed.), IEEE, 1988


113

[31] The Program Managers Guide to Software Acquisition BestPractices, Software Program Managers Network, Norm Brown(Executive Director), 1988

[32] Quantitative Methods for Project Management, Frank T. Anbari,PhD, International Institute for Learning, 1997

[33] Principles of Software Management, Gib Т., 19881) Оригиналы международных стандартов ИСО (ИСО/МЭК) - во

ВНИИКИ Госстандарта России.

Ключевые слова: обработка данных, вычислительные машины,программные средства вычислительных машин, управление,проекты, программные проекты


114

Программная инженерия. Руководство по ... · 2011-06-03 · guide...

Documents