Глава

Введение

В октябре 1968 года в немецком городе Гармиш (Garmish) прошла конференцияподкомитета NATO по науке и технике. На этой конференции присутствовало пятьде-сят профессиональных разработчиков ПО из одиннадцати стран. Наряду с тем, чтобольшинство обсуждений было сосредоточено на технических аспектах проектирова-ния, производства, реализации, распространения и поддержки программ, также рас-сматривались отчеты о “трудностях планирования встреч и заданий в больших про-граммных проектах”. Это, возможно, было первое общественное признание важностиуправления программными проектами. Вскоре после этого в Хедсор Парк (HedsorPark), уединенном местечке вблизи Лондона, собрались двадцать два руководителяиз различных стран, которые курировали разработку ПО в академиях, научно-исследовательских лабораториях и на предприятиях. На этой встрече упоминалось оконференции NATO, а также производился анализ будущих направлений развитияпроцесса разработки ПО. Здесь специалисты впервые серьезно заговорили о надви-гающемся “кризисе ПО”. Он был связан со все более усиливающимся воздействиемПО на жизнь людей, вследствие чего процессы разработки требовали постоянногоусовершенствования. В рамках этого была предложена концепция жизненного цикларазработки ПО (Software life cycle, SLC). Эта модель реализует последовательностьсобытий, происходящих при разработке ПО. Определение цикла SLC, равно как и спо-ры относительно смысла его существования, было предметом многих беседи публикаций, связанных с индустрией ПО. Накопившиеся к концу 70-х годов прошлоговека противоречия привели к появлению лозунга: “Остановите жизненный цикл, я хочувыйти!” Несмотря на существование различных точек зрения, потребность в докумен-тально подтвержденном процессе разработки ПО осталась столь же актуальной.В 1970 году У.У.Ройс (W.W.Royce) произвел идентификацию нескольких стадий в ти-пичном цикле SLC. Именно Ройс и Барри Боэм (Barry Boehm) предположили, что осу-ществление контроля каждой стадии процесса разработки приведет к улучшению ка-чества ПО, а также к увеличению производительности при разработке программ. На-пример, работа по проектированию интерфейсов программного модуля может быть

1

32 Глава 1

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

Рис. 1.1. Каскадная модель жизненного цикла разработки ПО (SLC)

На самом деле, большинство действий в ходе выполнения проектов не происходятпо линейному закону. Зачастую разработчикам бывает необходимо возвратиться кпредыдущей стадии, чтобы выполнить задачи, которые не были в свое время разре-шены соответствующим образом. Если на стадии разработки обнаруживается отсут-ствие или неправильное формулирование требований, разработчик не продвигаетсявперед, а возвращается назад — к стадии спецификаций требований. После заверше-ния и коррекции спецификаций требований повторно вводится и начинает выполнять-ся стадия разработки. Чтобы отобразить повторяющийся характер разработки ПО, вграфике рис. 1.1 были добавлены обратные стрелки, в результате чего получилсяграфик стандартного жизненного индустриального цикла, показанный на рис. 1.2.

Введение 33

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

Рис. 1.2. Повторяющаяся каскадная модель жизненного цикла разработки ПО(SLC)

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

34 Глава 1

временных моделей SLC, а также принципы их выбора. Кроме того, в главе 4 будутрассмотрены группы процессов из руководства Основы знаний в области управле-ния проектами (Project Management Body of Knowledge®, PMBOK®) — процессыинициализации, планирования, выполнения и завершения. Также анализируется, какимобразом эти процессы представлены на стадии жизненного цикла разработки ПО.

Для упрощения дальнейшего изложения действия, выполняемые в рамках проек-тов, будут описываться в каждой главе этой книги с их привязкой к общей модели жиз-ненного цикла, реализованной в виде каскадной модели с повторениями. Хотя многиепрограммные приложения значительно изменились по сравнению с 70-ми годамипрошлого века, десятки тысяч разработчиков осваивали язык первого цикла SLC,включив его в своего свой общий словарь. Термины фаза, повторение, критерииввода и вывода, исследование концепции, сопровождение и т.д.. были унаследованыпоследующими поколениями аналитиков, проектантов и программистов. Независимо отпрограммного проекта, его масштаба или характеристик, реализуются фазы исследо-вания концепции с учетом процесса “вывода из эксплуатации”. “Старый добрый” циклSLC “фотографирует” фазы проекта, независимо от их продолжительности. Здесьтакже описывается, каким образом каждая из глав книги может применяться в процес-се разработки ПО.

Тридцать четыре необходимыекомпетенции. Введение

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

Мы составили перечень компетенций, используемых менеджерами наиболее ус-пешных программных проектов и разбили их на три категории: продукт, проект и персо-нал, как показано на рис. 1.3. Этот перечень основывается на опыте многих практи-кующих менеджеров программных проектов, которые вносили вклад в программу сер-тификации менеджмента программных проектов (SWPM) в Техасском университете с1993 по 2001 годы. Этот перечень содержится в документе Body of Knowledge (SQIBOK), разработанный Институтом качества ПО.

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

Методики разработки продукта

1. Процессы оценивания — определение критериев для обзора.2. Знание стандартов процесса — понимание стандартов процесса.

Введение 35

3. Определение продукта — идентификация клиентской среды и требований, вы-двигаемых к продукту.

4. Оценка альтернативных процессов — оценка различных подходов.

Управление программными проектамиÏðîäóêò Ïðîåêò Ïåðñîíàë

1. Ïðîöåññû îöåíèâàíèÿ

2. Çíàíèå ñòàíäàðòîâ ïðîöåññà

3. Îïðåäåëåíèå ïðîäóêòà

4. Îöåíêà àëüòåðíàòèâíûõ ïðîöåñ-ñîâ

5. Óïðàâëåíèå òðåáîâàíèÿìè

6. Óïðàâëåíèå ñóáïîäðÿä÷èêàìè

7. Âûïîëíåíèå íà÷àëüíîé îöåíêè

8. Îòáîð ìåòîäîâ è èíñòðóìåíòîâ

9. Ïîäãîíêà ïðîöåññîâ

10. Îòñëåæèâàíèå êà÷åñòâà ïðîäóêòà

11. Ïîíèìàíèå äåéñòâèé ïî ðàçðà-áîòêå ïðîäóêòà

12. Ñîçäàíèå ñòðóêòóðû ïîîïåðàöèîííî-ãî ïåðå÷íÿ ðàáîò

13. Äîêóìåíòèðîâàíèå ïëàíîâ

14. Îöåíêà ñòîèìîñòè

15. Îöåíêà òðóäîçàòðàò

16. Ìåíåäæìåíò ðèñêîâ

17. Îòñëåæèâàíèå ïðîöåññà ðàçðàáîòêè

18. Ñîñòàâëåíèå ãðàôèêà

19. Âûáîð ìåòðè÷åñêèõ ïîêàçàòåëåé

20. Îòáîð èíñòðóìåíòîâ ìåíåäæìåíòàïðîåêòîâ

21. Îòñëåæèâàíèå ïðîöåññîâ

22. Îòñëåæèâàíèå õîäà ðàçðàáîòêè ïðî-åêòà

23. Îöåíêà ïðîèçâîäèòåëüíîñòè

24. Âîïðîñû èíòåëëåêòóàëüíîé ñîá-ñòâåííîñòè

25. Îðãàíèçàöèÿ ýôôåêòèâíûõâñòðå÷

26. Âçàèìîäåéñòâèå è îáùåíèå

27. Ëèäåðñòâî

28. Óïðàâëåíèå èçìåíåíèÿìè

29. Óñïåøíîå âåäåíèå ïåðåãîâîðîâ

30. Ïëàíèðîâàíèå êàðüåðíîãî ðîñòà

31. Ýôôåêòèâíîå ïðåäñòàâëåíèå

32. Íàáîð ïåðñîíàëà

33. Îòáîð êîìàíäû

34. Ñîçäàíèå êîìàíäû

Рис. 1.3. Тридцать четыре компетенции, которыми должен владеть каждый ме-неджер программного проекта

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

контроля.7. Выполнение начальной оценки — оценка степени трудности, рисков, затрат и

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

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

продукта.11. Понимание действий по разработке продукта — изучение цикла разработки

ПО.

Навыки менеджмента проектов

1. Создание структуры пооперационного перечня работ — создание структурыWBS для проекта.

2. Документирование планов — идентификация ключевых компонентов.3. Оценка стоимости — оценка стоимости завершения проекта.4. Оценка трудозатрат — оценка трудозатрат, необходимых для завершения про-

екта.

36 Глава 1

5. Менеджмент рисков — идентификация, определение воздействия и обработкарисков.

6. Отслеживание процесса разработки — контроль процесса разработки ПО.7. Составление графика — разработка графика и ключевых стадий проекта.8. Выбор метрических показателей — выбор и использование соответствующих

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

выборе инструментов менеджмента проектов.10. Отслеживание процессов — мониторинг совместимости среди членов команды

разработчиков.11. Отслеживание хода разработки проекта — мониторинг хода разработки проек-

та с помощью выбранных метрических показателей.

Навыки менеджмента персонала

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

2. Вопросы интеллектуальной собственности — понимание степени влияниякритических проблем.

3. Организация эффективных встреч — планирование и проведение эффектив-ных встреч.

4. Взаимодействие и общение — взаимодействие с разработчиками, высшим ру-ководством и другими командами.

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

6. Управление изменениями — обеспечение эффективного управления измене-ниями.

7. Успешное ведение переговоров — разрешение конфликтов и успешное веде-ние переговоров.

8. Планирование карьерного роста — структурирование и управление ходом реа-лизации карьеры.

9. Эффективное представление — эффективное использование письменных иустных навыков.

10. Набор персонала — успешная вербовка и собеседование с членами команды.11. Отбор команды — отбор высококомпетентных специалистов.12. Создание команды — формирование, руководство и поддержка эффективной

команды.Вариации описанных компетенций рассматриваются во всех главах книги.

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

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

Введение 37

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

ссылки на многие компетенции содержатся в каждой главе.

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

рых группируются 34 компетенции в области менеджмента (управления) программныхпроектов (project management, PM), полезно определить несколько основных терми-нов. Для лучшего понимания последующего материала будут представлены описания ипрактические разработки ПО, управления проектами и процессами, в дополнение кважным определениям, приведенных в примечании 1.1.

Примечание 1.1. Важные определения, относящиеся к управлению проек-тами

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

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

Определение “менеджмента программных проектов”Эта книга посвящена практике использования ПО, проекта и менеджмента. Какой

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

Ниже приводится их упрощенная интерпретация.ПО — это программа (программы), которая является конечным продуктом проекта

(программного инжиниринга) (см. примечание 1.2.) В этом случае воспользуемся тер-минологией, предложенной Институтом программного инжиниринга (Software Engi-

38 Глава 1

neering Institute, SEI) и Институтом инженеров по электротехнике и электронике(Institute of Electrical and Electronics Engineers, IEEE). При этом мы также будем ис-пользовать сведения, имеющие отношение к вопросам обеспечения качества. Этаинформация предоставляется Национальным институтом стандартов и технологий(National Institute of Standards and Technology, NIST), Международной организациейстандартов (International Organization for Standards, ISO), Американским национальныминститутом стандартов (American National Standards Institute, ANSI) и Американскимобществом обеспечения качества (American Society for Quality, ASQ).

Примечание 1.2. Определение ПО

Источник: www.bartleby.comПОПрограммы, процедуры и символические языки, которые управляют функциониро-ванием аппаратных средств.

Проект — это большое или важное действие (или последовательность действий),которое было запланировано заранее. “Схема” такого наименования кажется несколь-ко примитивной (см. примечание 1.3.). Для определения проекта используем опреде-ление, данное Институтом управления проектами (Project Management Institute®, PMI®)и Институтом IEEE.

Примечание 1.3. Определение проекта

Источник: www.m-w.com/cgi-bin/dictionaryПроект1. Определенный план или разработка проекта: СХЕМА.2. Запланированное действие: (a) определенным образом сформулированная

часть исследования; (b) большое, обычно поддержанное правительственнымисубсидиями действие; (c) задача или проблема, обычно поставленная передгруппой студентов, которая затем выносится на аудиторные занятия.

Менеджмент — это практика выполнения и управления проектом (см. примечание1.4). Для определения менеджмента вернемся к PMI® и общей практике менеджмен-та в том аспекте, в каком она преподается в курсе на получение степени Магистрауправления бизнесом (Master of Business Administration, или MBA).

Примечание 1.4. Определение менеджмента

Источник: www.m-w.com/cgi-bin/dictionaryМенеджмент1. Акт или искусство менеджмента: проведение или наблюдение чего-либо (как в

случае с бизнесом).2. Разумное использование средств для достижения какого-либо результата.3. Коллективный орган управляющих предприятием.

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

Введение 39

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

Определение инжиниринга ПОСогласно Барри Боэму (Barry Boehm), инжиниринг ПО — это практическое приме-

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

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

Определение проектаА теперь перейдем к рассмотрению понятия менеджмент (управление) про-

граммными проектами .В двух упомянутых авторских учебниках по MBA и в специализированных курсах по

менеджменту проектов представлены следующие определения проекта.Гарольд Керцнер (Harold Kerzner) определяет проект как произвольный ряд дейст-

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

Джеймс Льюис (James Lewis) рассматривает проект как одноразовую работу, кото-рая имеет определенные даты начала и окончания, ясно определенные цели, воз-можности и, как правило, бюджет. Это действия, отличающиеся от повторяющихсяопераций, таких как производство, обработка заказа и т.д. В данном случае идет речьо специфическом действии, имеющем определенные тактические цели5.

1 Boehrn B. Software Engineering Economics. Englewood Cliffs, NJ: Prentice Hall, 1976. — p.16.2 Institute of Electrical and Electronics Engineers. IEEE Std 610.12-1990 Standard Glossary of Soft-

ware Engineering Terminology. Software Engineering Standards Collection. NY: Institute of Electricaland Electronics Engineers, 1983. — p. 76.

3 Schach Stephen R. Classical and Object-Oriented Software Engineering, 4th ed. Boston, MA:McGraw-Hill, 1999. — p. 4.

4 Kerzner H. Project Management: A Systems Approach to Planning, Scheduling, and Controlling,6th ed. NY: John Wiley & Sons, 1998. — p. 2.

5 Lewis James P. Project Planning, Scheduling, and Control: A Hands-On Guide to Bringing Proj-ects in on Time and on Budget, rev ed. Chicago, IL: Irwin, 1995. — pp. 2-3.

40 Глава 1

Зная эти определения, можно увидеть, каким образом конструируется широко из-вестный “треугольник ПМ” (рис. 1.4). В ходе осуществления проекта ставится задачапоставок продукта с определенной областью действия, стоимость которого остается взаданных пределах, выдерживается определенный график выполнения, а также дос-тигается определенная степень качества. Задача менеджеров проекта состоит в том,чтобы уравновешивать производительность (область действия), время (график) и ре-сурсы (стоимость). И все же нередко бывает так, что график, бюджет и качество невыдерживаются на требуемом уровне. Поэтому руководители вынуждены выбирать вкачестве первичной цели только один или два параметра качества. Это действие из-вестно на профессиональном жаргоне как “треугольник хорошо-быстро-дешево —выбери два из них”.

Согласимся с известным гуру в области ана-лиза обеспечения качества Джозефом Джура-ном (Joseph Juran) в том, что проект — это про-блема, намеченная для решения.

Институт управления проектами, которыйспециализируется не только на производствеПО, приводит в своем Руководстве PMBOK®неплохо сформулированное определение. Со-гласно PMI®, проект рассматривается как вре-менное усилие, предпринятое для того, чтобысоздать уникальный продукт или услугу с опре-деленной датой начала и окончания действия,отличающегося от продолжающихся, повторныхдействий и требующего прогрессивного совер-шенствования характеристик6.

Эти определения проекта имеют несколькообщих характеристик.

Цель. У проекта должна быть четко опреде-ленная цель или ряд целей. В ходе осуществ-ления проекта должен быть получен какой-либо

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

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

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

6 Project Management Institute. A Guide to the Project Management Body of Knowledge. Sylva, NC:PMI Publication Division, 1996. — p.167.

Рис. 1.4. Треугольник менедж-ментапроектов

Введение 41

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

Ограничения. Проект имеет ограничения по стоимости, графику и качеству выпол-нения. Они формируют “большую тройку” треугольника ПМ, который для достиженияуспеха должен быть сбалансирован и управляем.

Итак, практическое определение термина “проект” в терминах разработки ПО тако-во: проект — это уникальное, временное действие с определенными датами начала иконца, направленное на то, чтобы достичь одной или нескольких целей в пределах ог-раничений стоимости, графика и качества выполнения.

Определение программыПрограмма подобна проекту, и зачастую эти понятия путают. Хотя многие люди от-

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

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

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

Американским обществом обеспечения качества (The American Society forQualityTM, ASQTM) сертифицируются инженеры по качеству ПО путем проведения эк-замена на звание Сертифицированного инженера по качеству ПО (Certified SoftwareQuality Engineer, CSQE). Совет по качеству штата Индиана издает учебник, предназна-ченный для осуществления подготовки к экзамену (CSQE Primer). В этом учебникеописывается программа, представляющая собой группу связанных между собой про-ектов. При этом могут формулироваться коллективные интересы и стратегические це-ли, в процессе достижения которых может предприниматься ряд повторяющихся илициклических действий.

В документе PMI® приводится следующее краткое определение: программа — этогруппа взаимосвязанных проектов, управляемых координированным способом. Про-граммы обычно включают элемент продолжающегося действия8.

7 Kerzner H. Project Management: A Systems Approach to Planning, Scheduling, and Controlling,

6th ed. NY: John Wiley & Sons, 1998. — p. 70.8 Project Management Institute. A Guide to the Project Management Body of Knowledge. Sylva, NC:

PMI Publication Division, 1996. — p.167.

42 Глава 1

Эти определения схожи в том, что программа является:

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

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

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

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

Определение управления проектамиВ документе PMI® менеджмент (управление) проектами определяется как набор

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

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

Общие концепции в этих утверждениях таковы: управление — умения в области менеджмента (управления) проектами представ-ляют собой подмножество общих умений в области менеджмента;

навыки — навыки в области управления проектами представляют собой примене-ние умений в области менеджмента для достижения целей проекта. Они включаютпланирование, организацию, составление графика, контроль, управление и отсле-живание.Каким же образом управление проектами связано с основами знаний (Body of

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

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

Введение 43

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

Рис. 1.5. Сегмент, являющийся областью пере-сечения PMBOK с областью знаний MBA и обла-стью знаний управления проектами

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

Некоторые другие полезные определенияВ дополнение к терминам ПО, проект, менеджмент, управление программными

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

Определение процессаВ PMI управление проектами определяется как некий конгломерат, состоящий из

проверенных принципов, методов и методик. Наиболее часто методы и методикивключают рабочие процессы, поддерживаемые со стороны инструментов.

Определение процесса согласно Мерриам-Вебстеру (Merriam-Webster) приведенов приложении 1.5.

Приложение 1.5. Определение процесса

Источник: www.m-w.com/cgi-bin/dictionaryПроцесс1. Что-либо происходящее.2. Естественное явление, отмеченное постепенными изменениями, которые при-

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

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

44 Глава 1

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

На рис. 1.6. проиллюстрированы взаимосвязи между вводом, преобразованием ивыводом, определяющими процесс.

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

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

Таблица 1.1. Процессы проекта и продукта

Процессы проекта Процессы продукта

Описание и организация работы врамках проекта

Определяет и создает продукт проекта

Чаще всего применимые в течениебольшей части времени

Определяется используемым жизненным циклом

Определенное Институтом PMI®Руководство PMBOK®

Изменяются в области приложения

Определяется документом Основы знаний (Body of Know-ledge, или BOK), используемыми сертифицированными ин-женерами обеспечения качества ПО (CSQE) Американскогообщества обеспечения качества (ASQ)

Определение задач и действийТермины задача и действие зачастую являются взаимозаменяемыми, вследствие

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

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

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

9 Позаимствовано из книги Pall Gabriel A. Quality Process Management. Englewood Cliffs, NJ:Prentice-Hall, 1987

Введение 45

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

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

действие — организационная единица, предназначенная для выполнения опреде-ленной функции, а также составные части или функции действий10.

Рис. 1.6. Ввод, преобразование и выход процесса

Другие авторитетные определения из документа PMBOK выглядят следующим об-разом:

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

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

мевается что-нибудь “отслеживаемое”, не входящее в состав WBS. Подобные знаниямогут приобретаться в ходе профессионального обучения. Именно поэтому не всеможет уподобиться “шагам младенца”, описываемым в учебнике по компьютерномупрограммированию. На протяжении многих лет велась дискуссия относительно того,является ли задача частью действия либо же наоборот — является ли действие ча-стью задачи. В издании PMBOK за 2000 год вносится ясность по этому вопросу.

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

10 www.m-w.com/cgi-bin/dictionary. Merriam-Webster's Collegiate® Dictionary Online.11 Project Management Institute. A Guide to the Project Management Body of Knowledge. Sylva, JC:

PMI Publication Division, 2000. — pp. 43, 55.

46 Глава 1

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

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

Определение фазыЛюбой большой и сложный проект может быть легко разбит на явное количество

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

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

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

Определение системыКак и слово “вещь”, которое является наиболее неоднозначным словом в англий-

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

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

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

Введение 47

крытой (взаимодействующей с ближайшим окружением) или закрытой (которая изоли-рована от близлежащего окружения)12.

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

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

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

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

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

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

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

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

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

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

12 Kerzner, Harold. Project Management: A Systems Approach to Planning, Scheduling, and Con-

rolling, 6th ed. NY: John Wiley & Sons, 1998. — pp. 69-72.

48 Глава 1

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

Таблица 1.2. Компетенции продукта (ПО)

Компетенция продукта Описание Глава или приложе-ние, содержащие опи-сание этой темы

1. Процессы оценивания Определение критериев для вы-полнения экспертных оценок

11, 25, 26, 30

2. Знание стандартов процесса Понимание стандартов процесса Приложение А3. Определение продукта Идентификация клиентской среды

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

7

4. Оценка альтернативныхпроцессов

Оценка различных подходов 4, 7, 13

5. Управление требованиями Отслеживание изменяющихсятребований

16, 17

6. Управление субподрядчика-ми

Планирование, менеджмент и от-слеживание производительности

6, 12, 32

7. Выполнение начальнойоценки

Оценка степени трудности, рис-ков, затрат и графика

9, 10, 11, 18

8. Отбор методов и инструмен-тов

Определение процессов отбора 24, 31, приложение D

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

4, 13, 14

10. Отслеживание качествапродукта

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

30

11. Понимание действий по раз-работке продукта

Изучение цикла разработки ПО 4, 5

Область действия компетенций продуктаСуществует множество подходов к “последовательности” событий, которые со-

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

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

Введение 49

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

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

Краткое описание навыков, непосредственносвязанных с выпуском продуктов

Компетенции продукта с 1 по 11 кратко описаны в следующих разделах.

Компетенция продукта 1: определение критериев длявыполнения экспертных оценок (обзора)

В обзоре описывается действие оценивания или приводится оценка конечных про-дуктов работы. Зачастую обзоры требуются и на некоторых стадиях выполнения про-екта, и особенно — на заключительных стадиях фаз. Как только определяется соот-ветствующий жизненный цикл, становятся известны его фазы, благодаря чему можноопределить, когда производятся обзоры продукта в конце фаз. Обзоры также могут идолжны иметь место в ходе осуществления процесса. В главе 30 описывается случай,когда определяется уместность, субъект и порядок выполнения обзора. Также суще-ствуют аспекты контроля качества, на которые должны быть направлены обзоры, та-кие как стоимость обеспечения качества и подсчет дефектов. Треугольники, позаим-ствованные из каскадной модели IEEE 1074 (рис. 1.7), демонстрируют, что командаразработчиков должна передать обзор только что завершенной фазы перед перехо-дом к выполнению следующей фазы. Внутренний и внешний поставляемые продуктывнутри каждой фазы, в дополнение к обзорам продукта в конце фаз, также являютсякандидатами на роль обзора. Выполнение ранних обзоров оценок трудозатрат и стои-мости приведет к улучшению суммарной подтвержденной оценки стоимости/графикапроекта, как описано в главе 11.

В главе 25 подробно рассматривается, что в состав объектов, которые подлежатобзору, также включены результаты сравнения реальной и оценочной стоимости, ре-ального и оценочного графика, приводится процент завершения проекта, результатыоценки степени риска и многие другие измерительные “барометры” проекта.

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

50 Глава 1

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

Компетенция продукта 2: понимание стандартов процессаВ приложении А изложен материал по стандартам, влияющих на успешную дея-

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

Организации, поддерживающие процесс разработки ПО, отвечают за многие изэтих стандартов. Список некоторых из этих организаций представлен в табл. 1.3.

Рис. 1.7. Обзоры фаз повторяющегося жизненного цикла разработки ПО в кас-кадной модели

Введение 51

Таблица 1.3. Организации, поддерживающие процесс разработки ПОс применением промышленных стандартов

Сокра-щение

Организация Основная цель Связь с SWPM URL-ссылка

PMI® Институт управле-ния проектами(Project ManagementInstitute®)

Общий менедж-мент проектов

Руководство Основы зна-ний в области управленияпроектами (ProjectManagement Body ofKnowledge, PMBOK)

www.pmi.org

Окончание табл. 1.3

Сокра-щение

Организация Основная цель Связь с SWPM URL-ссылка

ASQTM Американское обще-

ство обеспечениякачества (AmericanSociety of Qualitytm)

Улучшение каче-ства производи-мых продуктов

Основы знаний в областиинжиниринга качественногоПО (Сертифицированныйинженер по качеству ПО[CSQE] BOK)

www.asq.org

IEEE Институт инженеровпо электротехнике иэлектронике (Instituteof Electrical and Elec-tronics Engineers)

Стандарты инжи-ниринга

Собрание стандартовв области программногоинжиниринга

www.ieee.org

ISO Международная ор-ганизация по стан-дартизации (Interna-tional Organization forStandardization)

Международныестандарты

Стандарты качества ISO9000; стандарт процессажизненного цикла ПОISO/IEC 12207 IT

www.iso.ch

ANSI Американский на-циональный инсти-тут стандартов(American NationalStandards Institute)

Американские на-циональные стан-дарты

Руководство, определяю-щее применение стандар-тов lSO/IEC 12207 по от-ношению к управлениюпроектами программногоинжиниринга

www.ansi.org

NIST Национальный ин-ститут стандартов итехнологий (NationalInstitute of Standardsand Technology)

Технология, изме-рения и стандар-ты, применяемыев американскойпромышленности

Национальная премияМалкольма Балдриджа заотличное качество работы(Malcolm Baldrige NationalQuality Award forPerformance Excellence,MBNQA)

www.nist.gov

SEI Институт программ-ного инжиниринга(Software EngineeringInstitute)

Программный ин-жиниринг

Модель зрелости возмож-ности в применении к раз-работке ПО, версия 1.1(Capability Maturity Model,CMMTM)

www.sei.cmu.edu

52 Глава 1

Компетенция продукта 3: идентификация клиентской средыи требований, связанных с разрабатываемым продуктом

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

Это определение продукта учитывает наличие поставляемых продуктов проекта,продемонстрированных в приложении F. В этом приложении описываются стандарт-ные продукты индивидуальной проектной работы, а также связывающие их отношенияи планы: менеджмента программных проектов (software project management plan,SPMP), управления рисками, коммуникации, менеджмента конфигурации ПО (Softwareconfiguration management plan, SCM), план обеспечения качества ПО (software qualityassurance plan, SQA) и план тестирования.

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

Компетенция продукта 4: оценивание различныхприменяемых подходов

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

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

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

формулирование с учетом привлечения всех заинтересованных лиц. Проблемы кон-тактов, изменение уровня ожиданий, отличие потребностей и многие другие барьерыусложняют работу. В главе 16 описано несколько методов получения и формулирова-ния реальных требований для спецификации требований к ПО и определения ценно-сти каждого из них. Методы выявления требований, которые будут рассмотрены ниже,включают: опрос, учет случаев использования и анализ сценария, ролевую игру, рабо-та с архивными документами, формирование опрашиваемых групп, использованиеразбиения на отдельные фрагменты, создание опытных образцов/моделирование,использование совместной разработки приложения (Joint Application Design®, JAD) идругих подобных методов, использование программных средств автоматизации кол-

Введение 53

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

Определение корректных требований является, возможно, наиболее важной ча-стью программного проекта. В главе 17 описывается разработка документа специфи-кации требований ПО (Software requirements specification, SRS), начиная с исследова-тельских действий по предоставлению помощи клиенту в определении его истинныхжеланий и потребностей. В связи с рассмотрением данной компетенции будет описанпорядок разработки требований, сбора требований с использованием модели объек-та, а также представление шаблона SRS с последующей разработкой документа SRS.

В главе 23 описаны методики аттестации фактического содержания документаSRS после того, как требования были собраны и зарегистрированы в шаблоне специ-фикаций. Они представляют собой другой пример того, где должно использоватьсядействие по выполнению обзора. Многие из них будут описаны в обзорах, посвящен-ных реализации процессов программного проекта (главы 19 – 24). Также будут описа-ны порядок и область применения этих и подобных им методик. Рассматривается по-рядок выполнения экспертных оценок (процедуры экспертизы, ее формы и т.д.), опыт-ные образцы, развертывание функции обеспечения качества (quality functiondeployment, QFD) и инструменты — ряд систем поддержки методов и процессов.

Компетенция продукта 6: планирование, управлениеи осуществление контроля за деятельностью субподрядчиков

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

В главе 12 рассматривается этап, наступающий после отбора команды разработчи-ков проекта. Ресурсы включают персонал, ПО, аппаратные средства, средства под-держки и все, что еще необходимо для выполнения планов проекта. В главе будутрассмотрены такие проблемы, как: использование упомянутых ресурсов наравне собобщенными метками; балансирование между платежными возможностями и степе-нью полезности; определение методов распределения ресурсов по уровням; разра-ботка версий продукта и порядок принятия решений о покупке (создание продуктавнутри организации либо закупка имеющегося в наличии коммерческого продукта(commercial-off-the-shelf, COTS) и заключение субдоговора наравне с разработкойпродукта средствами компании.

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

54 Глава 1

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

Компетенция продукта 7: оценивание трудностей, рисков,затрат и графика

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

Ключ к успешному планированию программного проекта — хорошо выполненнаяоценка. Обычно продолжительность выполнения задачи в области разработки ПО за-висит от размера создаваемого программного продукта. В главе 10 описываются по-лезные методики оценки, позволяющие выполнить калибровку ПО, включая меры под-счета, и повторное использование ПО. Также подчеркивается важность пониманияметодов его оценки.

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

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

Компетенция продукта 8: определение процессов отбораПрименение менеджерами проектов тех или иных методов разработки ПО, мето-

дик и инструментов совместно с методами менеджмента проектов определяет успехили неудачу организации.

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

13 Материал этой главы описывает правовые аспекты, актуальные для США, хотя в эпоху

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

Введение 55

В главе 24 обсуждается использование некоторых общих инструментов, доступныхдля планирования и управления программными проектами. Основное внимание в этойглаве уделяется важным характеристикам инструментов, используемых в процессеSWPM, неспецифическим программным продуктам, причем материал предназначендля практического использования. Отдельные приложения обсуждаются в остальныхглавах. Так, будут рассмотрены: инструменты автоматизированного проектирования исоздания программ (Computer aided software engineering, CASE) и в объектно-ориентированных (Object-oriented, OO), и в структурированных средах; оценка разме-ра ПО и инструменты оценки, такие как конструктивная стоимостная модель(Constructive cost model, COCOMO) и SLIM. Также рассматриваются инструментыпланирования, отслеживания и контроля проекта, составления графика и отчетов отрудозатратах и равномерного распределения ресурсов. Многие из этих инструментовмогут использоваться при работе в Internet.

С самого начала необходимо предусмотреть сис-тему менеджмента конфигурации (Configuration man-agement, CM), причем она должна быть доступной навсех этапах разработки проекта. Каждый отдельныйпоставляемый продукт проекта, начиная с исследова-ния концепции и документирования устанавливаемыхтребований, должен сохраняться при контроле кон-фигурации. В главе 31 рассматриваются проблемы иосновы стандартной системы менеджмента конфи-гурации программных проектов: принципы, основныетребования, планирование и организация, инструмен-ты, а также внутренние и внешние факторы. В этойпредметной области также находятся в компетенцииуправления проектами. Материал из приложения Dпредлагает рассмотрение “изнутри” системного ин-жиниринга, что является необходимым условием приразработке любого продукта. Ключевые области, охваченные в этом приложении, —процесс инжиниринга систем, жизненные циклы и методы. Они зачастую несколькоотличаются от тех же областей для программных систем.

Компетенция продукта 9: изменение стандартных процессовв целях удовлетворения требований проекта

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

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

Рис. 1.8. Взаимоотношениямежду методами, инстру-ментами и технологией

56 Глава 1

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

Подгонка проектных процессов и среды должна производиться с учетом всехимеющихся зависимостей. Большинство задач не выполняются в изоляции от проекта.Корректная идентификация имеющихся зависимостей является ключевым условием вделе построения рабочего графика. В главе обсуждаются некоторые из“настраиваемых” зависимостей, которые являются обычными в программных проек-тах, включая: расширенную поддержку на уровне компании, управление конфигураци-ей, менеджмент проектов и план SQA. Здесь также рассматривается потенциальнаяпроблема идентификации — высокий коэффициент объединения по входу или выходу,циклические взаимосвязи, определение критического пути, критическая цепь, замы-кающая уникальные ресурсы, а также ограничивающие взаимосвязи.

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

Компетенция продукта 10: отслеживание качестваразрабатываемого продукта

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

В главе 30 рассматриваются основы процесса улучшения качества в контекстереализации проекта. При этом рассматриваются следующие темы: определение каче-ства, его характеристики и критерии; краткая история динамики развития качества —Шухарт (Shewhart), Деминг (Deming), Дюран (Juran) и Косби (Crosby); понимание важ-ных концепций обеспечения качества — непрерывное усовершенствование и циклконтроля Деминга “планировать-делать-проверять-действовать” (plan-do-check-act,PDCA); управление изменением — реализация эффективного генератора изменений;обеспечение качества ПО; ознакомление с проблемами индустрии ПО.

Также рассматриваются вопросы обеспечения качества ПО (Software QualityAssurance, SQA) с акцентом на: определение качества ПО, отслеживание качествапроцесса и продукта, понимание процессов оценки и гарантирование качества(подготовка инструментов определения стоимости процесса обеспечения качества иознакомление с планом IEEE SQA).

Компетенция продукта 11: изучение цикла по разработке ПОКак и в случае с компетенциями 1 и 9, каскадная модель является типичной отправ-

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

Введение 57

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

Наряду с простым изучением моделей жизненного цикла, менеджер проекта поразработке ПО должен понимать основные процессы в области, для которой разра-батывается программа. Простое понимание информатики или процесса разработкиПО означает лишь то, например, что инженер-строитель понимает лишь принципыустройства и работы бульдозера. Инженеры-программисты и ученые-компьютерщикимогут концентрироваться лишь на понимании устройства и принципах работы инстру-ментов. Но для того чтобы быть успешным менеджером проекта, важно знать об-ласть, по отношению к которой будет применяться этот инструмент. В главе 5 описы-вается, как следует идентифицировать эту область, а также как нужно управлять спе-цифическими для данной области процессами. Менеджер проекта действует как“связующий мост” между разработчиками и потребителем. Он должен быть способенпонять клиента и среду продукта в контексте того, как они соотносятся с программны-ми продуктами, а также определить продукт в технической терминологии ПО. Теперь,когда был рассмотрен разрабатываемый программный продукт, настало время выяс-нить, как он будет создаваться. Здесь очень важно понимание того, что каждому про-дукту требуется его определение (требования), пересмотр (управление требованиями)и “встраивание” в организационную инфраструктуру. Эта инфраструктура включаетпланирование процессов и стандартов, методов и инструментов, которые будут ис-пользоваться в дальнейшем. Знание того, как оценивать альтернативные процессы иподгонять их к выбранным процессам, приводит нас к соответствующей инфраструк-туре. При наличии метода управления подрядчиками и определения начальных про-ектных рисков, затрат и графика можно установить стадию фактического развитияпродукта. Как только вся эта информация систематизирована, команда по разработкепроекта использует более скоростные методы разработки и идентифицирует проце-дуры отслеживания качества, после чего наступает этап реализации. Компетенциипроекта определяют все, что связано с использованием навыков по разработке про-дукта.

Навыки менеджмента проектовКроме навыков работы с продуктом, в этой книге будет рассмотрен каждый из

навыков проектного менеджмента, относящихся к упомянутым 34 компетенциям. Этинавыки проиллюстрированы в табл. 1.2 (компетенции с 12 по 22). Краткое описаниекаждой компетенции будет приведено в этом разделе, а более полное описание —приводится в последующих главах.

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

тентности при управлении программными проектами. Здесь будет представлено крат-кое объяснение навыков менеджмента проектов, описаны компетенции с 12 по 22,выступающие в качестве сетевого графика и как руководство для обзора. Главы, в ко-торых более подробно описывается каждая компетенция, перечислены в табл. 1.4.

58 Глава 1

Таблица. 1.4. Компетенции проекта

Компетенция проекта Описание Глава

12. Создание структуры поопераци-онного перечня работ

Создание структуры пооперационно-го перечня работ для проекта

4, 8, 9

13. Документирование планов Идентификация ключевых компонен-тов

4, 7, 17, 28, 30, 31приложение А

Окончание табл. 1.4

Компетенция проекта Описание Глава

14. Оценка затрат Оценка затрат, необходимых для за-вершения проекта

10, 11, 12, 16

15. Оценка трудозатрат Оценка трудозатрат, требуемых длязавершения проекта

10, 11, 12, 16, 17

16. Менеджмент рисков Определение степени воздействия иустранение влияния рисков

18, 21

17. Отслеживание процесса разра-ботки

Отслеживание процесса разработкиПО

24, 25, 26, 30

18. Составление графика Разработка графика и ключевых мет-рических показателей

7, 14, 15

19. Отбор метрических показателей Выбор соответствующих метриче-ских показателей

21, 24, приложе-ние A

20. Отбор инструментов управленияпроектами

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

24

21. Отслеживание процессов Отслеживание деятельности коман-ды разработчиков проекта

5, 21, 25, 26, 30

22. Отслеживание хода выполненияпроекта

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

21, 30

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

Краткое описание навыков менеджмента проектовКомпетенции проекта, с 12 по 22, кратко описаны в последующих разделах.

Компетенция проекта 12: разработка цикла WBS для проектаОснову любого проекта составляет структура пооперационного перечня работ

(work breakdown structure, WBS). Здесь описываются шаги, необходимые для выпол-нения проекта, а также их взаимосвязи. Создать хорошую структуру пооперационногоперечня работ, которая является полезной и пригодной к употреблению, не так просто,

Введение 59

как кажется на первый взгляд. В главах 8 и 9 описаны навыки менеджмента проектов,необходимые при создании WBS. Эта тема также рассматривается в главе 4.

В главах 19 – 24 описано, каким образом следует использовать структуру WBS вкачестве инструмента менеджмента проектов. Использование других полезных мет-рических инструментов описано в главе 25.

Рис. 1.9. Жизненные циклы бизнеса, продукта и проектаИсточник: Project Management Institute. A Guide to the Project Management Body ofKnowledge. Sylva, NC: PMI Publication Division, 1996.

Компетенции продукта и проекта необходимы, но не достаточны для успешной реа-лизации проекта. Лучшие на планете аналитики процесса, “умельцы” в деле постановкитребований, “кузнецы-инструментальщики”, проектировщики, кодировщики и менедже-ры проектов не могут успешно реализовать проект без учета компетенций персонала.Разработчики и клиенты — это не абстрактные проблемы, а люди с обычными потреб-ностями. Они любят, чтобы ими руководили, их инструктировали, с ними советовались,их вербовали и отбирали с должным достоинством. Спросите любого специалиста вобласти разработки ПО, были ли они когда-нибудь на неэффективной встрече, рабо-тали в непроизводительной команде, игнорировались ли когда-либо их карьерныеустремления, и вы, вероятно, услышите утвердительный ответ на каждый вопрос по-добного рода. Управление проектами — это не только дисциплина, в которой изучает-ся процесс разработки продукта, а также рассматривается управление процессами,определяющими выполнение технологических карт. Как известно, продукты не могутразрабатываться без участия персонала. Составители рассматриваемых 34 компе-тенций полагали, что все связанные с людьми действия — это составные задачи, ис-пользуемые на протяжении всего жизненного цикла разработки ПО.

Компетенция проекта 13: идентификация ключевыхкомпонентов планов

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

60 Глава 1

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

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

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

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

Компетенция проекта 14: оценка стоимости проектаПрогнозирование затрат и управление ими, наряду с графиком и областью дейст-

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

Знание размера ПО — условие первостепенное, поскольку оно является основойдля оценки стоимости и трудозатрат. В главе 10 исследуются методы оценки размерапрограмм. Точность оценки размера программного продукта обеспечивает материал,требуемый для точной оценки трудозатрат (см. главу 11). Оценка трудозатрат можетбыть связана с оценкой других затрат, например, стоимости материалов и накладныхрасходов. В результате можно вычислить полную стоимость программного проекта.На рис. 1.10 демонстрируется предполагаемая тенденция использования услуг глав-ных проектантов при осуществлении программного проекта.